Esta página foi traduzida pela API Cloud Translation.

Como configurar Signed HTTP Exchanges (SXG) usando nginx

Como gerar um certificado TLS com extensões SXG, instalar ferramentas para gerar arquivos SXG e configurar o nginx para exibir arquivos SXG.

Hiroki Kumazaki

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:

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.

A caixa de seleção **Incluir a extensão CanSignHttpExchanges no certificado**.

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 arquivo cert.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!