Há alguns dias li uma postagem no blog sobre a retomada da sessão no nginx.
Nesse texto, o autor afirma que o nginx não oferece a capacidade de limpar regularmente o cache da sessão. Depois que "ssl_session_timeout" expirar, a sessão não será mais usada, mas o arquivo ainda estará no disco rígido e poderá ser lido por um invasor, portanto, "Forward Secrecy" seria inútil neste momento.
Em vez de usar IDs de sessão, ele sugere desativar o cache de sessão e usar tickets de sessão. Para isso, uma "ticket_key" com 80 bytes de aleatoriedade deve ser criada pelo menos uma vez por dia.
Pesquisei na internet por mais informações, mas não consegui encontrar nada útil.
Q1: Qual é a localização do cache da sessão nginx e como posso verificar se os dados (sessões) da conexão TLS estão no disco rígido?
Q2: É aconselhável utilizar Session Tickets?
Responder1
Não posso responder à primeira pergunta, mas posso falar um pouco sobre a segunda.
Esta postagem do blog fornece algumas boas informações sobre falhas nos tickets de sessão no TLSv1.2:https://blog.filippo.io/we-need-to-talk-about-session-tickets/.
Então, como Michael diz, ambos têm seus problemas e somente se você usar TLSv1.3 (literalmente acabei de desconectare, portanto, apenas disponível nas implementações no momento em que este artigo foi escrito), você pode usar a retomada do 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 termina, no que me diz respeito). Por enquanto, recomendo usar IDs de sessão e 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 celulares e tablets - você realmente deseja desacelerar significativamente todos os usuários de iOS?