Introdução
HTTPS (via SSL /TLS) usa criptografia de chave pública para impedir que as comunicações do navegador sejam lidas ou modificadas em trânsito pela Internet. Os servidores fornecem aos navegadores visitantes uma chave pública usada para estabelecer uma conexão criptografada para todas as trocas de dados subsequentes.
No entanto, apenas receber um trabalhar a chave pública sozinha não garante que ela (e, por extensão, o servidor) seja de fato propriedade do controle remoto correto sujeito (ou seja, pessoa, empresa ou organização). Man-in-the-middle os invasores podem manipular redes para servir suas próprias chaves, comprometendo assim qualquer comunicação.
Os navegadores evitam isso autenticando Servidores HTTPS usando certificados, que são documentos digitais que vincular uma chave pública para um assunto individual. A ligação é afirmada por ter um confiável Autoridade de Certificação (CA) como SSL.com verifique a identidade dos possíveis proprietários de certificados, por meio de verificações automatizadas e manuais em bancos de dados qualificados.
Essa relação de confiança significa que a segurança do usuário da web não é absoluta; em vez disso, exige que os usuários confiem nos navegadores e nas CAs para proteger sua segurança. Portanto, acreditamos que é do interesse de cada usuário ter um conhecimento básico de como funciona a validação de certificado.
Observe que o processo de validação de certificado (descrito em detalhes no documento padrão RFC 5280) é bastante complicado. Neste artigo, tentaremos guiá-lo ao longo de um caminho (um navegador que valida o SSL /TLS certificado) e navegue pelos detalhes complexos e irrelevantes para a maioria dos usuários.
Certificados e o formato X.509
Certificados são arquivos digitais em todos os aspectos, o que significa que eles precisam seguir um formato de arquivo para armazenar informações (por exemplo, assinaturas, chaves, emissores, etc.). Enquanto privado PKI configurações podem implementar qualquer formato para seus certificados, publicamente confiáveis PKIs (ou seja, aqueles confiáveis pelos navegadores) devem estar em conformidade com a RFC 5280, que requer o uso do X.509 v3 formato.
O X.509 v3 permite que os certificados incluam dados adicionais, como restrições de uso ou informações de política, como extensões, com cada extensão sendo crítico or não crítico. Os navegadores podem ignorar extensões não críticas inválidas ou não reconhecidas, mas são necessárias para processar e validar todas as críticas.
Caminhos de certificação e processamento de caminhos
As autoridades de certificação usam uma chave privada para assinar criptograficamente todos os certificados emitidos. Essas assinaturas podem provar irrevogavelmente que um certificado foi emitido por uma CA específica e que não foi modificado depois de assinado.
Essa sequência de certificados é chamada de caminho de certificação. A raiz do caminho é chamada de âncora de confiança e o certificado do servidor é chamado de folha or entidade final certificado.
Construção de Caminho
Freqüentemente, os navegadores precisam considerar vários caminhos de certificação até que possam encontrar um válido para um determinado certificado. Mesmo que um caminho possa conter certificados que “encadeiam” corretamente em uma âncora conhecida, o caminho em si pode ser rejeitado devido a restrições no comprimento do caminho, nome de domínio, uso de certificado ou política.
Construir e avaliar todos os caminhos possíveis é um processo caro, executado para cada novo certificado que um navegador encontra. Os navegadores implementaram várias otimizações para minimizar o número de caminhos de candidatos rejeitados, mas investigar esses detalhes está muito além do escopo deste artigo.
Validação de caminho
Depois que um caminho de certificação do candidato é construído, os navegadores o validam usando as informações contidas nos certificados. Um caminho é válido se os navegadores puderem provar criptograficamente que, partindo de um certificado assinado diretamente por uma âncora de confiança, a chave privada correspondente de cada certificado foi usada para emitir a próxima no caminho, até o certificado folha.
Algoritmo de validação de caminho de certificação
A RFC 5280 descreve uma algoritmo padrão que os navegadores seguem para validar um caminho de certificação de certificados X.509.
Basicamente, os navegadores iteram todos os certificados no caminho, começando com a âncora de confiança (ou seja, o certificado raiz), validando as informações básicas e extensões críticas de cada certificado.
Se o procedimento for concluído com o último certificado no caminho sem erros, o caminho será aceito como válido. Se forem produzidos erros, o caminho é marcado como inválido.
Processamento básico de certificados
Independentemente de qualquer extensão, os navegadores sempre devem verificar as informações básicas do certificado, como a assinatura ou o emissor. As seções a seguir mostram a sequência de verificações executadas pelos navegadores.
1. O navegador verifica a integridade do certificado
O ESB ( assinatura no certificado pode ser verificado usando criptografia de chave pública normal. Se a assinatura for inválida, o certificado será considerado modificado após sua emissão e, portanto, será rejeitado.
2. O navegador verifica a validade do certificado
Um certificado período de validade é o intervalo de tempo durante o qual a CA de assinatura garante que manterá informações sobre seu status. Os navegadores rejeitam todos os certificados com um período de validade que termina antes ou depois da data e hora da verificação de validação.
3. O navegador verifica o status de revogação do certificado
Quando um certificado é emitido, espera-se que ele seja usado por todo o seu período de validade. Obviamente, várias circunstâncias podem tornar um certificado inválido antes de expirar naturalmente.
Tais circunstâncias podem incluir um assunto mudando seu nome ou uma suspeita de comprometimento de sua chave privada. Em casos como esse, uma CA precisa revogar o certificado correspondente e os usuários também confiam em uma CA para notificar os navegadores sobre o status de revogação de seus certificados.
RFC 5280 recomenda que as autoridades de certificação usem listas de revogação para esse fim.
Listas de revogação de certificado (CRL)
As autoridades de certificação emitem periodicamente uma lista assinada e com registro de data e hora de certificados revogados, denominada lista de revogação de certificado (CRL). As CRLs são distribuídas em repositórios publicamente disponíveis, e os navegadores podem adquirir e consultar a CRL mais recente da CA ao validar um certificado.
Uma falha desse método é que a granularidade de tempo da revogação é limitada ao período de emissão da CRL. Um navegador será notificado de uma revogação somente depois que todas as CRLs emitidas atualmente estiverem programadas para serem atualizadas. Dependendo da política da CA de assinatura, isso pode levar uma hora, um dia ou até uma semana.
Protocolo de status de certificado on-line (OCSP)
Existem outros métodos alternativos para adquirir informações de status de revogação, sendo o mais popular o Protocolo de status de certificado online (OCSP).
Descrito no documento padrão RFC6960, OCSP permite que um navegador solicite o status de revogação de um certificado específico de um servidor OCSP online (também chamado de respondedor) Quando configurado corretamente, o OCSP é muito mais imediato e evita o problema de latência de atualização da CRL mencionado acima. Além do que, além do mais, Grampeamento OCSP melhora o desempenho e a velocidade.
4. O navegador verifica o emissor
Os certificados são normalmente associados a duas entidades:
- O ESB ( emissor, que é a entidade proprietária da chave de assinatura e
- O ESB ( sujeito, que se refere ao proprietário da chave pública que o certificado autentica.
Os navegadores verificam se um certificado emissor campo é o mesmo que o sujeito campo do certificado anterior no caminho. Para maior segurança, a maioria PKI as implementações também verificam se a chave do emissor é a mesma que assinou o certificado atual. (Observe que isso não é verdade para a âncora de confiança, uma vez que as raízes são auto-emitidas - ou seja, elas têm o mesmo emissor e assunto.)
Processamento de restrições
O formato X.509 v3 permite que uma CA defina restrições ou restrições sobre como cada certificado é validado e usado como extensões críticas. Todo certificado no caminho pode impor restrições adicionais às quais todos os certificados subsequentes devem obedecer.
As restrições de certificado raramente afetam o usuário médio da Internet, embora sejam bastante comuns em soluções SSL corporativas. As restrições funcionais podem servir a vários propósitos operacionais, mas seu uso mais significativo é mitigar preocupações de segurança conhecidas.
5. O navegador verifica as restrições de nome
Uma CA intermediária de propriedade privada (mas publicamente confiável) com o apropriado restrições de nome pode fornecer a uma organização um controle refinado sobre o gerenciamento e a emissão de certificados. Os certificados podem ser limitados a um domínio específico ou árvore de domínio (ou seja, incluindo subdomínios) para o nome de domínio de uma empresa ou organização. Restrições de nome são frequentemente usadas para certificados de CA intermediários adquiridos de uma CA publicamente confiável para evitar que a CA intermediária emita certificados perfeitamente válidos para domínios de terceiros (por exemplo, google.com
).
6. O navegador verifica as restrições de política
Uma política de certificado é um documento legal publicado por uma CA, detalhando oficialmente os procedimentos a serem seguidos para emitir e gerenciar seus certificados. As autoridades de certificação podem emitir um certificado sob uma ou mais políticas, e os links para eles são incluídos em cada certificado emitido, para que as partes confiáveis possam avaliar essas políticas antes de decidir confiar nesse certificado.
Por razões legais e operacionais, os certificados podem impor restrições às políticas às quais estão sujeitos. Se um certificado contiver restrições críticas de política, os navegadores deverão validá-los antes de continuar. (No entanto, restrições críticas de políticas raramente são encontradas no mundo real e, portanto, serão desconsideradas no restante deste artigo.)
7. O navegador verifica restrições básicas (também conhecidas como comprimento do caminho)
O formato X.509 v3 permite que os emissores definam o comprimento máximo do caminho que um certificado pode suportar. Isso fornece controle sobre até que ponto cada certificado pode ser colocado em um caminho de certificação. Isso é realmente importante - os navegadores costumavam desconsiderar o comprimento do caminho de certificação até que um pesquisador demonstrou, em um 2009 apresentação de negócios, como ele usou o certificado folha de seu site para forjar um certificado válido para um grande site de comércio eletrônico.
8. O navegador verifica o uso da chave
A extensão “uso da chave” declara o propósito da chave contida no certificado. Exemplos de tais finalidades incluem criptografia, assinaturas, assinatura de certificado e assim por diante. Os navegadores rejeitam certificados que violam suas restrições de uso de chave, como encontrar um certificado de servidor com uma chave destinada apenas para assinatura CRL.
9. O navegador continua processando todas as extensões críticas restantes
Depois de processar as extensões mencionadas acima, os navegadores continuam a validar todas as extensões restantes que o certificado atual designa como críticas, antes de passar para o próximo. Se um navegador alcançar o certificado folha de um caminho sem erros, o caminho será aceito como válido. Se algum erro for produzido, o caminho será marcado como inválido e uma conexão segura não será estabelecida.
Conclusão
A World Wide Web é um sistema complexo de partes móveis interconectadas e em constante evolução. A segurança do navegador, portanto, não é um problema resolvido, e esperamos que este artigo tenha fornecido algumas dicas sobre a complexidade até mesmo do único componente que examinamos aqui. A confiança desempenha um papel importante em mantê-lo seguro online e, por esse motivo, recomendamos que você pergunte mais sobre a política de certificados de sua CA. (Sinta-se à vontade para revisar Políticas de SSL.com aqui, de fato.)
Obrigado por escolher SSL.com, onde acreditamos que um mais segura Internet é uma better Internet.