Provavelmente, você deve ter tomado conhecimento da Transparência de Certificado (TC) há alguns anos quando o Google anunciou que ela era uma exigência para todos os Certificados (EV) SSL/TLS de Validação Estendida emitidos a partir de 1º de janeiro de 2015. Desde então, o Google ampliou a exigência para englobar todos os tipos de Certificados SSL e recentemente divulgou um prazo final de abril de 2018. Certificados emitidos a partir dessa data que não forem classificados pela TC não serão confiáveis no Chrome.
Na GlobalSign, temos trabalhado arduamente nos bastidores para equipar todos os nossos certificados com TC – Validação Estendida (EV) desde 2015, Validação de Domínio (DV) desde agosto de 2016 e Validação Organizacional (OV) está chegando em outubro de 2017 – portanto, nossos clientes estarão prontos para o prazo do Google no ano que vem.
Enquanto isso, para aqueles que ainda estão questionando do que se trata a TC, considere este documento seu curso preparatório.
Observação: Por uma questão de praticidade, estamos usando o termo SSL em vez de TLS neste post (com uma única exceção), já que ele é mais comum. Para ler mais sobre o assunto, consulte nosso post relacionado.
O que é transparência de certificado?
Transparência de Certificado é uma estrutura aberta para monitorar Certificados SSL. Proprietários de domínios podem achar útil monitorar a emissão de certificados para seus domínios e usam isso para detectar certificados emitidos incorretamente. Antes da TC, não havia uma forma eficaz de obter uma lista abrangente de certificados emitidos para seu domínio.
Com a TC, todos os certificados são divulgados publicamente, fornecendo maior insight e transparência do ecossistema de PKI da Web como um todo. O Projeto transparência de certificado espera atingir três objetivos:
- Tornar impossível (ou pelo menos muito difícil) para uma AC emitir um Certificado SSL para um domínio sem que o certificado fique visível ao detentor daquele domínio.
- Fornecer um sistema de auditoria e monitoramento aberto que permita a qualquer proprietário de domínio ou AC determinar se os certificados foram emitidos erroneamente ou maliciosamente emitidos.
- Proteger os usuários para que não sejam enganados por certificados emitidos erroneamente ou maliciosamente emitidos.
A estrutura de transparência de certificado significa que certificados emitidos incorretamente podem ser detectados com rapidez e eficiência em comparação ao sistema antigo, em que certificados falsos conseguiam ficar livres para causar danos por semanas ou meses antes de serem descobertos. A detecção precoce de certificados suspeitos permite que ACs e proprietários de domínio ajam rapidamente e revoguem os certificados.
Como a transparência de certificado funciona
Os dois componentes principais da TC são logs e monitores de TC.
Logs de TC mantêm registros de Certificados SSL emitidos. Esses logs são apenas anexos, o que significa que as entradas não podem ser excluídas nem alteradas de nenhuma maneira depois que o certificado tiver sido adicionado a um log. Certificados e pré-certificados SSL (mais informações a seguir) podem ser lançados em logs de TC. Ao receber um pré-certificado ou um Certificado SSL válido, o log retorna um Carimbo do tempo, Data e Hora do Certificado Assinado (SCT), que é a comprovação de que o log recebeu a solicitação. Os logs de TC usam um mecanismo criptográfico chamado de hash de árvore de Merkle, que impede a modificação ou exclusão das entradas de log, assim, uma vez publicados, eles ficam sempre visíveis ao público. Os navegadores podem exigir SCTs (que indicam que o certificado foi divulgado ao público) enquanto processam Certificados SSL ao estabelecerem uma sessão TLS, assim, esses SCTs são um recurso cada vez mais importante no PKI da Web. Mais sobre isso a seguir.
Monitores consultam logs de TC e podem baixar e armazenar certificados para emitir relatório posteriormente. Os monitores analisarão os certificados em subcampos e permitirão que seus usuários criem e executem consultas para certificados. Proprietários de domínio podem estar interessados em receber avisos para certificados emitidos em seus domínios ou para certificados que correspondam ao nome da Organização, enquanto equipes de conformidade podem buscar conformidade com os requisitos do Programa de raiz ou com os Requisitos Básicos do Fórum CA/Browser. Independentemente disso, os Monitores têm muitas finalidades. Alguns serviços de terceiros lançaram ferramentas de Monitoramento de TC ou começaram a incluí-las em seus pacotes de solução existentes. Por exemplo, o Facebook lançou seu próprio serviço de monitoramento gratuito no final do ano passado.
Quais são os pré-certificados?
Conforme mencionado acima, os logs de TC aceitam pré-certificados e certificados SSL. Um pré-certificado contém todos os mesmos dados que o certificado "real", mas também contém uma extensão adicional que faz com que não seja possível usar o certificado. Essa extensão é chamada de extensão suspeita e é usada para distinguir este do certificado "real". Como todos os certificados emitidos por uma AC devem conter números de série únicos, e uma vez que tanto o pré-certificado quanto o certificado “real” terão o mesmo número de série, é importante tornar um deles inválido ou não utilizável, por isso a extensão suspeita.
Por que os pré-certificados são úteis?
Há vários métodos de enviar SCTs a navegadores para processamento, porém, a mais confiável e útil é incluir SCTs no certificado. Para obter SCTs antes da emissão (para que possam ser incluídos no certificado), a AC deve criar um pré-certificado, lançá-lo em logs de TC, receber SCTs e então incluí-los no certificado final.
Antes de emitir um certificado, uma AC deve emitir um pré-certificado para logs de TC como intenção de emitir o certificado correspondente. Na verdade, criar e lançar um pré-certificado que não tenha sido validado ou formatado adequadamente é considerado uma emissão incorreta.
Quem pode enviar certificados a logs de TC?
Qualquer um pode enviar certificados a logs de TC, mas apenas ACs enviarão pré-certificados. Mecanismos de pesquisa e operadores de site também costumam lançar certificados para logs de TC.
Alguns operadores de log de TC aceitam certificados apenas sob determinadas raízes, alguns não aceitam certificados expirados e todos os certificados (ou pré-certificados) devem ser destinados a uso como Certificados SSL (ou seja, não é possível lançar S/MIME ou certificados de assinatura de código para logs de TC).
Como usar SCTs
O SCT – a comprovação de que o certificado foi registrado – deve ser disponibilizado ao navegador da Web para que o navegador avalie adequadamente o Certificado SSL. O comportamento exato e os requisitos do navegador para SCTs variam conforme o navegador, porém, em todos os casos, o navegador deve receber os SCTs. Embora o navegador teoricamente possa lançar Certificados SSL para logs ao criar uma sessão de TLS para obter SCTs, a sobrecarga de fazer isso seria proibitiva. Há três métodos principais de distribuir SCTs ao navegador:
1. Extensão de certificação
O método mais comum e confiável para distribuir SCTs ao navegador é a AC incluir SCTs no certificado. Como o navegador precisa de um Certificado SSL para estabelecer a sessão de TLS, o certificado com certeza estará presente e poderá sempre ser usado para ler SCTs.
Talvez alguns proprietários de site não queiram divulgar os URLs do site antes do lançamento do site. Portanto, não desejarão publicar seus certificados em logs de TC com antecedência. Neste caso, pode haver preferência por uma das opções de distribuição.
2. Extensão de TLS (SSL)
O operador do site pode fornecer SCTs ao navegador no protocolo TLS. Neste modelo, o operador do site/servidor da Web envia o certificado para logs de TC e obtém os SCTs. Os SCTs são incluídos no handshake do TLS por meio de uma extensão TLS chamada de "signed_certificate_timestamp". O "lado negativo" desse método de distribuição é que os operadores do servidor da Web devem alterar as configurações padrão do servidor da Web, e nem todos os servidores da Web dão suporte a essa opção.
3. Associação de OCSP
Mensagens OCSP podem ser usadas para a distribuição de SCTs ao navegador. Dois itens são necessários para dar suporte a esse método:
- O operador do site deve usar um servidor da web que dê suporte a associação de OCSP e configurar seu servidor para solicitar e baixar uma resposta OCSP válida. Se isso não for feito, não há garantia de que o navegador buscará a mensagem do OCSP contendo os SCTs (muitos navegadores não dão suporte a OCSP, assim, esse não é um mecanismo confiável, a menos que a resposta do OCSP esteja incluída no protocolo TLS).
- A AC deve configurar o serviço OCSP para dar suporte à associação de SCT. Depois da emissão do certificado, a AC o lançará em vários logs e receberá SCTs. Quando as respostas do OCSP forem geradas, a AC anexará os SCTs à mensagem OCSP e o navegador terá tanto o status de revogação quanto os SCTs necessários.
Embora os métodos 2 e 3 exijam configuração especial do servidor, eles poderão oferecer mais flexibilidade em comparação à opção 1 acima se os logs do certificado passarem a não ser confiáveis, já que o operador do site da Web e a AC podem reconfigurar de modo mais dinâmico os logs que estão sendo usados.
A política de TC do Google
Para ser "qualificado para TC", o Google exige que um certificado apareça em vários logs (pelo menos um log do Google um log não do Google), e o número de SCTs necessários depende do período de validade do certificado. Para mais detalhes, consulte a Transparência de certificado no Chrome do Google.
Uma lista de logs pode ser encontrada aqui.
O que você precisa fazer para estar em conformidade com TC?
Bom, agora você conhece os fundamentos de TC! A melhor solução para garantir que você esteja em conformidade é selecionar uma AC que adicione SCTs a certificados emitidos em conformidade com a política de TC do Google. A grande maioria dos certificados de SSL da GlobalSign já está em conformidade com a política do Google e, em alguns meses, todos os certificados estarão – cinco meses completos antes do prazo do Google de abril de 2018.
Até o momento, o Google é o único navegador a anunciar cronogramas para exigir TC. A Mozilla elaborou uma política, mas nenhuma data foi anunciada até o momento, e esperamos que suas exigências sejam compatíveis com às do Google. Você pode acompanhar a discussão aqui. Atualizaremos esta publicação quando houver anúncios futuros.
Tem alguma dúvida sobre transparência de certificado e a conformidade dos seus certificados? Fale conosco a qualquer hora; ficaremos felizes em ajudar.
