Como o SSL realmente funciona?

143

Como o SSL funciona?

Onde o certificado está instalado no cliente (ou navegador?) E no servidor (ou servidor web?)?

Como o processo de confiança / criptografia / autenticação é iniciado quando você insere o URL no navegador e obtém a página do servidor?

Como o protocolo HTTPS reconhece o certificado? Por que o HTTP não pode funcionar com certificados quando são os certificados que funcionam com toda a confiança / criptografia / autenticação?

Vicky
fonte
24
Penso que esta é uma pergunta razoável - compreender como o SSL funciona é o passo 1, implementá-lo corretamente é do passo 2 ao passo infinito.
Synthesizerpatel
4
Aqui está uma boa gerência através de processo https aperto de mão a um nível de byte
Rob Church
5
@StingyJack Não seja um nazista de políticas aqui. As pessoas vêm procurando ajuda. Não negue toda a assistência, pois você acha que a pergunta não combina perfeitamente com as regras.
precisa saber é o seguinte
1
@KorayTugay - ninguém está negando assistência. Isso pertence ao Security ou Sysadmin, onde é mais direcionado, mas o OP normalmente se beneficiaria neste fórum adicionando um pouco de contexto de programação em vez de postar uma pergunta geral de TI. Quantas pessoas encerram as perguntas quando não estão vinculadas a um problema de programação específico? Provavelmente muitos, daí meu OP insistente para fazer essa associação.
precisa saber é o seguinte

Respostas:

144

Nota: eu escrevi minha resposta original muito apressadamente, mas desde então, isso se transformou em uma pergunta / resposta bastante popular, então eu a expandi um pouco e a tornei mais precisa.

Capacidades TLS

"SSL" é o nome mais frequentemente usado para se referir a este protocolo, mas SSL refere-se especificamente ao protocolo proprietário projetado pela Netscape em meados dos anos 90. "TLS" é um padrão IETF baseado em SSL, portanto, utilizarei o TLS na minha resposta. Hoje em dia, as chances são de que quase todas as suas conexões seguras na Web estejam realmente usando TLS, não SSL.

O TLS possui vários recursos:

  1. Criptografe os dados da camada do aplicativo. (No seu caso, o protocolo da camada de aplicativo é HTTP.)
  2. Autentique o servidor no cliente.
  3. Autentique o cliente no servidor.

# 1 e # 2 são muito comuns. # 3 é menos comum. Você parece estar se concentrando no # 2, então eu explicarei essa parte.

Autenticação

Um servidor se autentica em um cliente usando um certificado. Um certificado é um blob de dados [1] que contém informações sobre um site:

  • Nome do domínio
  • Chave pública
  • A empresa proprietária
  • Quando foi emitido
  • Quando expirar
  • Quem a emitiu
  • Etc.

Você pode obter confidencialidade (nº 1 acima) usando a chave pública incluída no certificado para criptografar mensagens que só podem ser descriptografadas pela chave privada correspondente, que deve ser armazenada com segurança nesse servidor. [2] Vamos chamar esse par de chaves de KP1, para não ficarmos confusos mais tarde. Você também pode verificar se o nome de domínio no certificado corresponde ao site que está visitando (nº 2 acima).

Mas e se um adversário pudesse modificar pacotes enviados para e a partir do servidor e se esse adversário modificasse o certificado que lhe foi apresentado e inserisse sua própria chave pública ou alterasse outros detalhes importantes? Se isso acontecesse, o adversário poderia interceptar e modificar qualquer mensagem que você pensasse estar criptografada com segurança.

Para evitar esse ataque, o certificado é criptograficamente assinado pela chave privada de outra pessoa, de forma que a assinatura possa ser verificada por qualquer pessoa que possua a chave pública correspondente. Vamos chamar esse par de chaves de KP2, para deixar claro que essas não são as mesmas chaves que o servidor está usando.

Autoridades de certificação

Então, quem criou o KP2? Quem assinou o certificado?

Simplificando um pouco, uma autoridade de certificação cria o KP2 e eles vendem o serviço de usar sua chave privada para assinar certificados para outras organizações. Por exemplo, eu crio um certificado e pago uma empresa como a Verisign para assiná-lo com sua chave privada. [3] Como ninguém além da Verisign tem acesso a essa chave privada, nenhum de nós pode forjar essa assinatura.

E como eu pessoalmente pegaria a chave pública no KP2 para verificar essa assinatura?

Bem, já vimos que um certificado pode conter uma chave pública - e os cientistas da computação adoram recursão -, por que não colocar a chave pública KP2 em um certificado e distribuí-la dessa maneira? Isso parece um pouco louco no começo, mas na verdade é exatamente assim que funciona. Continuando com o exemplo da Verisign, a Verisign produz um certificado que inclui informações sobre quem eles são, que tipos de coisas eles têm permissão para assinar (outros certificados) e sua chave pública.

Agora, se eu tiver uma cópia desse certificado da Verisign, posso usá-lo para validar a assinatura no certificado do servidor do site que quero visitar. Calma né ?!

Bem, não tão rápido. Eu tive que obter o certificado da Verisign de algum lugar . E se alguém falsificar o certificado Verisign e colocar sua própria chave pública lá? Em seguida, eles podem forjar a assinatura no certificado do servidor e voltamos ao ponto em que começamos: um ataque man-in-the-middle.

Cadeias de certificados

Continuando a pensar recursivamente, é claro que poderíamos introduzir um terceiro certificado e um terceiro par de chaves (KP3) e usá-lo para assinar o certificado Verisign. Chamamos isso de cadeia de certificados: cada certificado da cadeia é usado para verificar o próximo certificado. Espero que você já possa ver que essa abordagem recursiva é apenas tartarugas / certificados até o fim. Onde isso pára?

Como não podemos criar um número infinito de certificados, a cadeia de certificados obviamente precisa parar em algum lugar , e isso é feito incluindo um certificado na cadeia que é autoassinado .

Farei uma pausa por um momento enquanto você pega os pedaços de matéria cerebral da sua cabeça explodindo. Auto-assinado ?!

Sim, no final da cadeia de certificados (também conhecida como "raiz"), haverá um certificado que usa seu próprio par de chaves para se autenticar. Isso elimina o problema de recursão infinita, mas não corrige o problema de autenticação. Qualquer um pode criar um certificado autoassinado que diga algo sobre ele, assim como eu posso criar um diploma falso de Princeton que diz que eu me formei em política, física teórica e apliquei chutes e depois assinei meu próprio nome na parte inferior.

A solução [um tanto quanto desinteressante] para esse problema é escolher um conjunto de certificados autoassinados nos quais você confia explicitamente. Por exemplo, posso dizer: " Confio neste certificado autoassinado da Verisign".

Com essa confiança explícita, agora posso validar toda a cadeia de certificados. Não importa quantos certificados existam na cadeia, posso validar cada assinatura até a raiz. Quando chego à raiz, posso verificar se esse certificado raiz é aquele em que confio explicitamente. Nesse caso, posso confiar em toda a cadeia.

Confiança Conferida

A autenticação no TLS usa um sistema de confiança conferida . Se eu quiser contratar um mecânico de automóveis, talvez não confie em nenhum mecânico aleatório que encontrar. Mas talvez meu amigo ateste um mecânico em particular. Já que confio no meu amigo, posso confiar nesse mecânico.

Quando você compra um computador ou baixa um navegador, ele vem com algumas centenas de certificados raiz nos quais confia explicitamente. [4] As empresas que possuem e operam esses certificados podem conferir essa confiança a outras organizações assinando seus certificados.

Isso está longe de ser um sistema perfeito. Algumas vezes uma CA pode emitir um certificado incorretamente. Nesses casos, o certificado pode precisar ser revogado. A revogação é complicada, pois o certificado emitido sempre estará criptograficamente correto; é necessário um protocolo fora de banda para descobrir quais certificados anteriormente válidos foram revogados. Na prática, alguns desses protocolos não são muito seguros e muitos navegadores não os verificam.

Às vezes, uma autoridade de certificação inteira está comprometida. Por exemplo, se você invadir a Verisign e roubar sua chave de assinatura raiz, poderá falsificar qualquer certificado no mundo. Observe que isso não afeta apenas os clientes da Verisign: mesmo que meu certificado seja assinado por Thawte (um concorrente da Verisign), isso não importa. Meu certificado ainda pode ser falsificado usando a chave de assinatura comprometida da Verisign.

Isso não é apenas teórico. Isso já aconteceu na natureza. O DigiNotar foi famoso por ser hackeado e posteriormente faliu. O Comodo também foi hackeado , mas inexplicavelmente eles continuam no mercado até hoje.

Mesmo quando as autoridades de certificação não estão diretamente comprometidas, existem outras ameaças nesse sistema. Por exemplo, um governo usa coerção legal para obrigar uma CA a assinar um certificado falsificado. Seu empregador pode instalar seu próprio certificado CA no computador do funcionário. Nesses vários casos, o tráfego que você espera ser "seguro" é realmente completamente visível / modificável para a organização que controla esse certificado.

Algumas substituições foram sugeridas, incluindo Convergence , TACK e DANE .

Notas finais

[1] Os dados do certificado TLS são formatados de acordo com o padrão X.509 . X.509 é baseado em ASN.1 ( "Abstract Syntax Notation # 1"), o que significa que é não um formato de dados binário. Portanto, o X.509 deve ser codificado para um formato binário. DER e PEM são as duas codificações mais comuns que eu conheço.

[2] Na prática, o protocolo realmente muda para uma cifra simétrica, mas esse é um detalhe que não é relevante para sua pergunta.

[3] Presumível, a CA realmente valida quem você é antes de assinar seu certificado. Se eles não fizessem isso, eu poderia criar um certificado para google.com e solicitar que uma CA o assinasse. Com esse certificado, eu poderia intermediar qualquer conexão "segura" com o google.com. Portanto, a etapa de validação é um fator muito importante na operação de uma CA. Infelizmente, não está muito claro o quão rigoroso é esse processo de validação nas centenas de CAs em todo o mundo.

[4] Veja a lista do Mozilla de CAs confiáveis .

Mark E. Haase
fonte
O que é uma chave privada?
Koray Tugay
você esqueceu de mencionar que a chave pública faz parte do arquivo de certificado enviado ao site para descriptografar os dados que seu servidor criptografou em primeiro lugar.
Mamdouh alramadan
Obrigado @mamdouhalramadan. Eu editei para mencionar isso.
Mark E. Haase
2
@mamdouhalramadan "a chave pública é ... enviada ao site para descriptografar os dados". Como a chave pública pode ser usada para descriptografar dados?
Teddy
@ateddy Você está correto. Não pode. A chave pública é usada apenas para autenticação. A reivindicação aqui de que os pares de chaves também são usados ​​para criptografia e descriptografia está incorreta. Uma chave de sessão negociada com segurança é usada para isso.
Marquês de Lorne
53

HTTPS é uma combinação de HTTP e SSL (Secure Socket Layer) para fornecer comunicação criptografada entre cliente (navegador) e servidor da Web (o aplicativo está hospedado aqui).

Por que é necessário?

O HTTPS criptografa os dados transmitidos do navegador para o servidor pela rede. Portanto, ninguém pode farejar os dados durante a transmissão.

Como a conexão HTTPS é estabelecida entre o navegador e o servidor da web?

  1. O navegador tenta se conectar ao https://payment.com .
  2. O servidor payment.com envia um certificado para o navegador. Este certificado inclui a chave pública do servidor payment.com e algumas evidências de que essa chave pública realmente pertence a payment.com.
  3. O navegador verifica o certificado para confirmar se possui a chave pública adequada para payment.com.
  4. O navegador escolhe uma nova chave simétrica aleatória K para usar na conexão com o servidor payment.com. Ele criptografa K sob a chave pública payment.com.
  5. payment.com descriptografa K usando sua chave privada. Agora, tanto o navegador quanto o servidor de pagamento conhecem K, mas ninguém mais o conhece.
  6. Sempre que o navegador deseja enviar algo para o payment.com, ele o criptografa em K; o servidor payment.com descriptografa-o após o recebimento. Sempre que o servidor payment.com deseja enviar algo ao seu navegador, ele o criptografa em K.

Esse fluxo pode ser representado pelo seguinte diagrama: insira a descrição da imagem aqui

sanjay_kv
fonte
1
A parte sobre criptografar e enviar a chave da sessão e descriptografá-la no servidor é um lixo completo e total. A chave da sessão nunca é transmitida: é estabelecida por meio de um algoritmo de negociação de chave segura. Por favor, verifique seus fatos antes de postar bobagens como essa. RFC 2246.
Marquês de Lorne
Por que o navegador não usa a chave pública do servidor para criptografar dados ao publicá-los no servidor, em vez de criar uma nova chave simétrica aleatória K na etapa 4?
KevinBui
1
@KevinBui Porque o envio da resposta do servidor exigiria que o cliente tivesse um par de chaves e porque a criptografia assimétrica é muito lenta.
Marquês de Lorne
3

Eu escrevi um pequeno post no blog que discute o processo brevemente. Por favor, sinta-se livre para dar uma olhada.

Handshake SSL

Um pequeno trecho do mesmo é o seguinte:

"O cliente faz uma solicitação ao servidor por HTTPS. O servidor envia uma cópia do seu certificado SSL + chave pública. Depois de verificar a identidade do servidor com seu armazenamento CA confiável local, o cliente gera uma chave de sessão secreta, criptografa-a usando o servidor público do servidor. O servidor descriptografa a chave da sessão secreta usando sua chave privada e envia uma confirmação ao cliente. Canal seguro estabelecido. "

Abhishek Jain
fonte
"Depois de verificar a identidade do servidor com o armazenamento CA confiável local" - isso não é estritamente verdadeiro. Posso usar um certificado autoassinado e o HTTPS funcionaria - posso obter uma conexão HTTPS segura com um servidor . O certificado confiável é recebido somente quando eu quero ter certeza de que estou falando com o servidor certo .
Teddy
A parte sobre criptografar e enviar a chave da sessão e descriptografá-la no servidor é um lixo completo e total. A chave da sessão nunca é transmitida: é estabelecida por meio de um algoritmo de negociação de chave segura. Por favor, verifique seus fatos antes de postar bobagens como essa. RFC 2246.
Marquês de Lorne
@Teddy Isso não está correto. A verificação de confiança do certificado é uma parte obrigatória do SSL. Pode ser ignorado, mas normalmente está em vigor: certificados autoassinados não funcionam sem medidas especiais de um tipo ou de outro.
Marquês de Lorne
2

Mehaase já explicou isso em detalhes. Vou adicionar meus 2 centavos a esta série. Eu tenho muitos posts postados em torno de certificados e handshake SSL. Enquanto a maior parte disso gira em torno do servidor Web IIS, a postagem ainda é relevante para o handshake SSL / TLS em geral. Aqui estão alguns para sua referência:

Não trate CERTIFICADOS & SSL como um tópico. Trate-os como dois tópicos diferentes e tente ver quem eles trabalham em conjunto. Isso ajudará você a responder à pergunta.

Estabelecendo confiança entre as partes que se comunicam por meio do armazenamento de certificados

A comunicação SSL / TLS funciona apenas com base na confiança. Todo computador (cliente / servidor) na Internet possui uma lista de CAs raiz e CA intermediárias que ele mantém. Estes são atualizados periodicamente. Durante o handshake SSL, isso é usado como uma referência para estabelecer confiança. Por exemplo, durante o handshake SSL, quando o cliente fornece um certificado ao servidor. O servidor tentará verificar se a CA que emitiu o certificado está presente em sua lista de CAs. Quando não pode fazer isso, declara que não conseguiu fazer a verificação da cadeia de certificados. (Esta é uma parte da resposta. Também analisa a AIApara isso.) O cliente também faz uma verificação semelhante para o certificado do servidor que recebe no Server Hello. No Windows, você pode ver os repositórios de certificados do cliente e do servidor via PowerShell. Execute o abaixo em um console do PowerShell.

Certificado PS:> ls Localização: CurrentUser StoreNames: {TrustedPublisher, ClientAuthIssuer, Root, UserDS ...}

Local: LocalMachine StoreNames: {TrustedPublisher, ClientAuthIssuer, Área de Trabalho Remota, Raiz ...}

Navegadores como Firefox e Opera não contam com o SO subjacente para gerenciamento de certificados. Eles mantêm seus próprios armazenamentos de certificados separados.

O handshake SSL usa criptografia de chave pública e simétrica. A autenticação do servidor acontece por padrão. A autenticação do cliente é opcional e depende se o terminal do servidor está configurado para autenticar o cliente ou não. Consulte minha postagem no blog, como expliquei isso em detalhes.

Finalmente para esta pergunta

Como o protocolo HTTPS reconhece o certificado? Por que o HTTP não pode funcionar com certificados quando são os certificados que funcionam com toda a confiança / criptografia / autenticação?

Certificados é simplesmente um arquivo cujo formato é definido pelo padrão X.509 . É um documento eletrônico que comprova a identidade de uma parte que se comunica. HTTPS = HTTP + SSL é um protocolo que define as diretrizes sobre como as duas partes devem se comunicar.

MAIS INFORMAÇÕES

  • Para entender os certificados, você precisará entender o que são certificados e também ler sobre o Gerenciamento de Certificados. Isso é importante.
  • Depois que isso for entendido, continue com o handshake TLS / SSL. Você pode consultar as RFCs para isso. Mas eles são um esqueleto que define as diretrizes. Existem vários posts no blog, incluindo o meu, que explicam isso em detalhes.

Se a atividade acima for concluída, você terá um entendimento justo de Certificados e SSL.

Kaushal Kumar Panday
fonte