Privacidade do OCSP: o respondedor vê um certificado, não o seu URL

Uma verificação de estado faz uma pergunta sobre um certificado, e a resposta viaja na sua própria ligação. Não contém o caminho da página que levou à verificação. As discussões sobre privacidade tratam frequentemente a troca como um feed do histórico de navegação, o que exagera o que o pedido transporta e subestima o que o respondedor pode observar. Leia o pedido antes de decidir o que ele revela.

O pedido identifica um certificado

O identificador de certificado OCSP é construído a partir de uma função hash, dois hashes do emissor e o número de série do certificado alvo, como especifica a RFC 6960. Cada campo aponta para um certificado, não para um URL ou um pedido HTTP.

O caminho da página, a cadeia de consulta e qualquer conteúdo de formulário estão ausentes do identificador padrão. A afirmação de que o respondedor recebe o URL exato exige provas de outro lugar que não a verificação do certificado. O pedido ainda nomeia um certificado e um momento, e o respondedor pode saber que serviço o apresenta.

O que falta é a página, não todo o contexto. Uma verificação de certificado mais um serviço conhecido mais uma fonte repetida podem ser mais informativas do que qualquer uma delas isoladamente.

O que o respondedor pode realmente observar

O respondedor vê a ligação que o alcança: endereço de origem, temporização e quaisquer metadados de transporte que a sua implantação registe. Se o pedido de estado seguir a VPN, essa origem pode ser a saída da VPN em vez da rede de acesso do utilizador. Não assuma que o pedido de estado segue o mesmo caminho do pedido da página só porque ambos pertencem à mesma sessão do navegador.

Verifique o encaminhamento e o comportamento de verificação suportados pelo cliente em vez de os inferir de um único rasto. Um túnel dividido pode enviar os dois pedidos em direções diferentes.

A resposta agrafada é o outro padrão comum. A extensão TLS status_request da RFC 6066 permite que um servidor anexe uma resposta OCSP ao seu próprio handshake, pelo que o cliente valida o que lhe foi dado em vez de obter ele próprio o estado para essa ligação. Essa mudança altera o observador. É o lado do servidor que faz a obtenção, e o endereço próprio do cliente nunca chega ao respondedor para essa ligação.

O estado pode chegar agrafado no handshake

Nada disto garante que um cliente nunca faça outro pedido de validação. A construção da cadeia, a política de estado e os mecanismos suportados variam conforme a implementação.

Um visualizador de certificados num navegador não descreve cada sistema operativo e cliente de VPN. A mesma captura de rede pode significar coisas diferentes com definições de verificação diferentes.

A cache quebra a suposição de uma página por consulta

A cache desacopla os carregamentos de página das consultas. O navegador pode reutilizar uma resposta durante um período, pelo que uma visualização de página não implica um pedido de rede.

O erro oposto é igualmente comum. Uma resposta em cache não diz nada sobre quando ocorrerá a próxima atualização, e o calendário de atualização pode não ter relação com a página que está a ser aberta. Use a documentação atual do cliente e a política de verificação em vigor antes de atribuir uma captura ao OCSP.

Uma resposta de estado válida tem de cumprir as regras de autenticidade e frescura do verificador, e um HTTP 200 não é o mesmo que um bom estado. Um tempo limite não é uma revogação. Esses resultados levam a comportamentos distintos do cliente e não devem ser reduzidos a um único erro.

Escolhas de privacidade que mantêm a validação intacta

Quando a própria consulta é sensível, discuta as opções de entrega e cache suportadas com o proprietário do sistema. Não o resolva desativando a verificação de revogação ou a validação da cadeia.

Um rasto mais silencioso não é uma ligação mais segura. Mantenha intactos a identidade do par, a validação da cadeia e a política de revogação pretendida, e altere o caminho de entrega apenas através de uma opção suportada pela implantação. Registe qual opção foi escolhida e quem é responsável por ela.

Quando uma consulta aparece inesperadamente, nomeie o recetor, a rota e a operação de certificado separadamente. Um download do emissor, uma consulta de estado e o pedido da página são três eventos. Tratá-los como um só torna a revisão de privacidade imprecisa e esconde que parte aprendeu realmente algo. Comece pelos campos do protocolo e avance para fora até ao caminho de rede.