Armazenamento em cache de Reinício da sessão no Nginx

Question

Alguns dias atrás, eu li uma postagem no blog sobre a retomada da sessão no nginx.

Nesse texto, o autor afirma que o nginx não fornece a capacidade de limpar regularmente o cache de sessão. Depois que "ssl_session_timeout" expirar, a sessão não será mais usada, mas o arquivo ainda está no disco rígido e pode ser lido por um invasor portanto, "Forward Secrecy" seria inútil neste momento.

Em vez de usar IDs de sessão, ele sugere a desativação do cache de sessão e usando tickets de sessão. Para fazer isso, uma "ticket_key" com 80 bytes de aleatoriedade deve ser criada pelo menos uma vez por dia.

Pesquisei na Internet para obter mais informações, mas não consegui encontrar nada de útil.

Q1: Qual é a localização do cache de sessão nginx e como eu posso verificar se os dados de conexão TLS (sessões)     estão no disco rígido?

Q2: é aconselhável usar os tickets da sessão?

    

Answer 1

Eu não posso responder a primeira pergunta, mas posso falar um pouco sobre a segunda.

Esta postagem do blog fornece algumas boas informações sobre falhas com tickets de sessão no TLSv1.2: link .

Então, como Michael diz que ambos têm seus problemas e somente se você usar o TLSv1.3 ( literalmente acabou de sair e, assim, tornar-se disponível em implementações no momento da redação) você pode usar a retomada de TLS com total segurança.

No entanto, dizer que o custo de desempenho de não usar a retomada da sessão TLS é significativo, e IMHO, os riscos são relativamente baixos (se alguém tiver acesso ao seu servidor, o jogo acaba, até onde eu sei). Por enquanto, recomendo usar os IDs de sessão e os tickets de sessão. Especialmente porque alguns clientes (Safari e IE no Windows 7 e anteriores) não suportam tickets de sessão. O Safari em particular ainda tem muitos usuários em dispositivos móveis e tablets - você realmente quer desacelerar significativamente todos os usuários do iOS?