As autoridades de certificação são uma das espinhas mais importantes da segurança da Internet. Uma autoridade de certificado é alguém que é confiável por todos, no começo, quando ninguém confia em mais ninguém. É então o trabalho desta autoridade de certificado (a.k.a ca) Para garantir que a confiança seja estabelecida entre servidores e clientes antes de estabelecer comunicação pela Internet.Uma CA é importante não apenas para HTTPs usados ​​por navegadores e aplicativos da web, mas também para e -mails criptografados, atualizações de software assinadas, VPNs e muito mais. Vamos dar o exemplo prototípico de https e aprender sobre a CA, neste contexto em particular. Embora você possa extrapolar o resultado para qualquer outra suíte 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 antigo site http http: //www.exemplo.com No seu navegador, muitas coisas podem acontecer no meio dos seus pacotes.

1. Um ator ruim pode interceptar a comunicação, copiar os dados por si mesmos, antes de renderizá -los novamente no canal em sua direção ou para o servidor com quem você estava falando. Sem o conhecimento de nenhuma das partes, a informação é comprometida. Precisamos garantir que a comunicação seja privado.
2. Um ator ruim pode modificar as informações enquanto estão sendo enviadas sobre o canal. Bob pode ter enviado uma mensagem "X" Mas Alice receberia "Y" de Bob, porque um ator ruim interceptou a mensagem e a modificou. Em outras palavras, o integridade da mensagem está comprometida.
3. Por fim, e o mais importante, precisamos garantir que a pessoa com quem estamos conversando seja de fato com quem eles dizem que são. Voltando ao exemplo.com domínio. Como podemos garantir que o servidor que nos respondeu de volta é realmente o legítimo titular de www.exemplo.com? Em qualquer momento 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 seu navegador não tem como verificar se o DNS traduziu o endereço IP.

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

Iniciando sessões http criptografadas

O principal problema da comunicação criptografada sobre um canal inseguro é “Como começamos?”

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

Bem, se as chaves estiverem sendo enviadas sobre um canal inseguro, qualquer um poderá ouvir sobre isso e comprometer a segurança da sua sessão HTTPS no futuro. Além disso, como podemos confiar que a chave sendo 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 festa maliciosa disfarçada como um site legítimo e não saber a diferença.

Portanto, o problema de garantir a identidade é importante se desejarmos garantir a troca de chaves seguras.

Autoridades de certificação

Você deve ter ouvido falar de LetSencrypt, Digicert, Comodo e alguns outros serviços que oferecem certificados TLS para seu nome de domínio. Você pode escolher o que atenda à sua necessidade. Agora, a pessoa/organização que possui o domínio precisa provar de alguma forma para sua autoridade de certificação que eles realmente têm controle sobre o domínio. Isso pode ser feito criando um registro DNS com um valor exclusivo, conforme solicitado pela autoridade de certificado, ou você pode adicionar um arquivo ao seu servidor da Web, com conteúdo especificado pela autoridade de certificado, a CA pode 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 Cert Public 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. Esta informação é assada no navegador/dispositivo desde o início (ou seja, quando eles são instalados) para que eles saibam que podem confiar em determinados casos. Agora, quando eles tentam se conectar a www.exemplo.com https e veja um certificado emitido por, digamos Digicert, o navegador pode realmente verificar se o uso das teclas armazenadas localmente localmente. Na verdade, existem mais algumas etapas intermediárias, mas essa é uma boa visão simplificada do que está acontecendo.

Agora que o certificado fornecido pela 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 descriptografia, e geralmente é muito mais rápido que sua contraparte assimétrica.

Nuances

Se a idéia de TLS e segurança da Internet atrair você, você poderá procurar mais neste tópico cavando LetSencrypt e seu TLS gratuito CA. Há muito mais minutiado em todo esse rigmarole do que o indicado acima.

Outros recursos que eu posso recomendar para aprender mais sobre o TLS são o blog de Troy Hunt e o trabalho realizado pela eft como https em todos os lugares e certbot. Todos os recursos são gratuitos para acessar e realmente baratos para implementar (você só precisa pagar pelo registro de nomes de domínio e cobranças por hora VPS) e obter uma experiência prática.