Implementação de codificação SSL mais rápida para Nginx se a força NÃO for necessária?

Question

Eu tenho um caso de uso que é o inverso da maioria: eu gostaria de implementar cifras SSL muito fracas em nome do desempenho, com a opção de voltar a cifras mais strongs se o cliente o solicitar.

Backstory: Eu tenho um servidor web voltado para o público que recebe uma quantidade gigantesca de tráfego POST de milhares de clientes remotos, com cada POST sendo bem pequeno. Um cliente pagará uma carga uma vez e desconectará. O servidor recebe milhares dessas conexões por minuto, então a sobrecarga da negociação SSL é adicionada.

Os dados em questão NÃO precisam ser seguros; A razão para usar HTTPS é porque o tráfego é originado de uma tag JavaScript em um determinado site, e se o site está usando HTTPS, o nosso tráfego suplementar também deve usar HTTPS para evitar aviso sobre a mistura de conteúdo seguro e inseguro. Novamente, a segurança dos dados nessa conexão não é importante, mesmo se o site "pai" estiver protegido por SSL por qualquer motivo.

Por causa disso, faz sentido apresentar a criptografia mais fraca possível para os clientes, mantendo a compatibilidade total com os navegadores. Também gostaria de oferecer a opção de aumentar a segurança para o ECDHE completo, se solicitado, apenas para satisfazer clientes mais conscientes da segurança, mas definitivamente como uma opção secundária.

Alguns anos atrás, algumas variantes do RC4 teriam se encaixado na proposta, mas como isso é universalmente criticado como inseguro hoje, estou preocupado que a compatibilidade do navegador possa se tornar um problema. Na sequência disso - que cifras me ofereceria as características que estou procurando acima, com a maior velocidade?

    

Answer 1

The data in question does NOT need to be secure... prevent warning about mixing secure

Acho que você provavelmente deve entender o motivo desses avisos, em vez de apenas tentar ignorá-los da melhor forma possível. Se o conteúdo de um site seguro for incluído em um site inseguro, isso poderá afetar a segurança do site original.

The server takes on thousands of these connections per minute, so the overhead of SSL negotiation adds up.

Uma codificação rápida geralmente não reduz significativamente a sobrecarga da negociação SSL. As cifras são usadas principalmente após a negociação ser feita e tem apenas um pequeno impacto no desempenho. Alguma parte da cifra é relevante para o handshake (a troca de chaves), mas, a menos que você escolha uma troca de chaves muito lenta (veja abaixo), o principal impacto no desempenho vem das múltiplas idas e voltas necessárias para a negociação. Isso só pode ser reduzido se você oferecer suporte à reutilização de sessões, para que um handshake completo seja necessário apenas para a primeira solicitação e, na próxima vez em que o mesmo cliente se conectar a uma sessão mais econômica, a retomada possa ser feita. O keep-alive do HTTP também pode ajudar muito. É claro que ambas as otimizações funcionam apenas se você tiver várias solicitações do mesmo cliente.

Existem algumas cifras com troca de chaves muito lenta, que você provavelmente não quer usar no seu caso. Todas as cifras DHE- * têm um grande impacto no desempenho, mas têm a vantagem de fornecer sigilo antecipado. Você obtém a mesma vantagem com as codificações ECDHE sem ter um impacto de desempenho muito grande no hardware de hoje, mas ainda existe uma sobrecarga. O uso de cifras como AES128-GCM-SHA256 deve ser uma boa escolha, tanto em termos de desempenho quanto em termos de segurança.

No final, a escolha da cifra depende também dos clientes que você usa. Enquanto RC4-SHA é rápido, é considerado inseguro e cada vez mais clientes o desabilitam. Assim, você pode e com um servidor rápido ninguém pode usar porque os navegadores desativaram cifras inseguras.

    

Answer 2

O absoluto mais rápido seria eNull. Para incluir eNull em ssl_ciphers, tente "aNULL: eNULL: MD5: LOW: HIGH" para sua cadeia de caracteres de criptografia. Normalmente, no entanto, você vai negociar a mais alta criptografia suportada. Portanto, você pode querer limitá-lo, definindo usando! HIGH, mas não deixe de testá-lo completamente. Você precisará pelo menos manter LOW, pois acredito que a maioria dos navegadores se recusaria a usar as cifras null e md5.

    

Answer 3

Dependendo da sua urgência, você pode esperar pela adoção de "Salsa20" e "ChaCha " em particular, que se destina a substituir diretamente o RC4 em termos de desempenho. No entanto, no momento, apenas o Google Chrome e os últimos lançamentos do Android OS o suportam no lado do cliente e ainda não estão no OpenSSL, portanto, nenhum servidor oferece suporte ainda. Caso contrário, concordo com os outros na AES-IN.