0
0
SSL e seu descendente, TLS, são protocolos que criptografam o tráfego da internet, tornando possível a comunicação segura da internet e o comércio eletrônico.
A história de décadas desses protocolos tem sido marcada por atualizações contínuas que visam acompanhar os atacantes cada vez mais sofisticados. A próxima versão principal do protocolo, o TLS 1.3, será finalizada em breve — e a maioria dos que dirige um site vai querer atualizar, porque os cibercriminosos estão se atualizando.
Secure Sockets Layer, ou SSL, era o nome original do protocolo quando foi desenvolvido em meados da década de 1990 pela Netscape, a empresa que fez o navegador da Web mais popular na época. O SSL 1.0 nunca foi lançado ao público, e o SSL 2.0 teve falhas graves. SSL 3.0, lançado em 1996, foi completamente renovado, e definiu o palco para o que se seguiu.
TLS vs. SSL
Quando a próxima versão do protocolo foi lançada em 1999, foi padronizada pela Força-Tarefa de Engenharia da Internet (IETF) e recebeu um novo nome: Transport Layer Security, ou TLS. Como observa a especificação do TLS, “as diferenças deste protocolo e do SSL 3.0 não são dramáticas”. Assim, não é realmente uma questão de TLS vs. SSL; em vez disso, os dois formam uma série de protocolos continuamente atualizados, e muitas vezes são agrupados como SSL/TLS.
O protocolo TLS criptografa o tráfego de internet de todos os tipos. O mais comum é o tráfego web; você sabe que seu navegador está conectado via TLS se a URL em seu endereço começar com “https”, e há um indicador com um cadeado dizendo que a conexão é segura, como nesta captura de tela do Chrome:
Mas o TLS também pode ser usado por outros aplicativos, incluindo e-mail e usenet.
Como funciona o SSL
A criptografia é necessária para se comunicar com segurança pela internet: se seus dados não forem criptografados, qualquer pessoa pode examinar seus pacotes e ler informações confidenciais. O método mais seguro de criptografia é chamado de criptografia assimétrica; isso requer duas chaves criptográficas — peças de informação, geralmente números muito grandes — para funcionar corretamente, uma pública e outra privada. A matemática aqui é complexa, mas em essência, você pode usar a chave pública para criptografar os dados, mas precisa da chave privada para descriptografá-los. As duas chaves estão relacionadas uma com a outra por alguma fórmula matemática complexa que é difícil de fazer engenharia reversa por força bruta. Pense na chave pública como informações sobre a localização de uma caixa de correio trancada com um slot na frente, e a chave privada como a chave que desbloqueia a caixa de correio. Qualquer um que saiba onde está a caixa de correio pode colocar uma mensagem nela; mas para qualquer um lê-lo, eles precisam da chave privada.
Como a criptografia assimétrica envolve esses problemas matemáticos difíceis, é preciso muitos recursos de computação, tanto que se você a utilizasse para criptografar todas as informações em uma sessão de comunicação, seu computador e conexão iriam parar. O TLS contorna esse problema usando apenas criptografia assimétrica no início de uma sessão de comunicações para criptografar a conversa que o servidor e o cliente têm que concordar com uma única chave de sessão que ambos usarão para criptografar seus pacotes a partir desse ponto. A criptografia usando uma chave compartilhada é chamada criptografia simétrica, e é muito menos computacionalmente intensiva do que criptografia assimétrica. Como essa chave de sessão foi estabelecida usando criptografia assimétrica, a sessão de comunicação como um todo é muito mais segura do que seria de outra forma.
O processo pelo qual essa chave de sessões é acordada é chamado de aperto de mão, já que é o momento em que os dois computadores comunicadores se apresentam um ao outro, e está no centro do protocolo TLS.
Processo de aperto de mão SSL
O processo de aperto de mão é bastante complexo, e há uma série de variações permitidas pelo protocolo. As etapas a seguir fornecem um esboço amplo que deve dar-lhe uma noção de como ele funciona.
- O cliente entra em contato com o servidor e solicita uma conexão segura. O servidor responde com a lista de suítes cifradas — kits de ferramentas algorítmicas de criação de conexões criptografadas — que ele sabe como usar. O cliente compara isso com sua própria lista de suítes de cifra suportadas, seleciona um e avisa ao servidor que ambos estarão usando.
- Em seguida, o servidor fornece seu certificado digital, um documento eletrônico emitido por uma autoridade terceirizada confirmando a identidade do servidor. Discutiremos os certificados digitais com mais detalhes em um momento, mas por enquanto a coisa mais importante que você precisa saber sobre eles é que eles contêm a chave criptográfica pública do servidor. Uma vez que o cliente recebe o certificado, ele confirma a autenticidade do certificado.
- Usando a chave pública do servidor, o cliente e o servidor estabelecem uma chave de sessão que ambos usarão para o resto da sessão para criptografar a comunicação. Existem várias técnicas para fazer isso. O cliente pode usar a chave pública para criptografar um número aleatório que é então enviado para o servidor para descriptografar, e ambas as partes usam esse número para estabelecer a chave de sessão. Alternativamente, as duas partes podem usar o que é chamado de troca de chaves Diffie-Hellman para estabelecer a chave de sessão.
Este artigo na SSL.com tem um ótimo diagrama delineando cada passo de comunicação ao longo do processo de aperto de mão da TLS.
Como o nome indica, a chave de sessão só é boa para o curso de uma única sessão de comunicação ininterrupta. Se, por algum motivo, as comunicações entre cliente e servidor forem cortadas — devido a um problema de rede, por exemplo, ou porque o cliente está ocioso por muito tempo — um novo aperto de mão será necessário para estabelecer uma nova chave de sessão quando a comunicação for restabelecido.
O que é um certificado SSL?
Um certificado SSL é um documento eletrônico que confirma a identidade de um servidor e permite a comunicação criptografada.
Como a descrição na seção anterior deixou claro, esses certificados estão no centro do protocolo SSL/TLS: eles fornecem ao cliente a chave criptográfica pública necessária para iniciar conexões seguras. Mas seu propósito vai além de apenas fornecer a chave em si; eles também autenticam que a chave está de fato associada à organização que a oferece ao cliente.
Como isso funciona? Os certificados são emitidos por Autoridades de Certificado (CAs), que servem como o equivalente a um escritório de passaporte quando se trata de confirmar identidades. As organizações que desejam oferecer serviços criptografados pela TLS devem comprar certificados de CAs, que, por sua vez, verificam se as organizações são quem afirmam ser. Por exemplo, se você quisesse comprar um certificado para garantir um site em example.com, você teria que tomar algumas medidas para provar ao CA que você controla o domínio example.com. Dessa forma, se alguém se conectar a example.com e receber um certificado SSL válido emitido por um CA confiável, pode ter certeza de que está se comunicando com o legítimo proprietário de example.com. Isso pode evitar o homem nos ataques do meio.
Observe que usamos a frase “CA confiável” no último parágrafo. Qualquer um pode se configurar como uma autoridade de certificado; como você pode dizer quais realizam a diligência necessária para autenticar seus clientes? Felizmente, o trabalho de descobrir isso é principalmente cuidado pelos fabricantes de software. A Fundação Mozilla mantém uma lista de CAs em que o Firefox confiará; Apple e Microsoft também mantêm listas que implementam no nível do SISTEMA operacional para Windows, macOS e iOS, que o Chrome usa nessas plataformas. As decisões sobre as quais os CAs confiam têm altas apostas, como um confronto de 2017 entre o Google e a Symantec sobre o que o Google achava que eram os padrões frouxos da Symantec, deixaram claro.
A norma que define certificados SSL é chamada X.509. Esta norma permite que os certificados carreguem muitas informações além apenas da chave pública e da identidade confirmada do proprietário do certificado; DigiCert é um CA cuja base de conhecimento tem uma descrição detalhada do padrão.
Damas SSL
Quase toda a troca e confirmação de informações detalhadas acima ocorre nos bastidores à medida que você se comunica com servidores que oferecem conexões criptografadas por TLS. Se você quiser obter um pouco mais de transparência, você pode inserir a URL de um site criptografado SSL/TLS em um site de verificador SSL. O verificador devolverá uma série de informações sobre o certificado do site testado, incluindo o tipo de servidor, que os navegadores da Web confiarão e não confiam no certificado, no emissor, no número de série e na data de validade.
A maioria dos verificadores SSL são serviços gratuitos oferecidos pelos CAs como ferramentas de marketing para seus produtos; muitos, por exemplo, permitirão que você defina um alerta para quando um certificado inspecionado expirar, supondo que ele é seu certificado e você estará no mercado para um novo à medida que essa data se aproxima. Se você está procurando uma alternativa um pouco menos comercial, confira o verificador SSL da Qualys SSL Labs, que fornece uma coleção particularmente robusta de informações em sites inspecionados.
Vulnerabilidades TLS 1.2 e TLS 1.2
O TLS 1.2 é a versão mais atual definida do protocolo, e tem sido por vários anos. Estabeleceu uma série de novas opções criptográficas para comunicação. No entanto, como algumas versões anteriores do protocolo, também permitiu que técnicas criptográficas mais antigas fossem usadas, a fim de suportar computadores mais antigos. Infelizmente, isso o abriu para vulnerabilidades, à medida que essas técnicas mais antigas se tornaram mais vulneráveis à medida que o tempo passou e o poder computacional tornou-se mais barato.
Em particular, o TLS 1.2 tornou-se cada vez mais vulnerável aos chamados ataques “homem no meio”, nos quais um hacker intercepta pacotes no meio da comunicação e os envia após lê-los ou alterá-los. Também está aberto para os ataques POODLE, PREGUIÇA E DROWN. Muitos desses problemas surgiram nos últimos dois anos, aumentando o senso de urgência para a atualização do protocolo.
TLS 1.3
Felizmente, a ajuda está a caminho. A versão 1.3 do protocolo TLS, atualmente em forma de rascunho, mas que em breve será finalizada, conecta muitos desses buracos, lançando suporte para sistemas de criptografia legados. Há compatibilidade inversa no sentido de que as conexões cairão de volta para o TLS 1.2 se uma extremidade não for capaz de usar os sistemas de criptografia mais recentes na lista aprovada 1.3. No entanto, se, por exemplo, um ataque homem no meio tentar forçar um recuo para 1.2, a fim de bisbilhotar pacotes, que serão detectados e a conexão caiu.
Ainda há servidores por aí que estão usando versões do TLS ainda mais antigas que 1.2 — alguns ainda estão usando o protocolo SSL original. Se o seu corte for um desses, você deve atualizar agora, e basta saltar à frente e atualizar para a especificação do rascunho 1.3.
TLS crimeware
Uma última nota sobre TLS e segurança: os mocinhos não são os únicos que a usam! Muitos cibercriminosos usam o TLS para criptografar o tráfego de comando e controle entre seus servidores e malware instalado nos computadores da vítima. Isso acaba invertendo o estado habitual das coisas e deixa as vítimas de crimes cibernéticos procurando uma maneira de descriptografar o tráfego. Há uma série de técnicas para lidar com esse tipo de ataque criptografado, incluindo o uso de metadados de rede sobre o tráfego criptografado para ter uma noção do que os atacantes estão fazendo sem realmente ler nada disso.
FONTE: CSO ONLINE