Resumo

  • OCSP stapling leva ao handshake TLS uma evidência assinada sobre o status do certificado e elimina uma consulta adicional do cliente ao respondedor.
  • O estado good tem alcance deliberadamente restrito, enquanto thisUpdate, nextUpdate e producedAt delimitam a afirmação no tempo.
  • Assinatura válida e janela ainda aceitável não revelam quando cada borda obteve a resposta nem se informação posterior de revogação foi instalada em toda a frota.
  • A operação precisa de um registro verificável que mostre quão recente é o status de revogação e ligue certificado e respondedor aos horários do status, à obtenção, à coorte implantada e ao momento da decisão.

Considere um caso hipotético, sem atribuí-lo a um fornecedor ou incidente real. Uma autoridade certificadora produz uma resposta OCSP assinada com status good, e uma borda a guarda em cache. Depois, o certificado é revogado. Outra borda recebe uma resposta nova, enquanto a primeira continua apresentando a anterior dentro da janela indicada. O cliente pode validar corretamente esse objeto mais antigo e ainda assim não obter a prova necessária para a afirmação operacional de que “a revogação já vigora em todos os lugares”.

O limite está no próprio protocolo. O RFC 6960 define o OCSP como meio de consultar o status de um certificado sem buscar uma lista completa de revogações. Respostas definitivas são assinadas, identificam o respondedor e trazem o status de um certificado determinado. É evidência forte, mas continua sendo uma afirmação sobre um objeto, um emissor e um intervalo específicos.

good é particularmente fácil de interpretar além do que permite. Em seu sentido mínimo, indica que nenhum certificado com o número de série consultado e dentro do período de validade consta como revogado. A norma restringe imediatamente a conclusão: isso não demonstra necessariamente que o certificado foi emitido nem que a resposta foi produzida durante a validade do certificado. Extensões podem acrescentar informações, mas o status básico não comprova, por si só, a legitimidade simultânea do certificado, do servidor e da conta, nem identifica quem controla o serviço naquele momento.

Três horários mostram a fronteira. thisUpdate é o momento mais recente em que o respondedor sabia que o estado indicado estava correto. nextUpdate é o limite até o qual haverá informação nova. producedAt registra quando a resposta foi assinada. Eles não são equivalentes. Uma resposta recém-assinada pode descrever um estado conhecido antes, e um nextUpdate futuro não prova que um evento posterior já se propagou a todos os caches e pontos de terminação.

Antes de aceitar a resposta, o cliente que valida a resposta precisa conferir o certificado consultado, validar a assinatura e a autoridade do respondedor, considerar thisUpdate suficientemente recente e, quando presente, verificar que nextUpdate esteja no futuro. Esses controles mostram autenticidade e aceitabilidade segundo a política local. Não registram o caminho de distribuição até o servidor que apresentou o objeto.

O RFC 6066 descreve a extensão TLS status_request, pela qual o servidor pode enviar a resposta OCSP junto do certificado. O cliente dispensa uma conexão separada ao respondedor e deve interromper o handshake se a resposta recebida não for satisfatória. OCSP stapling melhora a entrega da evidência; não aumenta o que ela afirma.

Em um serviço distribuído, o mesmo certificado pode estar em diversas entradas, regiões ou grupos de terminação. Cada grupo pode obter, armazenar e trocar respostas por caminhos diferentes. O objeto OCSP registra o conhecimento e os tempos do respondedor, não a lista completa de bordas, a revisão de configuração, a última tentativa de obtenção ou a confirmação da substituição. “A resposta OCSP é validada” e “o estado mais recente está em todas as bordas” são afirmações distintas.

O RFC 7633 permite declarar no certificado uma função TLS exigida, como status_request. Um cliente compatível pode rejeitar uma configuração que não forneça o status esperado. Nos casos definidos pela norma, porém, a validação ainda pode recorrer a outra fonte. Must-Staple torna a ausência da evidência acionável, mas não torna uma resposta antiga mais nova, não evita toda emissão indevida e não prova quem controla atualmente a aplicação atrás do certificado.

O erro operacional é reduzir quatro estados a um único sinal verde. A cadeia do certificado pode validar, a assinatura OCSP pode validar e o tempo pode satisfazer a política do cliente; ainda assim, uma borda pode estar atrasada ou fora da coorte que o operador considera atualizada. Um painel que mostra apenas “resposta OCSP presente” não distingue esses casos.

Esse registro deve conservar a cadeia: número de série e cadeia completa do certificado, identidade do respondedor, status, thisUpdate, nextUpdate, producedAt, horário de obtenção, coorte que instalou o objeto, política de validação e momento da decisão. Também deve registrar falhas de substituição e separar autenticação de transporte da autorização atual da aplicação.

Isso não enfraquece OCSP stapling. Ele reduz exposição de privacidade, latência e dependência de uma consulta externa no momento do handshake. Must-Staple pode transformar ausência em falha verificável. Assinatura e tempos autenticam uma afirmação limitada. O problema surge somente quando esses benefícios são convertidos em uma garantia que o objeto não contém.

A decisão, portanto, é definir qual afirmação a resposta OCSP anexada pode satisfazer. Para validar um handshake, uma resposta autêntica e suficientemente recente pode ser decisiva. Para provar que a revogação chegou a todas as bordas, é necessária evidência de implantação. Para autorizar uma ação da aplicação, o serviço deve tomar uma decisão atual de identidade e política, sem tomar emprestada a autoridade do objeto de status.

Fontes

RFC 6960 — Online Certificate Status Protocol; RFC 6066 — extensões TLS; RFC 7633 — extensão TLS Feature.