As autoridades de certificação são uma das mais importantes pedras angulares para a segurança na Internet. Uma autoridade de certificação é alguém em quem todos confiam, no início, quando ninguém confia em mais ninguém. É então o trabalho desta autoridade certificadora (também conhecida como CA) 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 só para HTTPS usados por navegadores e aplicativos 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 conjunto de software.

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

1. Um mau ator pode interceptar a comunicação, copiar os dados para si mesmo, antes de reenviá-los novamente no canal em direção a você ou ao servidor com o qual você estava falando. Sem o conhecimento de qualquer uma das partes, a informação fica comprometida. Temos de garantir que a comunicação é privada.
2. Um mau actor pode modificar a informação à medida que ela é enviada pelo canal. Bob poderia ter enviado uma mensagem “x” mas Alice receberia “y” de Bob, porque um mau ator interceptou a mensagem, e a modificou. Em outras palavras, a integridade da mensagem é comprometida.
3. Por último, e o mais importante, precisamos garantir que a pessoa com quem estamos falando é realmente quem eles dizem ser. Voltando ao domínio example.com. Como podemos ter certeza de que o servidor que nos respondeu é de fato o legítimo detentor do www.example.com? Em qualquer ponto da sua rede, você pode ser mal direcionado para outro servidor. Um DNS em algum lugar é responsável por converter um nome de domínio, como www.example.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 pelo DNS.

Os dois primeiros 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 entra em jogo uma Autoridade Certificadora.

Initiating Encrypted HTTP sessions

O principal problema da comunicação criptografada através de um canal inseguro é “Como iniciamos?”

O primeiro passo envolveria as duas partes, seu navegador e o servidor, para trocar as chaves de criptografia a serem trocadas através do canal inseguro. Se você não está familiarizado com o termo chaves, pense nelas como uma senha gerada aleatoriamente, realmente longa, 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 um pode ouvir sobre isso e comprometer a segurança da sua sessão HTTPS no futuro. Além disso, como podemos confiar que a chave que está sendo enviada por um servidor que afirma ser www.example.com é de fato o verdadeiro dono desse nome de domínio? Podemos ter uma comunicação encriptada com uma parte maliciosa disfarçada de site legítimo e não saber a diferença.

Então, o problema de garantir a identidade é importante se queremos garantir a troca segura de chaves.

Certificate Authorities

Você já 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 o que mais se adequa à sua necessidade. Agora, a pessoa/organização que possui o domínio tem de provar de alguma forma à sua Autoridade Certificadora que de facto tem controlo sobre o domínio. Isto pode ser feito criando um registo DNS com um valor único no mesmo, como solicitado pela Autoridade Certificadora, ou você pode adicionar um ficheiro ao seu servidor web, com o conteúdo especificado pela Autoridade Certificadora, a CA pode então ler este ficheiro e confirmar que você é o proprietário válido do domínio.

Então você negocia um certificado TLS com a CA, e isso resulta numa chave privada e num certificado TLS público emitido para o seu domínio. As mensagens criptografadas pela sua chave privada podem então ser descriptografadas pelo certificado público e vice versa. Isto é conhecido como criptografia assimétrica

Os navegadores clientes, como Firefox e Chrome (às vezes até o sistema operacional) têm o conhecimento das Autoridades Certificadoras. Esta informação é introduzida no browser/dispositivo desde o início (ou seja, quando são instalados) para que saibam que podem confiar em certos CAs. Agora, quando eles tentam conectar-se a www.example.com através de HTTPS e ver um certificado emitido por, digamos DigiCert, o navegador pode realmente verificar que usando as chaves armazenadas localmente. Na verdade, existem mais alguns passos intermediários, mas esta é uma boa visão simplificada do que está acontecendo.

Agora o certificado fornecido por www.example.com pode ser confiável, isto é usado para negociar uma chave de criptografia simétrica única que é usada entre o cliente e o servidor para o restante da sua sessão. Na encriptação simétrica, uma chave é usada para encriptar bem como para desencriptar e é normalmente muito mais rápida que a sua contraparte assimétrica.

Nuances

Se a ideia de TLS e segurança na Internet lhe agrada, pode aprofundar este tópico pesquisando o LetsEncrypt e a sua CA TLS gratuita. Há muito mais minuciosidade em todo este rigmarole do que o mencionado acima.