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?
ssl
ssl-certificate
Vicky
fonte
fonte
Respostas:
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 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:
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 .
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 .
fonte
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?
Esse fluxo pode ser representado pelo seguinte diagrama:
fonte
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. "
fonte
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:
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.
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
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
Se a atividade acima for concluída, você terá um entendimento justo de Certificados e SSL.
fonte