Cette page a été traduite par l'API Cloud Translation.

Configurer les échanges HTTP signés (SXG) à l'aide de nginx

Générer un certificat TLS avec des extensions SXG, installer des outils pour générer des fichiers SXG et configurer nginx pour diffuser des fichiers SXG

Hiroki Kumazaki

Signed HTTP Exchanges (SXG) est une nouvelle technologie Web qui permet aux utilisateurs de distinguer plus facilement les créateurs de contenu des distributeurs de contenu. Ce guide vous explique comment configurer SXG.

Compatibilité entre les navigateurs

Plusieurs navigateurs Chromium sont compatibles avec SXG, y compris Google Chrome, Samsung Internet et Microsoft Edge. Pour en savoir plus, consultez la section "Consensus et standardisation" de la page Échanges HTTP signés par l'origine.

Prérequis

Pour implémenter un échange signé sur votre site Web, vous devez:

Contrôler votre domaine, y compris les entrées DNS
Obtenez des certificats. SXG nécessite l'émission d'un certificat dédié. En particulier, vous ne pouvez pas réutiliser votre clé ou votre certificat TLS.
disposer d'un serveur HTTP capable de générer et de diffuser des fichiers SXG via HTTPS ;

Hypothèses

Ce guide suppose que vous:

disposer d'un environnement OpenSSL 1.1.1 ; Ce guide a été rédigé avec Ubuntu 18.04 LTS sur l'ISA amd64.
Être en mesure d'exécuter sudo pour installer des exécutables.
Utilisez nginx comme serveur HTTP.
Vous utilisez DigiCert pour générer des certificats qui incluent des extensions liées à SXG, car il semble actuellement être le seul fournisseur compatible avec ces extensions.

De plus, les exemples de commandes de cet article supposent que votre domaine est website.test. Vous devrez donc remplacer website.test par votre domaine réel.

Étape 1: Obtenez votre certificat pour SXG

Pour générer des SXG, vous avez besoin d'un certificat TLS avec l'extension CanSignHttpExchanges, ainsi que d'un type de clé particulier. DigiCert fournit des certificats avec cette extension. Vous avez besoin d'un fichier CSR pour émettre un certificat. Générez-le à l'aide des commandes suivantes:

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"

Vous recevrez un fichier CSR qui ressemble à ceci:

Faites les vérifications suivantes :

La période de validité ne dépasse pas 90 jours.
La case à cocher Inclure l'extension CanSignHttpExchanges dans le certificat est activée, sous "Options de certificat supplémentaires".

La case à cocher **Inclure l'extension CanSignHttpExchanges dans le certificat**.

Si votre certificat ne répond pas à ces conditions, les navigateurs et les distributeurs rejetteront votre SXG pour des raisons de sécurité. Ce guide part du principe que le nom de fichier du certificat que vous avez obtenu auprès de DigiCert est mySxg.pem.

Étape 2: Installez `libsxg`

Le format SXG est complexe et difficile à générer sans utiliser d'outils. Vous pouvez générer un fichier SXG à l'aide de l'une des options suivantes:

L'outil gen-signedexchange écrit en Go.
La bibliothèque libsxg écrite en C.

Ce guide utilise libsxg.

Option 1: Installer `libsxg` à partir d'un paquet Debian

Vous pouvez installer le paquet de la manière habituelle sous Debian, à condition que la version d'OpenSSL (libssl-dev) corresponde.

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

Option 2: Créer `libsxg` manuellement

Si vous n'utilisez pas d'environnement compatible avec les fichiers .deb, vous pouvez créer libsxg vous-même. Vous devez d'abord installer git, cmake, openssl et 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

Étape 3: Installer le plug-in `nginx`

Le plug-in nginx vous permet de générer des SXG de manière dynamique plutôt que de les générer de manière statique avant de les diffuser.

Option 1: Installer le plug-in à partir d'un paquet Debian

Le module SXG pour nginx est distribué sur GitHub. Sur les systèmes basés sur Debian, vous pouvez l'installer en tant que package binaire:

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

Option 2: Créer le plug-in manuellement

La compilation du module nginx nécessite le code source nginx. Vous pouvez obtenir le fichier tarball et le compiler avec le module dynamique SXG à l'aide des commandes ci-dessous:

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

La configuration nginx est très flexible. Installez nginx n'importe où dans votre système, puis spécifiez un chemin d'accès correspondant pour module/config/log/pidfile. Ce guide suppose que vous l'installez dans /opt/nginx.

Étape 4: Configurez le plug-in `nginx` pour qu'il fonctionne avec SXG

Option 1: Configurer un module `nginx` installé à partir de Debian

Suivez ces instructions si vous avez suivi l'étape 3, option 1 précédemment.

La diffusion de contenu SXG nécessite HTTPS. Vous pouvez obtenir un certificat SSL/TLS auprès de DigiCert, Let's Encrypt et d'autres services. Notez que vous NE POUVEZ PAS utiliser un certificat SXG pour SSL ni inversement. Vous aurez donc besoin de deux certificats. Le fichier de configuration dans /etc/nginx/nginx.conf doit se présenter comme suit, en supposant que vous placez la paire clé/certificat SSL dans /path/to/ssl/ et la paire clé/certificat SXG dans /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;
    }
}

sxg_cert_url est essentiel pour que les navigateurs chargent correctement les SXG, car il permet de localiser la chaîne de certificats. La chaîne de certificats contient des informations sur le certificat et l'agrafage OCSP au format cbor. Notez que vous n'êtes pas obligé de diffuser le fichier cert.cbor à partir de la même origine. Vous pouvez le diffuser via n'importe quel CDN ou autre service de diffusion de fichiers statiques, à condition qu'il prenne en charge HTTPS.
sxg_validitiy_url est prévu pour diffuser des informations liées à l'en-tête de signature SXG. Si une page n'a pas été modifiée depuis le dernier fichier SXG, il n'est techniquement pas nécessaire de télécharger l'intégralité du fichier SXG. Par conséquent, la mise à jour des informations de l'en-tête de signature seule devrait réduire le trafic réseau. Mais les détails ne sont pas encore implémentés.

Démarrez nginx et vous êtes prêt à diffuser des 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)

Option 2: Configurer un module `nginx` compilé à partir de la source

Suivez ces instructions si vous avez suivi l'étape 3, option 2 précédemment.

Configurez votre système nginx installé sous /opt/nginx pour qu'il ressemble à l'exemple suivant:

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;
    }
}

Démarrez ensuite nginx. Vous pouvez maintenant obtenir votre 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)

Étape 5: Servir le backend de votre application

Dans les exemples ci-dessus, nginx diffuse des fichiers statiques dans le répertoire racine, mais vous pouvez utiliser des directives en amont pour vos applications afin de créer des SXG pour des backends d'application Web arbitraires (tels que Ruby on Rails, Django ou Express), à condition que votre nginx fonctionne comme un serveur HTTP(S) avant.

upstream app {
    server 127.0.0.1:8080;
}

server {
    location / {
        proxy_pass http://app;
    }
}

Étape 6: Test

Utilisez l'outil dump-signedexchange pour vérifier que les SXG diffusés sont corrects, vous assurer qu'aucune erreur n'est signalée et que les en-têtes et le corps sont conformes aux attentes.

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

Envoyer des commentaires

Les ingénieurs Chromium qui travaillent sur SXG sont ravis de recevoir vos commentaires à l'adresse webpackage-dev@chromium.org. Vous pouvez également rejoindre la discussion sur les spécifications ou signaler un bug à l'équipe. Vos commentaires nous aideront grandement à standardiser le processus et à résoudre les problèmes d'implémentation. Merci !