Resumo
- O staple responde sobre um CertID em tempos definidos. A assinatura prova quem tinha autoridade para falar, não que conhecia toda revogação posterior ou produziu a resposta para este handshake.
producedAt,thisUpdateenextUpdatesão relógios diferentes; coleta, idade HTTP, instalação, relógio do cliente e idade máxima também precisam ficar visíveis.- TLS transporta evidência. O cliente atribui a consequência, combinando identidade, delegação, status, tempo, cache, posição na cadeia, Must-Staple e política de falha.
O good que atravessou um evento vermelho
O respondedor assinou às 09h55; o servidor buscou às 09h57; a revogação entrou às 10h07. A cópia entregue quatro minutos depois continuava criptograficamente íntegra. Isso não poderia fazê-la conhecer um evento posterior.
RFC 6960 limita good: no mínimo, não consta como revogado um certificado vigente com aquele serial. CertID fixa a pergunta por hashes do emissor, serial e algoritmo. Resposta para outro serial ou para outra posição da cadeia não é evidência parcial; é outra pergunta.
A resposta definitiva deve vir do emissor ou de respondedor explicitamente autorizado. Uma assinatura correta sem delegação não tem autoridade. Uma assinatura autorizada pode refletir informação anterior. Preservar CertID, certificado do respondedor, delegação, assinatura, hash bruto e posição na cadeia evita que “OCSP ok” apague essa diferença.
Tempo assinado e tempo operacional
producedAt é quando a resposta foi assinada; thisUpdate, quando o estado era conhecido como correto; nextUpdate, até quando informação nova será disponibilizada. RFC 6960 permite produção antecipada e RFC 9919 incorpora cache e exige nextUpdate em seu perfil.
O sistema acrescenta revogação, ingestão, Date/Age HTTP, obtenção, revalidação, instalação, handshake e relógio do cliente. Tolerância de relógio não cria frescor. thisUpdate futuro demais, nextUpdate vencido ou idade local excedida são motivos distintos.
O cache reduz latência e exposição de navegação e tira o respondedor do caminho crítico. Date, Expires, ETag e Cache-Control regem reutilização. O servidor deve guardar origem, cabeçalhos, hash, coleta, revalidação, instalação e prazo de renovação. Carregar uma resposta válida no início não prova que a atualização continuou.
Nonce, TLS e Must-Staple
Nonce liga uma solicitação à resposta. Um staple compartilhado não costuma carregar um nonce novo por cliente; sua atualidade depende do intervalo assinado, limite de idade e renovação. Novo handshake não significa nova produção.
Até TLS 1.2, o cliente oferece status_request e o servidor pode enviar CertificateStatus; TLS 1.3 associa status às entradas de certificado. A atribuição IANA prova o código, não o uso ou a aceitação.
Presença não é validade: BoringSSL oferece bytes brutos sem garantir que estejam bem formados; OpenSSL separa pedido, instalação e leitura. Ausência também pode ser falta de pedido, sessão retomada sem certificados, recusa do servidor ou soft fail.
Must-Staple governa a omissão: se o certificado exige e o cliente pede, ele pode rejeitar a falta. Não há execução universal, e uma resposta presente ainda falha por CertID, delegação, assinatura, tempo, unknown ou revoked.
O controle está no código em execução
TLS 1.3 pode associar respostas a mais de um certificado; versões anteriores costumam oferecer uma só para a folha. Quantidade e posição precisam sobreviver aos logs. Uma retomada sem troca de certificado não deve ser contada como nova observação OCSP.
OpenSSL separa busca de CertID, leitura do estado, checagem de tempo com desvio/idade máxima e verificação do signatário. GnuTLS integra a validação, mas requer renovação periódica e possível troca de credenciais. BoringSSL recomenda buscar e atualizar antes do handshake, evitando rede síncrona.
Testes devem cobrir serial errado, respondedor sem autorização, thisUpdate futuro, nextUpdate vencido, resposta antiga sem limite, bytes quebrados, staple obrigatório ausente, cadeia parcial, retomada mal contabilizada, renovador parado e relógio revertido. Se o respondedor cair, cache ainda aceitável deve sustentar o serviço até a fronteira definida pela política.
Fontes
- https://www.rfc-editor.org/rfc/rfc6960.html
- https://www.rfc-editor.org/rfc/rfc9919.html
- https://www.rfc-editor.org/rfc/rfc8954.html
- https://www.rfc-editor.org/rfc/rfc6066.html
- https://www.rfc-editor.org/rfc/rfc9846.html
- https://www.rfc-editor.org/rfc/rfc7633.html
- https://www.rfc-editor.org/rfc/rfc9325.html
- https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
- https://docs.openssl.org/3.6/man3/SSL_CTX_set_tlsext_status_cb/
- https://docs.openssl.org/3.6/man3/OCSP_resp_find_status/
- https://www.gnutls.org/manual/html_node/OCSP-stapling.html
- https://www.gnutls.org/manual/html_node/OCSP-API.html
- https://boringssl.googlesource.com/boringssl/+/refs/heads/main/include/openssl/ssl.h
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
