Novo Header de Segurança : Expect - CT
Certificate Transparency
Abril de 2018 é o deadline para que seu certificado esteja
devidamente instalado e configurado na aplicação, de acordo com as recomendações
da Google. As aplicações que não estiverem em conformidade, irão apresentar
mensagens de falta se segurança e não terão as páginas com um bom índice de SEO,
ou seja, o site não irá funcionar corretamente no Chrome, não serão tratados
como certificados confiáveis pelo browser. Estas recomendações surgiram de um projeto que
a Google iniciou em 2012, chamado de Certificate
Transparency, que visa obter a maior
transparência possível nas emissões de certificados feitas pelas CA, possível obter
mais informações aqui.
Para ajudar neste processo de adequação as solicitações da
Google, a empresa criou um header de segurança, chamado Expect-CT, que permite
analisar se a sua aplicação está pronta para as mudanças que serão aplicadas a
partir de Abril de 2018.
Signed Certificate
Timestamp
Os certificados deverão ser enviados ao servidor do Certificate
Transparency (CT) pela CA que os emitiu, entretanto, é possível que o mantenedor
do site faça isso. Signed Certificate Timestamp (SCT) é o response de um log de
um certificado, ele que deve ser entregue aos clientes quando é feita estabelecida
uma conexão TLS, e isso pode ser feito de três maneiras:
x.509v3 Extension
Uma extensão que já vem com o certificado, ou seja, quando
sua CA emite o certificado, ela entrega esta extensão que já faz a entrega SCT,
sem necessitar de uma ação por parte do dono do site que não seja a instalação típica.
TLS Extension
Via extensão TLS, onde é necessária uma ação por parte do
dono do site, aplicando a extensão chamada de signed_certificate_timestamp
OCSP Stapling
OCSP Stapling é normalmente usado para obter informações
sobre a revogação dos certificados em um servidor, mas também serve para
entrega do SCT.
Clicando aqui, é possível ver
como funciona um log, ele busca todos os certificados que foram instalados no
seu domínio.
Header Expect-CT
Para implementar o header, não requer muita configuração. As suas diretivas disponíveis são:
Enforce – A diretiva
enforce é
opcional, ela controla se o browser deve aplicar uma política ou trata-la como
report-only.
Max-age – A diretiva max-age especifica
o número de segundos que o browser deve fazer cache e aplica a política para
enforced ou report-only
Report-uri – A diretiva
report-uri especifica onde o browser deve
enviar relatórios, caso não esteja recebendo informações validas do CT.
Aplicando o Header
Para aplicar o header, é importante que esteja no modo
report-only para testar e certificar que não irá causar alguma falha. Isso
significa que deve omitir a diretiva enforce
e aplicar max-age para 0. Exemplo:
Expect-CT: max-age=0;
report-uri="https://meusite.report-uri.io/r/default/ct/reportOnly"
Essa política é implementada no modo report-only e se o
browser não receber as informações CT de acordo, será referenciado como não qualificado
e ao invés de terminar a conexão, será enviado um relatório para o valor report-uri especificado. Quando as configurações
estiverem corretas e as entregas de SCTs estejam de acordo, aplique a politica
Expect-CT. Inicie o processo com um “max-age”
baixo.
Expect-CT: enforce;
max-age=30; report-uri=https://meusite.report-uri.io/r/default/ct/enforce
Agora o browser irá fazer o cache e aplicar esta política em
todas as conexões do site por 30 segundos.
As especificações do header podem ser encontradas aqui.
Essa opção ajuda para que a sua aplicação esteja de acordo
com os requerimentos que a Google pede. Mesmo que sua CA forneça o certificado com
o SCT, considero ser importante a aplicação do header, pois um dia você poderá
trocar de CA.
Referencias:
0 comentários: