O protocolo de status de certificado online (do inglês Online Certificate Status Protocol - OCSP) é um protocolo de Internet usado para obter o status de revogação de um certificado digital X.509.[1] Ele é descrito no RFC 6960 e está no caminho de padrão de Internet. Ele foi criado como uma alternativa para as listas de revogação de certificado (CRLs), abordando especificamente certos problemas associados ao uso de CRLs em uma infraestrutura de chave pública (PKI).[2] As mensagens comunicadas via OCSP são codificadas em ASN.1 e geralmente são transmitidas por meio de HTTP. A natureza de "solicitação/resposta" dessas mensagens leva os servidores OCSP a serem denominados respondentes OCSP.
Alguns navegadores usam o OCSP para validar os certificados HTTPS.
Um respondente OCSP (um servidor normalmente executado pelo emissor do certificado) pode retornar uma resposta assinada, significando que o certificado especificado na solicitação é 'bom', 'revogado' ou 'desconhecido'. Se não puder processar a solicitação, ele pode retornar um código de erro.
O formato de solicitação OCSP oferece suporte a extensões adicionais. Isso permite uma ampla personalização para um determinado esquema de PKI.
O OCSP pode ser vulnerável a replay attacks,[5] ou seja, uma resposta "boa" assinada pode ser capturada por um intermediário malicioso e reproduzida para o cliente posteriormente (data após o certificado em questão ter sido revogado).
O OCSP permite que um nonce seja incluído na solicitação que pode ser incluída na resposta correspondente. Devido à alta carga, a maioria dos respondentes OCSP não usa a extensão nonce para criar uma resposta diferente para cada solicitação em vez de usar respostas predefinidas com um período de validade de vários dias. Portanto, o ataque de repetição é uma grande ameaça aos sistemas de validação.
O OCSP pode oferecer suporte a mais de um nível de CA. As solicitações OCSP podem ser encadeadas entre respondentes de pares para consultar a CA emissora apropriada para o certificado em questão, com respondentes validando as respostas uns dos outros contra a CA raiz usando suas próprias solicitações OCSP.
Um respondente do OCSP pode ser consultado para informações de revogação por servidores de validação de caminho delegado (DPV). O OCSP não realiza, por si só, qualquer DPV dos certificados fornecidos.
A chave que assina uma resposta não precisa ser a mesma que assinou o certificado. O emissor do certificado pode delegar outra autoridade para ser o respondente do OCSP. Neste caso, o certificado do respondente (aquele que é usado para assinar a resposta) deve ser emitido pelo emissor do certificado em questão e deve incluir uma determinada extensão que o marca como uma autoridade de assinatura OCSP (mais precisamente, uma extensão de uso de chave estendida com o OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})
A verificação OCSP cria uma preocupação com a privacidade para alguns usuários, uma vez que exige que o cliente entre em contato com um terceiro (embora seja uma parte de confiança do fornecedor do software cliente) para confirmar a validade do certificado. O grampeamento é uma forma de verificar a validade sem revelar o comportamento de navegação à CA.[1]
A revogação baseada em OCSP não é uma técnica eficaz para mitigar o comprometimento da chave privada de um servidor HTTPS. Um invasor que comprometeu a chave privada de um servidor normalmente precisa estar em uma posição man-in-the-middle na rede para abusar dessa chave privada e se passar por um servidor. Um invasor em tal posição também pode interferir nas consultas OCSP do cliente. Como a maioria dos clientes ignora silenciosamente o OCSP se a consulta atingir o tempo limite, o OCSP não é um meio confiável de mitigar o comprometimento da chave do servidor HTTPS.[6]
A extensão MustStaple TLS em um certificado pode exigir que o certificado seja verificado por uma resposta OCSP grampeada, atenuando esse problema.[3] O OCSP também permanece uma defesa válida contra situações em que o invasor não é um "intermediário" (assinatura de código ou certificados emitidos por engano).
O protocolo OCSP assume que o solicitante tem acesso à rede para se conectar a um respondente OCSP apropriado. Alguns solicitantes podem não conseguir se conectar porque sua rede local proíbe o acesso direto à Internet (uma prática comum para nós internos em um data center). Forçar os servidores internos a se conectarem à internet para usar OCSP contribui para a tendência de Desperimetrização. O protocolo de grampeamento OCSP é uma alternativa que permite que os servidores armazenem em cache as respostas do OCSP, o que elimina a necessidade de o solicitante entrar em contato diretamente com o respondente do OCSP.
Há amplo suporte para OCSP entre a maioria dos navegadores principais:
No entanto, o Google Chrome é um ponto fora da curva. O Google desativou as verificações OCSP por padrão em 2012, citando latência e problemas de privacidade[13] e, em vez disso, usa seu próprio mecanismo de atualização para enviar certificados revogados ao navegador.[14]
Existem várias implementações OCSP de código aberto e proprietário, incluindo servidor e bibliotecas para construir aplicativos personalizados. O suporte à cliente OCSP está integrado em muitos sistemas operacionais, navegadores web e outros softwares de redes devido à popularidade do HTTPS e a World Wide Web.