If you're seeing this message, it means we're having trouble loading external resources on our website.

Se você está atrás de um filtro da Web, certifique-se que os domínios *.kastatic.org e *.kasandbox.org estão desbloqueados.

Conteúdo principal

Certificados digitais

O protocolo TLS se baseia em criptografia de chave pública. O computador remetente usa a chave pública do computador destinatário ao criptografar as informações. Antes disso, contudo, o TLS requer uma etapa crucial para sua segurança: o remetente deve verificar a identidade por trás da chave pública.
Um certificado digital, também conhecido como certificado de chave pública ou certificado de identidade, prova a propriedade de uma chave de criptografia.

A necessidade de certificados

O que aconteceria se o TLS não incluísse uma etapa de verificação de certificado?
Criminosos poderiam descobrir maneiras de interceptar uma solicitação de um computador para outro computador na internet, como por meio de pontos de acesso desonestos.
A partir daí, seria possível lançar um ataque man-in-the-middle (MITM), que em tradução livre significa "homem no caminho". Embora esse tipo de ataque seja chamado de "homem" no caminho, criminosos podem ter qualquer idade ou ser de qualquer gênero. Você também pode pensar no ataque como um ataque "masquerader in the middle" ("farsante no caminho").
Primeiramente, durante o processo de estabelecimento de uma conexão segura com TLS, um criminoso enviaria ao cliente sua própria chave pública em vez da chave pública do servidor.
Ilustração de uma interceptação ativa de um pacote TLS em um ponto de acesso desonesto. Há um servidor à esquerda e um notebook identificado como "Cliente" à direita. A área superior está identificada como "O que o cliente acha que acontece". Ela contém uma seta identificada com uma chave de criptografia verde que vai do servidor até um ponto de acesso identificado como "ponto de acesso legítimo". Outra seta tem a mesma identificação e vai do ponto de acesso legítimo até o cliente. A área inferior está identificada como "O que realmente acontece". Ela contém uma seta identificada com uma chave verde que vai do servidor até um criminoso chamado "ponto de acesso desonesto". Outra seta está identificada com uma chave vermelha que vai do ponto de acesso desonesto até o cliente.
Depois disso, sempre que o cliente criptografasse informações com a chave pública recebida, ele na verdade criptografaria com a chave pública do criminoso. O criminoso poderia, então, descriptografar a mensagem criptografada, alterá-la da forma que quisesse e criptografá-la novamente com a chave pública do servidor antes de enviar as informações para ele.
Ilustração de uma interceptação ativa de um pacote TLS por meio de um ponto de acesso desonesto. À esquerda, um notebook tem um site aberto com um campo para inserção de valor preenchido. Há um servidor à direita. A área superior está identificada como "O que o cliente acha que acontece" e contém uma seta identificada com uma chave de criptografia verde e a frase "ID da conta: 25" que vai do notebook até um ponto de acesso identificado como "ponto de acesso legítimo". Outra seta identificada com as mesmas informações vai do ponto de acesso legítimo até o servidor. A área inferior está identificada como "O que realmente acontece". Ela contém uma seta identificada com uma chave vermelha e a frase "ID da conta: 25" que vai do notebook até um criminoso identificado como "ponto de acesso desonesto". Outra seta identificada com uma chave verde e a frase "ID da conta: 12" vai do ponto de acesso desonesto até o servidor.
Para evitar um ataque MITM, o cliente precisa verificar a identidade por trás de uma chave pública; e um certificado digital mostra a identidade por trás de uma chave pública. Mas, se qualquer um pode criar um certificado digital, como um cliente pode confiar em sua legitimidade? No TLS, os clientes acreditam em um certificado digital se ele tiver sido gerado por instituições conhecidas como autoridades de certificação.

Autoridades de certificação

Um servidor que quer se comunicar de forma segura por TLS se registra em uma autoridade de certificação. A autoridade de certificação verifica a propriedade do domínio, assina o certificado com seu próprio nome e chave pública, e devolve o certificado assinado para o servidor.
Um certificado inventado que se parece com os certificados dados a pessoas que ganham prêmios. Na parte superior está escrito "Certificado de Autenticidade". Abaixo disso, está escrito "Este certificado confirma que khanacademy.org é a orgulhosa proprietária desta chave pública:" e então há uma longa string hexadecimal. Na parte inferior, uma linha para assinatura está identificada como "Autoridade de certificação" e tem a assinatura "Autoridade de certificação GoDaddy." Outra linha está identificada como "Data de validade" e tem as datas "14/10/2018 - 18/11/2020".
Quando o cliente inspeciona o certificado, ele pode ver que uma autoridade de certificação está atestando a autenticidade da chave pública. Mas ainda há uma decisão a ser tomada: ele confia nessa autoridade de certificação?
Os clientes geralmente têm uma lista de autoridades de certificação confiáveis. Por exemplo, um iPhone da Apple com o sistema operacional iOS 10 confia nesta lista de autoridades de certificação.
Os usuários da Apple devem confiar na empresa para monitorar continuamente essa lista e garantir que cada autoridade de certificação esteja verificando os domínios adequadamente.
Imagine uma cadeia de confiança do usuário até o servidor:
Uma ilustração da cadeia de confiança do certificado. Ela se inicia com um ícone identificado como "usuário" à esquerda. Há uma seta identificada como "confia em" que vai do ícone do usuário até um ícone de um smartphone identificado como "cliente". Outra seta identificada como "confia em" vai do ícone do cliente até um ícone de um computador identificado como "autoridade de certificação". Uma última seta identificada como "confia em" vai do ícone da autoridade de certificação até um ícone de um computador identificado como "servidor".
A confiança pode ser quebrada em qualquer um dos pontos. Se o usuário não confiar no cliente, ele poderá desconsiderar sua lista padrão de autoridades de certificação confiáveis. Se um cliente não confiar mais em uma autoridade de certificação, ele a removerá de sua lista. Se uma autoridade de certificação perceber um comportamento suspeito vindo de um servidor, ela poderá revogar seu certificado.

Autoridades de certificação intermediárias

Na verdade, há diversos níveis de autoridades de certificação: a autoridade de certificação raiz e a autoridade de certificação intermediária.
A autoridade de certificação raiz, na realidade, não emite nenhum certificado digital diretamente para os servidores. Ela só emite certificados digitais para autoridades de certificação intermediárias que agem em seu nome. As autoridades de certificação intermediárias podem emitir certificados digitais para outra autoridade de certificação intermediária ou diretamente para um servidor.
Assim, há outra cadeia de confiança, que vai da autoridade de certificação raiz até o servidor:
Uma ilustração da cadeia de confiança da autoridade de certificação. Ela se inicia com um ícone identificado como "AC raiz" à esquerda. Há uma seta identificada como "confia em" que vai desse ícone até outro ícone de servidor identificado como "AC intermediária". Outra seta identificada como "confia em" vai desse ícone até outro ícone de servidor identificado como "AC intermediária". Uma última seta identificada como "confia em" vai desse ícone até o ícone de um servidor identificado como "Servidor".
As camadas das autoridades de certificação aumentam a segurança do sistema. Se uma autoridade de certificação raiz descobre que uma autoridade de certificação intermediária foi comprometida por um criminoso, ela invalida os certificados dessa autoridade de certificação, mas continua a confiar nos certificados de suas outras autoridades de certificação intermediárias.
🔍 É possível ver a cadeia de confiança ao verificar o certificado de um site seguro no navegador. Ao clicar no cadeado próximo à URL, o navegador deve oferecer uma forma de inspeção dos certificados.
Captura de tela de certificados emitidos para o site da Khan Academy. Ela mostra uma lista que se organiza encaixando uma informação dentro da outra com "GlobalSign Root CA" no topo, depois "GlobalSign CloudSSL CA", e em seguida "khan.map.fastly.net".
A cadeia de confiança da KhanAcademy.org inclui uma autoridade de certificação intermediária.

🙋🏽🙋🏻‍♀️🙋🏿‍♂️Você tem alguma dúvida sobre esse assunto? Adoraríamos respondê-la. Basta enviar sua pergunta na área de dúvidas abaixo!

Quer participar da conversa?

Você entende inglês? Clique aqui para ver mais debates na versão em inglês do site da Khan Academy.