Descodificador de OCSP (resposta e pedido)

Como usar

1. Solte o ficheiro .der ou cole a resposta em base64, PEM ou como despejo hexadecimal de uma captura. Tudo é analisado na página.
2. Veja primeiro o estado da resposta. Qualquer valor diferente de successful é uma resposta completa e sem assinatura que não informa sobre nenhum certificado.
3. Percorra a tabela de estado: good, revoked ou unknown, com o thisUpdate e o nextUpdate ao lado, e a data e o motivo da revogação quando existem.
4. Repare na linha de validade e no instante de referência ao lado. Uma resposta passada do nextUpdate é aquela que um cliente conforme recusaria.
5. Cole na última caixa o pedido que enviou para confirmar o eco do nonce e veja na secção de certificados se o respondedor delegado tem id-kp-OCSPSigning.

Perguntas frequentes

A minha resposta tem apenas seis bytes. Está truncada?

Quase de certeza que não. Uma OCSPResponse é uma SEQUENCE cujo primeiro campo é o estado, e os bytes de resposta que se seguem só existem quando esse estado é successful. Por isso malformedRequest, internalError, tryLater, sigRequired e unauthorized são respostas completas em cinco ou seis bytes: sem assinatura, sem producedAt e sem mencionar qualquer certificado. O tryLater em particular é o que um respondedor sobrecarregado devolve, e o cliente deve tentar de novo em vez de o tratar como falha. Se guarda respostas para stapling, guardar uma destas é o próprio erro.

Porque é que o CertID ainda usa SHA-1? Isso é uma fraqueza?

Porque identifica em vez de autenticar. Um CertID é o hash do nome do emissor, o hash da sua chave pública e o número de série do certificado: uma chave de pesquisa para o respondedor encontrar a entrada certa. O que protege a resposta é a assinatura sobre o conjunto, não esse hash. Um ataque de colisão exigiria dois emissores com o mesmo hash de nome, o mesmo hash de chave e o mesmo número de série, e não daria ao atacante nada que não obtivesse mais facilmente por outra via. É por isso que a RFC 6960 mantém aqui o SHA-1. Já uma assinatura SHA-1 sobre a resposta é um problema a sério, e este descodificador assinala-o à parte.

A resposta não tem nextUpdate. Quando é que expira?

Formalmente, nunca. A RFC 6960 diz que, na ausência de nextUpdate, há informação mais recente disponível a todo o momento e a resposta pode ser usada até ser substituída. Na prática cada cliente aplica um limite próprio, mas muitos aceitam-na enquanto ela se deixar analisar, que é exatamente a janela procurada por um ataque de repetição. É esse o interesse do nonce: com ele, uma resposta capturada não serve para uma pergunta posterior, porque fica ligada a um valor escolhido pelo cliente.

O respondedor descartou o meu nonce. A resposta é inválida?

Não, e esta é a surpresa mais comum ao depurar. As grandes AC públicas pré-calculam respostas em lote e servem-nas a partir de um CDN, o que é incompatível com devolver um nonce diferente por pedido, e por isso simplesmente omitem-no; a RFC 8954 até permite que um respondedor ignore a extensão. A resposta continua válida: o que se perde é a prova de que foi feita para o seu pedido, e a validade passa a depender do thisUpdate e do nextUpdate. Cole o seu pedido nesta ferramenta e ela dirá se o nonce voltou, foi descartado ou voltou diferente, que é o caso que realmente significa estar a olhar para a resposta à pergunta de outra pessoa.

Qual é a diferença entre unknown e uma resposta que nada diz?

unknown é uma resposta a sério: este respondedor não tem registo desse número de série, quase sempre porque o certificado foi emitido por uma AC diferente da que o CertID nomeia, ou porque nunca existiu. Não é o mesmo que good e um cliente não o deve tratar como tal. Também não é o mesmo que unauthorized, que diz que o respondedor não vai responder por aquele certificado. E se a resposta trouxer a extensão extended-revoke o sentido estreita-se: um respondedor desses devolve revoked, com data no início de 1970, para certificados que nunca emitiu, pelo que o seu unknown se aproxima de «fora do meu âmbito».

Esta ferramenta diz-me de que certificado fala a resposta, ou verifica a assinatura?

A primeira coisa não, e a segunda não a promete. O CertID é um conjunto de hashes mais um número de série, e os hashes não se percorrem ao contrário, pelo que a única forma de ligar uma resposta a um certificado é calcular o hash do nome e da chave do emissor desse certificado e comparar — ou seja, é preciso já ter o certificado. Verificar a assinatura exige a chave pública do emissor, que esta página não tem nem procura, por isso o que aparece é uma leitura fiel dos bytes e não uma decisão de confiança. O que os bytes já resolvem é quem assinou: comparar o hash da chave de cada certificado incluído com o issuerKeyHash do CertID distingue a AC emissora de um respondedor delegado.

Ferramentas relacionadas