A consulta saiu do navegador; o trabalho ficou: a divisão criada pelo OCSP stapling

Resumo

• Ao anexar uma resposta OCSP assinada à negociação TLS, o servidor podia evitar uma consulta adicional do cliente. Ele transportava a prova, mas não passava a controlar a autoridade que a emitia.
• A resposta reutilizável precisava continuar recente e corresponder ao certificado apresentado. Declarar a função no certificado tornava sua ausência verificável por clientes compatíveis, mas também exigia coordenar certificado, resposta e implantação.

A economia que deixa uma tarefa

Há duas maneiras muito diferentes de descrever uma consulta que deixou de acontecer. Ela pode ter se tornado desnecessária porque alguém preparou a resposta de antemão. Ou pode simplesmente ter sido abandonada. OCSP stapling pertence à primeira ideia, desde que a resposta entregue realmente satisfaça a verificação do cliente.

Em vez de abrir outra conexão para buscar o estado de um certificado, o cliente podia recebê-lo do próprio servidor. O visitante economizava uma ida ao serviço de estado. O operador, porém, precisava obter respostas utilizáveis, mantê-las atualizadas e distribuí-las com o certificado certo. A ausência de tráfego no navegador não demonstrava ausência de dependência no sistema.

Essa é a questão histórica interessante: como uma tarefa executada durante cada visita podia se transformar em uma obrigação contínua de quem atendia as visitas, sem entregar a esse operador o direito de definir a resposta.

Uma assinatura que não pertencia ao mensageiro

O servidor estava sob exame e, ao mesmo tempo, entregava a evidência. Isso só fazia sentido porque a resposta OCSP tinha assinatura própria. Sua validade não decorria da boa vontade do transportador.

RFC 6960 exigia verificar a correspondência com o certificado consultado, a assinatura, a autoridade de quem assinou e a atualidade da informação. A CA emissora, um respondedor expressamente confiável ou um respondedor devidamente designado podiam exercer esse papel. A posse da chave TLS comum de um site não concedia, por si só, autoridade para assinar estados OCSP.

Nem uma resposta good resolvia todas as perguntas. O significado mínimo desse estado não provava necessariamente que o certificado tivesse sido emitido. Não atestava a segurança do conteúdo do site nem substituía a validação da cadeia e os demais critérios de aceitação.

O desenho preservava três decisões: produzir uma declaração autorizada, transportá-la e decidir se ela bastava. A mesma empresa podia ocupar mais de uma posição, mas o protocolo não precisava tratá-las como uma autoridade única.

O caminho começou a encurtar em 2003

O pedido status_request já aparecia na RFC 3546, de junho de 2003. O servidor podia enviar uma resposta OCSP logo após o certificado. A especificação mencionava redes limitadas, o custo de transmitir listas de revogação e a redução de idas e voltas.

A RFC 6066, de janeiro de 2011, descreveu a extensão no contexto posterior de TLS. Naquele formato, um CertificateStatus separado carregava a resposta completa codificada. Não era a negociação TLS que produzia uma nova declaração de estado, e 2011 não era a origem do mecanismo.

Uma resposta adequada podia eliminar a conexão adicional do visitante com um terceiro. Havia, portanto, uma vantagem específica de privacidade: aquela consulta não precisava revelar mais informação ao serviço externo. Isso não tornava toda a navegação anônima. Tampouco dispensava o respondedor de continuar fornecendo o material que o servidor usaria no futuro.

A validade da assinatura não mede a idade da informação

A RFC 5019, publicada em setembro de 2007, definiu um perfil leve voltado à produção antecipada, distribuição e cache. Uma resposta já preparada podia atender novas verificações sem ser refeita para cada cliente.

Mas o reaproveitamento precisava de relógio. thisUpdate indicava quando o estado comunicado era conhecido como correto; producedAt, quando a resposta fora assinada; nextUpdate, quando informação mais nova estaria disponível, no máximo. Assinar mais tarde não significava ter observado um estado mais recente.

O perfil leve exigia nextUpdate e verificação temporal com uma fonte de tempo precisa. O OCSP básico admitia a ausência desse campo. É importante não transformar a exigência de um perfil em uma regra universal. Da mesma forma, cabeçalhos HTTP de cache sem proteção da assinatura não podiam, sozinhos, estender o período aceitável da resposta.

Se o respondedor ficasse inacessível, uma resposta ainda aceitável em cache podia oferecer algum fôlego. Esse fôlego acabava quando a informação deixava de cumprir as regras do cliente. Uma revogação posterior não reescrevia todas as cópias de um antigo good. O ganho de escala vinha acompanhado de uma diferença inevitável entre o momento conhecido e o momento de uso.

O silêncio precisava de contexto

Solicitar a extensão não equivalia a receber uma promessa de resposta. O mecanismo era opcional e o servidor podia deixar de anexar o estado. Isso tanto podia refletir falta de suporte quanto a intenção de não apresentar uma evidência desfavorável.

As considerações de segurança da RFC 6066 alertavam para um atacante com uma chave comprometida fingindo não oferecer a função. Um cliente que exigisse validação OCSP deveria consultar o respondedor diretamente ou encerrar a tentativa. Já uma resposta recebida e insatisfatória exigia abortar a negociação. Ausência, estado desconhecido, expiração e revogação eram situações diferentes.

A RFC 7633, de outubro de 2015, permitiu declarar status_request na extensão X.509 TLS Feature do certificado. Essa é a base do mecanismo conhecido como Must-Staple. Um cliente compatível podia comparar o comportamento do servidor com uma expectativa autenticada, em vez de depender da explicação do próprio servidor.

A regra não garantia comportamento uniforme de todos os clientes: o documento não exigia implementar cada função e preservava alternativas de validação. Ainda assim, o servidor que apresentasse a declaração precisava sustentá-la. A recomendação de não ativar um certificado novo antes de existir seu estado OCSP tratava de uma falha concreta: certificado legítimo e serviço funcionando, mas prova exigida ainda indisponível.

A embalagem mudou depois

Na RFC 8446, de 2018, TLS 1.3 passou a levar o estado em uma extensão da entrada do certificado correspondente. Não era mais o antigo CertificateStatus separado. O novo lugar não transferia ao servidor a autoridade de assinatura nem dispensava o exame da idade da resposta.

Essa continuidade resume a contribuição do stapling. Uma prova independente podia circular por uma parte interessada e reduzir uma dependência durante a conexão. Mas produzir, renovar e verificar a prova continuavam sendo tarefas distintas. As RFCs documentam esse acordo técnico, não a adoção atual de cada navegador ou CA.

Fontes

RFC 3546, RFC 6066, RFC 6960, RFC 5019, RFC 7633 e RFC 8446. A interpretação sobre responsabilidades deriva dos requisitos; não é uma medição de práticas de mercado.