O “S” em HTTPS não significa SSL

É natural supor que quando vemos um ícone de cadeado em nossos navegadores, o site está usando SSL para proteger nossas comunicações. Aparentemente, também é um sinal para os consumidores de que o site é, de fato, seguro . Tanto é assim que, de acordo com a Pesquisa de Confiança do Consumidor de 2015 do Conselho de Segurança da Califórnia, “apenas três por cento forneceriam suas informações de cartão de crédito para sites sem o ícone de cadeado”.

O impacto não se limita aos consumidores. Os entrevistados da nossa última pesquisa State of Application Delivery que já implementaram ou planejam implementar o “SSL Everywhere” demonstraram maior confiança (3 ou mais em uma escala de 1 a 5) na capacidade de sua organização de resistir a um ataque na camada de aplicativo.

A verdade é que a maioria das pessoas não sabe dizer o que significa SSL, muito menos descrever como ele funciona. O que eles sabem, no entanto, é que é um mecanismo para garantir a segurança das transações (e, portanto, de informações potencialmente confidenciais) ao interagir com um aplicativo ou site.

Em parte, isso é culpa nossa (do mercado). Usamos SSL como uma descrição do protocolo ( RFC 6101 ) e também como uma maneira genérica de descrever uma conexão segura. SSL é o Band-Aid da segurança, o Google dos mecanismos de busca, o Kleenex dos lenços de papel.

A realidade é que o HTTPS não requer SSL. O “S” em “HTTPS” significa seguro e simplesmente requer algum método de proteger conexões entre dois pontos de extremidade, como um navegador e um site. Cada vez mais, isso significa HTTP sobre TLS, não SSL.

Essa é uma diferença importante porque, embora compartilhem raízes, TLS não é SSL, não é TLS. São protocolos diferentes, cada um com seus próprios conjuntos exclusivos de desafios, problemas e impactos. Ambas as conexões seguras da mesma maneira – elas usam certificados para autenticação e pares de chaves pública/privada para criptografia – mas as diferenças de implementação permanecem.

Por que você deveria se importar? Você deve se importar porque os protocolos de aplicativos da web mais recentes (e talvez os melhores, ainda não sabemos) (HTTP/2 e SPDY) não oferecem suporte a SSL. Eles suportam TLS. Eles não exigem isso, por si só, mas as implementações de navegadores que oferecem suporte a ambos oferecem suporte apenas por TLS. Não SSL.

É verdade que hoje não há um número significativo de sites usando HTTP/2 ou SPDY, mas esse número está crescendo. Considere que 7,5% dos 1.000 principais sites agora estão disponibilizando conteúdo via HTTP/2:

Da W3CTech (julho de 2015):

O novo padrão HTTP/2 , cuja versão final foi publicada em maio de 2015, agora é usado por 0,4% de todos os sites (contra 0,24% no início do mês) e por 7,5% dos 1.000 principais sites .

Agora considere que não estamos falando apenas de navegadores e servidores. Também temos que considerar o que isso significa para a integração – para o uso de APIs vindas de alguns desses 1.000 principais sites (como o Google) que podem estar forçando o uso não apenas de HTTP/2 ou SPDY, mas também de TLS. Todos os serviços públicos do Google que oferecem criptografia usam TLS. Se você estiver integrando alguma funcionalidade do Google, pode ser que se importe que eles estejam usando TLS em vez de SSL. Porque faz a diferença por baixo dos panos.

Observe também que há ramificações comerciais. De acordo com o PCI, o SSL não poderá mais ser usado após 30 de junho de 2016.  Depois desse ponto, o TLS é explicitamente necessário.  Isso significa algumas mudanças para permanecer em conformidade com o PCI. E é claro que você precisa, porque se você não estiver em conformidade, há um monte de ramificações. Isso poderia, por exemplo, resultar em taxas de contas comerciais mais altas e multas dos emissores de cartão de crédito ou na revogação total da sua capacidade de processar pagamentos e transações. Se houver uma violação, sua empresa correrá maior risco de processos judiciais e multas devido à sua falha em realizar a devida diligência no que diz respeito à segurança.

Por fim, há este RFC ( RFC 7568 ) com uma redação muito forte que explica por que você realmente deveria migrar para o TLS:

3.Não use SSL versão 3.0

   SSLv3 NÃO DEVE ser usado .  Negociação de SSLv3 de qualquer versão do TLS

   NÃO DEVE ser permitido .

   Qualquer versão do TLS é mais segura que o SSLv3 , embora a mais alta

   a versão disponível é preferível .

Agora, não é viável presumir que você vai sair correndo e mudar de SSL para TLS neste exato minuto. Afinal, embora o TLS seja baseado no SSL v3, ele não é 100% compatível com seu antecessor e são necessárias algumas alterações de configuração para desabilitar o SSL e forçar o uso do TLS. Alterações de configuração que geralmente exigem uma reinicialização. Em um ambiente grande, esse processo é, compreensivelmente, perturbador e demorado.

Mas é hora de começar a considerar seriamente por quanto tempo você deseja oferecer suporte a SSL e quando deseja mudar para TLS puro.