Como habilitar o cache de reinicialização de sessão sem informações de estado por trás do balanceador de carga?

Question

Analisei a configuração de SSL / TLS dos meus servidores usando o link e ele relatou Session resumption (caching) No (IDs assigned but not accepted)

Estou usando duas instâncias de funções da web do Azure por trás de um balanceador de carga round-robin. Acredito que a retomada da sessão foi interrompida devido aos IDs da sessão serem armazenados em cache em um servidor, mas não no outro.

Como configuro o IIS para usar um cache compartilhado (preferencialmente o Redis) para seus IDs de sessão?

Atualização:

Não parece haver uma maneira de compartilhar o cache de sessão. No entanto, o Windows Server 2012 R2 parece suportar o link sem estado (baseado em tickets).

Tentei definir HKLM SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ MaximumCacheSize como 0, conforme declarado em link para desativar o cache de sessão, mas não há efeito.

Tentou ativar a sessão baseada em ticket com New-TlsSessionTicketKey e Enable-TlsSessionTicketKey ( link ) , mas também não há efeito.

Alguém conseguiu que essas configurações funcionassem?

Atualização 2:

Cache de sessão desativado com êxito configurando os dois

• HKLM \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ MaximumCacheSize para 0
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ ServerCacheTime para 0

e reiniciando o servidor

Ainda não é possível conseguir ingressos para o trabalho, apesar de executar o comando Enable-TlsSessionTicketKey para IIS AppPool\{app pool GUID} e Network Service

    

Answer 1

Finalmente, encontrei a maneira de ativar os tickets da sessão TLS no win2k12 r2 e no win2k16. Você precisa seguir estas etapas:

1. Crie uma chave ( DWORD ) no registro com valor 1 HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\EnableSslSessionTicket

2. Crie uma nova chave de ticket de sessão TLS por meio desse comando do powershell: New-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/new-tlssessionticketkey

3. Ative a chave do tíquete de sessão TLS por meio deste comando do powershell: Enable-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/enable-tlssessionticketkey

4. Reinicialize o servidor para ativar a geração de tíquete de sessão TLS. A reinicialização é necessária para que a entrada do registro entre em vigor.

IMPORTANTE: Para reutilizar os mesmos tickets de sessão TLS em servidores de carga balanceada, é necessário copiar o arquivo " C:\KeyConfig\TlsSessionTicketKey.config " gerado após a execução do comando " New-TlsSessionTicketKey " em um dos servidores e copiar o arquivo de configuração em todos os servidores restantes e execute o comando " Enable-TlsSessionTicketKey " do powershell em cada arquivo. Infelizmente isso só funcionou para mim no win2k16. Não funcionou no win2k12r2.

    

Answer 2

Pode haver algum mal-entendido sobre qual sessão está envolvida.

Você tem a sessão que a maioria dos aplicativos da Web usa para criar persistência entre várias solicitações HTTP, o conteúdo estereotipado do seu carrinho de compras. Não é isso que o SSLLabs está testando.
Independentemente disso: ao usar um balanceador de carga, você normalmente deve replicar esse estado de sessão para que o visitante não termine com um carrinho de compras vazio quando as solicitações HTTP subseqüentes forem distribuídas para servidores da Web de backend diferentes.

Há também a sessão SSL / TLS, que é o que o SSLLabs está testando.

Em suma, quando uma conexão SSL é estabelecida, o servidor web e o navegador usam um handshake / negociação de chave pública computacionalmente dispendioso no início (Diffie-Hellman). Parte dessa negociação é estabelecer uma chave simétrica, exclusiva para essa conexão específica, que será usada para a criptografia / decriptografia subsequente dos dados transmitidos através dessa conexão. A criptografia simétrica ainda é segura, mas computacionalmente relativamente barata, o que reduz a carga no servidor da Web e no navegador da Web. Ao contrário do HTTP simples, o navegador da web deixará a conexão HTTPS com o servidor da Web aberta e a usará para várias solicitações HTTPS, mas depois de algum tempo ocioso, a conexão ainda será fechada. É aí que o cache de sessão SSL entra em jogo. Se ativado, em vez de negociar uma nova chave simétrica, o servidor da Web pode permitir que o navegador da Web reutilize essa chave simétrica antiga na nova conexão. O benefício é que uma nova conexão é estabelecida mais rapidamente (ela economiza algumas viagens de ida e volta TCP / IP e alguma computação pesada), provavelmente às custas da segurança que eu suspeito.

Eu não sei se o IIS (ou outros servidores da Web para esse assunto) tem recursos para replicar o cache de sessão SSL para outros nós em um cluster carregado com carga. Pode não haver necessidade também. Geralmente, a terminação SSL ocorre no balanceador de carga ou as sessões fixas de TCP são usadas para garantir que as conexões HTTPS subseqüentes sejam manipuladas pelo mesmo servidor da Web, eliminando a necessidade de servidores da Web replicarem o cache de sessão SSL. Se isso acontecer, e o servidor da Web anunciar o suporte para reinicialização de SSL, mas o balanceador de carga distribuir a nova conexão para um servidor da Web diferente, será criada uma incompatibilidade.