As autoridades de certificação são um dos pilares mais importantes para a segurança da Internet. Uma autoridade de certificação é alguém em quem todos confiam, no início, quando ninguém confia em ninguém. É então o trabalho desta autoridade de certificação (um.k.uma CA) para garantir que a confiança seja estabelecida entre servidores e clientes antes que eles estabeleçam comunicação pela Internet.Uma CA é importante não apenas para HTTPS usado por navegadores e aplicativos da web, mas também para e-mails criptografados, atualizações de software assinadas, VPNs e muito mais. Vamos pegar o exemplo prototípico de HTTPS e aprender sobre CA, neste contexto particular. Embora você possa extrapolar o resultado para qualquer outro pacote de software.

Problemas com HTTP e texto simples

A Internet é um canal de comunicação não confiável. Quando você envia ou recebe informações de um site HTTP antigo http: //www.exemplo.com em seu navegador, muitas coisas podem acontecer no meio do caminho para seus pacotes.

1. Um malfeitor pode interceptar a comunicação, copiar os dados para si mesmo, antes de reenviá-la no canal para você ou para o servidor com o qual você estava falando. Sem o conhecimento de nenhuma das partes, a informação fica comprometida. Precisamos garantir que a comunicação seja privado.
2. Um malfeitor pode modificar as informações à medida que são enviadas pelo canal. Bob pode ter enviado uma mensagem “X” mas Alice iria receber “Y” de Bob, porque um mau ator interceptou a mensagem e a modificou. Em outras palavras, o integridade da mensagem está comprometida.
3. Por último, e mais importante, precisamos garantir que a pessoa com quem estamos falando seja realmente quem diz ser. Voltando ao exemplo.com domínio. Como podemos ter certeza de que o servidor que nos respondeu é realmente o detentor legítimo de www.exemplo.com? Em qualquer ponto da sua rede, você pode ser direcionado para outro servidor. Um DNS em algum lugar é responsável por converter um nome de domínio, como www.exemplo.com, em um endereço IP na Internet pública. Mas o seu navegador não tem como verificar se o endereço IP traduzido do DNS.

Os primeiros dois problemas podem ser resolvidos criptografando a mensagem antes que ela seja enviada pela Internet para o servidor. Ou seja, mudando para HTTPS. No entanto, o último problema, o problema da identidade, é onde uma autoridade de certificação entra em jogo.

Iniciando sessões HTTP criptografadas

O principal problema com a comunicação criptografada em um canal inseguro é “Como começamos?”

A primeira etapa envolveria as duas partes, seu navegador e o servidor, para trocar as chaves de criptografia a serem trocadas no canal inseguro. Se você não estiver familiarizado com o termo chaves, pense nelas como uma senha muito longa gerada aleatoriamente com a qual seus dados serão criptografados antes de serem enviados pelo canal inseguro.

Bem, se as chaves estão sendo enviadas por um canal inseguro, qualquer pessoa pode ouvir isso e comprometer a segurança da sua sessão HTTPS no futuro. Além disso, como podemos confiar que a chave enviada por um servidor que afirma ser www.exemplo.com é de fato o verdadeiro proprietário desse nome de domínio? Podemos ter uma comunicação criptografada com uma parte mal-intencionada mascarada como um site legítimo e não saber a diferença.

Portanto, o problema de garantir a identidade é importante se quisermos garantir a troca segura de chaves.

Autoridades de Certificação

Você deve ter ouvido falar de LetsEncrypt, DigiCert, Comodo e alguns outros serviços que oferecem certificados TLS para o seu nome de domínio. Você pode escolher aquele que se adapta às suas necessidades. Agora, a pessoa / organização que possui o domínio tem que provar de alguma forma para sua Autoridade de Certificação que ela realmente tem controle sobre o domínio. Isso pode ser feito criando um registro DNS com um valor exclusivo, conforme solicitado pela Autoridade de Certificação, ou você pode adicionar um arquivo ao seu servidor web, com conteúdo especificado pela Autoridade de Certificação, a CA pode então ler este arquivo e confirme que você é o proprietário válido do domínio.

Em seguida, você negocia um certificado TLS com a CA, e isso resulta em uma chave privada e um certificado TLS público emitido para seu domínio. As mensagens criptografadas por sua chave privada podem ser descriptografadas pelo certificado público e vice-versa. Isso é conhecido como criptografia assimétrica

Os navegadores do cliente, como Firefox e Chrome (às vezes até o sistema operacional) têm o conhecimento das Autoridades de Certificação. Essas informações são incorporadas ao navegador / dispositivo desde o início (ou seja, quando são instalados) para que saibam que podem confiar em certas CAs. Agora, quando eles tentam se conectar a www.exemplo.com sobre HTTPS e ver um certificado emitido por, digamos DigiCert, o navegador pode realmente verificar isso usando as chaves armazenadas localmente. Na verdade, existem mais algumas etapas intermediárias para isso, mas esta é uma boa visão geral simplificada do que está acontecendo.

Agora que o certificado fornecido por www.exemplo.com pode ser confiável, isso é usado para negociar uma chave de criptografia simétrica única que é usada entre o cliente e o servidor para o restante de sua sessão. Na criptografia simétrica, uma chave é usada para criptografar, bem como descriptografar e geralmente é muito mais rápida do que sua contraparte assimétrica.

Nuances

Se a ideia de TLS e segurança na Internet o agrada, você pode examinar mais a fundo este tópico pesquisando LetsEncrypt e seu TLS CA gratuito. Há muito mais detalhes em toda essa besteira do que o declarado acima.

Outros recursos que posso recomendar para aprender mais sobre TLS são o Blog de Troy Hunt e o trabalho feito pela EFF como HTTPS Everywhere e Certbot. Todos os recursos são de acesso gratuito e muito baratos de implementar (você só precisa pagar pelo registro do nome de domínio e taxas de VPS por hora) e ter uma experiência prática.