Introdução
Quando um usuário visita seu site HTTPS, ele deve responder com um chave públicae um certificado SSL válido associando a chave à sua identidade, como pessoa, empresa ou organização. Os certificados são sempre emitidos com uma data de expiração predefinida que está incluída no próprio certificado assinado, e os navegadores sempre verificam a data de expiração e rejeitarão qualquer certificado expirado.
No entanto, em certos casos, um certificado deve ser marcado como inválido (e a confiança nesses certificados deve ser revogou) antes expira. Exemplos comuns incluem um proprietário de servidor que tem evidências (ou simplesmente suspeita) de que sua chave privada foi comprometida (ou seja, foi perdida, roubada ou destruída), uma vez que terceiros que mantêm essa chave privada podem basicamente ignorar todos os controles de segurança de rede do navegador.
Como conseqüência, os fornecedores de navegadores exigiram publicamente confiável autoridades de certificação (CAs) para implementar pelo menos um método para revogar certificados problemáticos e notificar os navegadores para rejeitar esses certificados revogados.
Um breve histórico dos (problemas da) verificação de revogação
Nos primeiros dias do SSL, o método usado pelas CAs era publicar seu status de revogação de certificado em documentos acessíveis ao público chamados listas de revogação de certificado (CRL) Uma CRL é simplesmente uma lista de todos os certificados que uma CA revogou antes da expiração. As autoridades de certificação publicavam periodicamente a versão mais recente de suas CRLs, que os navegadores eram obrigados a consultar antes cada conexão HTTPS.
Naturalmente, como HTTPS (e SSL /TLS) a adoção aumentou ao longo dos anos, assim como o tamanho das CRLs publicadas. A necessidade de baixar e analisar uma grande CRL antes de cada conexão impôs uma sobrecarga de rede cada vez maior. Rapidamente se tornou aparente que o método CRL não escalou bem.
Para mitigar esses problemas de dimensionamento, navegadores e autoridades de certificação projetaram e implementaram o Protocolo de status de certificado online (OCSP) CAs publicamente confiáveis, como SSL.com, agora mantenha servidores HTTP simples chamados Respondentes OCSP. Agora, os navegadores podem entrar em contato com um respondedor para solicitar o status de revogação de um único certificado emitido pela CA, em vez de precisar adquirir e processar toda a CRL.
Os respondentes OCSP assinam suas respostas com a chave de assinatura privada do CA e os navegadores podem verificar se o status de revogação que receberam foi realmente gerado pelo CA real.
Infelizmente, embora o OCSP parecesse uma solução eficaz a princípio, o novo protocolo provou ter alguns problemas práticos de desempenho, segurança e privacidade.
Problemas de desempenho
Entrar em contato com um respondedor para cada certificado encontrado pelo navegador significa que os navegadores precisam executar uma solicitação HTTP adicional para cada nova conexão HTTPS. Essa sobrecarga de rede era perceptível para os usuários, especialmente em páginas contendo conteúdo de terceiros armazenados em servidores remotos de distribuição de conteúdo (em que cada um pode ter um ou mais certificados em vigor).
Capacidade de Resposta é um princípio essencial do bom design da interface do usuário. Atrasos prolongados podem ser uma das principais causas de frustração do usuário e podem levar os usuários a acreditar que seu site não está funcionando ou que o gesto de entrada foi ignorado.
Além do mais, muitos caso no passado, vinculavam a velocidade de carregamento da página e a capacidade de resposta com SEO aprimorado e taxas de conversão maiores. De fato, a Amazon calculou que um atraso de apenas um segundo pode custar cerca de $1.6 bilhão anual.
(Para obter mais detalhes sobre como a velocidade de carregamento da página afeta seu site e sobre as otimizações sugeridas, consulte nosso artigo descrevendo como a remoção de conteúdo misto do seu site melhorará seu desempenho.)
Questões de segurança
Também existem importantes preocupações de segurança com o OCSP. O fato de a maioria das implementações práticas de OCSP não serem confiáveis o suficiente (devido a atraso na rede ou erros de configuração ou aplicativo) motivou navegadores e outro software cliente a implementar a verificação do OCSP falha suave modo.
Isso significa que, se um servidor OCSP não puder ser alcançado ou atingir o tempo limite enquanto estiver respondendo, os navegadores irão considere o certificado como válido e continue com a conexão HTTPS de qualquer maneira.
O raciocínio por trás disso é que, como um servidor OCSP pode potencialmente atender a milhões de sites e é possível que um servidor OCSP falhe a qualquer momento, interromper a conexão em todas as falhas do OCSP prejudicaria a experiência de navegação de milhões de usuários. Mesmo que o servidor OCSP esteja em operação, mas demore muito tempo para responder, isso aumenta o atraso e a frustração do usuário.
O homem do meio (MITM) Sabe-se que os invasores exploram esse comportamento bloqueando todos os conexões com respondentes OCSP, o que efetivamente significa que eles podem usar um certificado roubado e um par de chaves para um site malicioso, independentemente do status de revogação do certificado.
Questões de privacidade
Por fim, como um certificado está vinculado a uma chave e a um nome de domínio, e os navegadores solicitam o status de revogação antes de cada nova conexão HTTPS, isso significa que os navegadores vazam uma parte significativa do histórico da web de seus usuários para respondentes OCSP.
Obviamente, CAs de confiança pública não são organizações maliciosas que procuram comprometer a privacidade do usuário. (CAs respeitáveis estão sempre tentando ativamente proteger segurança e privacidade de seus usuários.) No entanto, no caso de comprometimento de um respondente OCSP da CA, os dados trocados com esse servidor não confiável podem levar à divulgação de informações confidenciais e privadas.
OCSP grampeamento para o resgate
Para atenuar esses problemas, navegadores e CAs criaram um novo método para determinar o status de um certificado, chamado Grampeamento OCSP. O grampeamento OCSP permite que servidores Web (em vez de navegadores) obtenham respostas OCSP assinadas para seus certificados, que podem ser armazenados em cache por até 7 dias.
Servidores incluem (ou grampo) a resposta OCSP em cache em suas respostas HTTPS junto com o próprio certificado SSL. Dessa forma, os navegadores podem verificar a assinatura das CAs na resposta do OCSP e ter certeza de que o certificado não foi revogado, antes que a conexão segura seja estabelecida e sem ter que realizar a solicitação adicional cara ao servidor OCSP.
O grampeamento OCSP é uma solução simples, mas muito eficaz para os problemas mencionados acima. Os servidores podem recuperar as respostas do OCSP em cache em seu próprio tempo, o que remove a sobrecarga de desempenho imposta pelas CRLs e pelo OCSP, bem como as preocupações de privacidade que as acompanham.
No entanto, o grampeamento OCSP por si só não resolve completamente o problema de segurança de falha suave do OCSP. Como o grampeamento é implementado no servidor, os navegadores não podem saber se um servidor realmente suporta grampeamento ou não.
Como consequência, os invasores MITM com um certificado roubado (mas revogado) podem realizar um ataque de downgrade servindo o certificado sem grampeamento OCSP. O navegador de uma vítima não é capaz de corroborar se o servidor realmente suporta grampeamento e continuar a consultar o respondente do OCSP como faria normalmente.
Os invasores do MITM podem simplesmente bloquear essa consulta do OCSP e efetivamente forçar os navegadores a aceitar o certificado como válido.
Grampo obrigatório OCSP
Este ataque motivou CAs e fornecedores de navegadores a introduzir uma extensão para certificados SSL, definidos em RFC 7633, comumente chamado OCSP Obrigatório (embora o próprio RFC não mencione esse nome, o que pode causar alguma confusão.) Isso simplesmente exige o grampeamento OCSP para o certificado. Se um navegador encontrar um certificado com esta extensão usado sem grampeamento OCSP, ele será rejeitado. O OCSP Must-Staple atenua o ataque de downgrade mencionado acima e também reduz o tráfego desnecessário para os respondentes OCSP da CA, o que também pode ajudar a melhorar o desempenho geral do OCSP.
Se você estiver interessado em ativar a extensão OCSP Must-Staple em seus certificados, entre em contato com um de nossos agentes de suporte em support@ssl.com para mais detalhes.
Habilite o grampeamento OCSP no seu servidor
Para poupar o trabalho de procurar isso, as seções a seguir contêm instruções sobre como habilitar o grampeamento OCSP no seu apache e nginx ambientes:
apache
Para ativar o grampeamento OCSP no seu apache servidor, adicione as seguintes linhas no arquivo de configuração do seu servidor.
# OCSP Grampeamento, apenas em httpd 2.3.3 e posterior SSLUseStapling em SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
nginx
Para ativar o grampeamento OCSP no seu nginx servidor, adicione o seguinte texto no arquivo de configuração do seu servidor.
# Grampeamento OCSP --- # busca registros OCSP da URL em ssl_certificate e armazená-los em cache ssl_stapling on; ssl_stapling_verify on;
Conclusão
A web é uma intrincada rede de componentes interdependentes, todos (geralmente) trabalhando em harmonia para fornecer uma experiência de navegação contínua. A complexidade cada vez maior desse sistema, no entanto, cria uma superfície de ataque cada vez maior e permite que novos ataques à rede sejam planejados e executados.
O grande número de componentes naturalmente aumenta a latência e gera atrasos, o que significa que as empresas precisam encontrar maneiras de melhorar a segurança sem afetar a experiência do usuário. A ativação do grampeamento OCSP lhe dará essa rara oportunidade de melhorar a segurança e desempenho para o seu site ao mesmo tempo.
Como sempre, estamos felizes em responder às suas perguntas sobre grampeamento OCSP ou outros problemas. Basta enviar um e-mail para support@ssl.com.
