Como gerar um certificado TLS com extensões SXG, instalar ferramentas para gerar arquivos SXG e configurar o nginx para exibir arquivos SXG.
O Signed HTTP Exchanges (SXG) é uma nova tecnologia da Web que facilita a diferenciação entre criadores e distribuidores de conteúdo pelos usuários. Este guia mostra como configurar as SXG.
Suporte a vários navegadores
Vários navegadores baseados no Chromium são compatíveis com SXG, incluindo Google Chrome, Samsung Internet e Microsoft Edge. Consulte a seção "Consenso e Padronização" de Trocas HTTP assinadas pela origem para informações mais atualizadas.
Pré-requisitos
Para implementar SXGs no seu site, você precisa:
- controlar seu domínio, inclusive as entradas DNS.
- Receber certificados. As SXG exigem a emissão de um certificado dedicado. Especificamente, não é possível reutilizar a chave ou o certificado TLS.
- Tenha um servidor HTTP que possa gerar e exibir SXG por HTTPS.
Suposições
Confira o que é necessário para seguir este guia:
- Tenha um ambiente OpenSSL 1.1.1. Este guia foi escrito com o Ubuntu 18.04 LTS em amd64 ISA.
- Ter a capacidade de executar
sudo
para instalar executáveis. - Use
nginx
como um servidor HTTP. - estão usando a DigiCert para gerar certificados que incluem extensões relacionadas às SXG, porque atualmente ele parece ser o único provedor que oferece suporte a essas extensões;
Além disso, os comandos de exemplo neste artigo consideram que seu domínio é website.test
, então você vai precisar substituir website.test
pelo seu domínio real.
Etapa 1: acessar seu certificado para SXG
Para gerar SXG, você precisa de um certificado TLS com a extensão CanSignHttpExchanges
e de um tipo de chave específico.
A DigiCert fornece certificados com essa extensão.
Você precisa de um arquivo CSR para a emissão de um certificado, então gere-o com os seguintes comandos:
openssl ecparam -genkey -name prime256v1 -out mySxg.key
openssl req -new -key mySxg.key -nodes -out mySxg.csr -subj "/O=Test/C=US/CN=website.test"
Você receberá um arquivo CSR parecido com o seguinte:
-----BEGIN CERTIFICATE REQUEST-----
MIHuMIGVAgEAMDMxDTALBgNVBAoMBFRlc3QxCzAJBgNVBAYTAlVTMRUwEwYDVQQD
DAx3ZWJzaXRlLnRlc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS7IVaeMvid
S5UO7BspzSe5eqT5Qk6X6dCggUiV/vyqQaFDjA/ALyTofgXpbCaksorPaDhdA+f9
APdHWkTbbdv1oAAwCgYIKoZIzj0EAwIDSAAwRQIhAIb7n7Kcc6Y6pU3vFr8SDNkB
kEadlVKNA24SVZ/hn3fjAiAS2tWXhYdJX6xjf2+DL/smB36MKbXg7VWy0K1tWmFi
Sg==
-----END CERTIFICATE REQUEST-----
Confira se:
- O período de validade não é maior que 90 dias.
- A caixa de seleção Incluir a extensão CanSignHttpExchanges no certificado está ativada, encontrada em Opções adicionais de certificado.
![](https://web.dev/static/articles/how-to-set-up-signed-http-exchanges/image/kFWTZFXNvwkHnwRu7y8Q.png?authuser=5&hl=pt)
Se o certificado não corresponder a essas condições, os navegadores e distribuidores vão rejeitar as SXG por motivos de segurança.
Neste guia, pressupomos que o nome do arquivo do certificado recebido da DigiCert seja mySxg.pem
.
Etapa 2: instalar o libsxg
O formato SXG é complexo e difícil de gerar sem usar ferramentas. Use uma das seguintes opções para gerar SXG:
- A ferramenta gen-signedexchange escrita em Go.
- A biblioteca
libsxg
escrita em C.
Este guia usa libsxg
.
Opção 1: instalar libsxg
de um pacote Debian
É possível instalar o pacote da maneira comum do Debian, desde que a versão do OpenSSL (libssl-dev
) seja correspondente.
sudo apt install -y libssl-dev
wget https://github.com/google/libsxg/releases/download/v0.2/libsxg0_0.2-1_amd64.deb
wget https://github.com/google/libsxg/releases/download/v0.2/libsxg-dev_0.2-1_amd64.deb
sudo dpkg -i libsxg0_0.2-1_amd64.deb
sudo dpkg -i libsxg-dev_0.2-1_amd64.deb
Opção 2: criar libsxg
manualmente
Se você não estiver usando um ambiente compatível com arquivos .deb
, poderá criar libsxg
por conta própria.
Como pré-condição, você precisa instalar git
, cmake
, openssl
e gcc
.
git clone https://github.com/google/libsxg
mkdir libsxg/build
cd libsxg/build
cmake .. -DRUN_TEST=false -DCMAKE_BUILD_TYPE=Release
make
sudo make install
Etapa 3: instalar o plug-in nginx
O plug-in nginx
permite gerar SXG de maneira dinâmica, em vez de estaticamente, antes da veiculação.
Opção 1: instalar o plug-in de um pacote Debian
O módulo SXG para nginx
é distribuído no GitHub.
Nos sistemas baseados em Debian, é possível instalá-lo como um pacote binário:
sudo apt install -y nginx=1.15.9-0
wget https://github.com/google/nginx-sxg-module/releases/download/v0.1/libnginx-mod-http-sxg-filter_1.15.9-0ubuntu1.1_amd64.deb
sudo dpkg -i libnginx-mod-http-sxg-filter_1.15.9-0ubuntu1.1_amd64.deb
Opção 2: criar o plug-in manualmente
A criação do módulo nginx
requer o código-fonte de nginx
.
É possível conseguir o tarball e criá-lo junto com o módulo dinâmico SXG usando os comandos abaixo:
git clone https://github.com/google/nginx-sxg-module
wget https://nginx.org/download/nginx-1.17.5.tar.gz
tar xvf nginx-1.17.5.tar.gz
cd nginx-1.17.5
./configure --prefix=/opt/nginx --add-dynamic-module=../nginx-sxg-module --without-http_rewrite_module --with-http_ssl_module
make
sudo make install
A configuração nginx
tem grande flexibilidade.
Instale o nginx
em qualquer lugar do sistema e especifique um caminho correspondente para module/config/log/pidfile
.
Este guia pressupõe que você o instale no /opt/nginx
.
Etapa 4: configurar o plug-in nginx
para funcionar com SXG
Opção 1: configurar um módulo nginx
install-from-Debian
Siga estas instruções se você já tiver usado a Etapa 3, opção 1.
O envio de conteúdo SXG exige HTTPS. É possível conseguir um certificado SSL/TLS da DigiCert, Let's Encrypt e de outros serviços. Observe que NÃO é possível usar um certificado SXG para SSL ou vice-versa. Portanto, você precisará de dois certificados. O arquivo de configuração em /etc/nginx/nginx.conf
precisa ser semelhante ao exemplo a seguir, supondo que você coloque o par de chave/certificado SSL em /path/to/ssl/
e o par de chave/certificado SXG em /path/to/sxg/
:
user www-data;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
}
http {
include mime.types;
default_type application/octet-stream;
add_header X-Content-Type-Options nosniff;
server {
listen 443 ssl;
ssl_certificate /path/to/ssl/fullchain.pem;
ssl_certificate_key /path/to/ssl/privkey.pem;
server_name website.test;
sxg on;
sxg_certificate /path/to/sxg/mySxg.pem;
sxg_certificate_key /path/to/sxg/mySxg.key;
sxg_cert_url https://website.test/certs/cert.cbor;
sxg_validity_url https://website.test/validity/resource.msg;
sxg_cert_path /certs/cert.cbor;
root /var/www/html;
}
}
- O
sxg_cert_url
é essencial para que os navegadores carreguem as SXG corretamente, porque localiza a cadeia de certificados. A cadeia de certificados contém informações de certificados e de grampeamento de OCSP com o formato cbor. Não é necessário disponibilizar o arquivocert.cbor
da mesma origem. É possível veiculá-lo por meio de CDNs ou outros serviços de veiculação de arquivos estáticos, desde que sejam compatíveis com HTTPS. - O
sxg_validitiy_url
vai veicular informações relacionadas ao cabeçalho da assinatura SXG. Se uma página não foi modificada desde a última SXG, não é necessário fazer o download de todo o arquivo SXG. Portanto, somente a atualização das informações do cabeçalho da assinatura pode reduzir o tráfego de rede. No entanto, os detalhes ainda não foram implementados.
Inicie o nginx
para disponibilizar as SXG.
sudo systemctl start nginx.service
curl -H"Accept: application/signed-exchange;v=b3" https://website.test/ > index.html.sxg
cat index.html.sxg
sxg1-b3...https://website.test/...(omit)
Opção 2: configurar um módulo nginx
integrado à origem
Siga estas instruções se você já tiver usado a Etapa 3, opção 2.
Configure o sistema nginx
instalado em /opt/nginx
para que seja semelhante ao exemplo a seguir:
load_module "/opt/nginx/modules/ngx_http_sxg_filter_module.so";
events {
worker_connections 768;
}
http {
include mime.types;
default_type application/octet-stream;
add_header X-Content-Type-Options nosniff;
server {
listen 443 ssl;
ssl_certificate /path/to/ssl/fullchain.pem;
ssl_certificate_key /path/to/ssl/privkey.pem;
server_name example.com;
sxg on;
sxg_certificate /path/to/sxg/mySxg.pem;
sxg_certificate_key /path/to/sxg/mySxg.key;
sxg_cert_url https://website.test/certs/cert.cbor;
sxg_validity_url https://website.test/validity/resource.msg;
sxg_cert_path /certs/cert.cbor;
root /opt/nginx/html;
}
}
Em seguida, inicie nginx
. Agora você pode acessar suas SXG!
cd /opt/nginx/sbin
sudo ./nginx
curl -H "Accept: application/signed-exchange;v=b3" https://website.test/ > index.html.sxg
less index.html.sxg
sxg1-b3...https://website.test/...(omit)
Etapa 5: disponibilizar o back-end do aplicativo
Nos exemplos acima, nginx
exibe arquivos estáticos no diretório raiz, mas é possível usar diretivas upstream para que seus aplicativos criem SXG para back-ends de aplicativos da Web arbitrários, como Ruby on Rails, Django ou Express, desde que o nginx
funcione como um servidor HTTP(S) frontal.
upstream app {
server 127.0.0.1:8080;
}
server {
location / {
proxy_pass http://app;
}
}
Etapa 6: testar
Use a ferramenta de troca assinada de dump para testar se as SXGs exibidas estão corretas, garantir que nenhum erro seja relatado e verificar se os cabeçalhos e o corpo estão conforme o esperado.
go get -u github.com/WICG/webpackage/go/signedexchange/cmd/dump-signedexchange
export PATH=$PATH:~/go/bin
dump-signedexchange -verify -uri https://website.test/ | less
Enviar feedback
Os engenheiros do Chromium que trabalham nas SXG estão ansiosos para receber seu feedback pelo e-mail webpackage-dev@chromium.org. Você também pode participar da discussão de especificações ou informar um bug para a equipe. Seu feedback vai ajudar muito no processo de padronização e na resolução de problemas de implementação. Valeu!