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

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

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

Hiroki Kumazaki

Les échanges HTTP signés (SXG) sont 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 un échange signé.

Compatibilité multi-navigateur

Plusieurs navigateurs Chromium sont compatibles avec les échanges signés, y compris Google Chrome et Samsung Internet et Microsoft Edge. Reportez-vous à la section Consensus et standardisation du Échanges HTTP signés avec l'origine pour obtenir des informations à jour.

Prérequis

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

Contrôlez votre domaine, y compris les entrées DNS.
Permet d'obtenir 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 échanges signés via HTTPS

Hypothèses

Dans ce guide, nous partons du principe que vous avez:

Disposer d'un environnement OpenSSL 1.1.1. Ce guide a été rédigé avec Ubuntu 18.04 LTS sur amd64 ISA.
Vous devez pouvoir exécuter sudo pour installer des exécutables.
Utilisez nginx comme serveur HTTP.
utilisent DigiCert pour générer des certificats qui incluent des extensions liées aux échanges signés, car il semble actuellement être le seul fournisseur compatible avec ces extensions.

De plus, les exemples de commandes présentés dans cet article supposent que votre domaine est website.test. Vous devez donc remplacer website.test par votre véritable domaine.

Étape 1: Obtenez votre certificat pour l'échange signé

Pour générer un échange signé, vous avez besoin d'un certificat TLS avec l'extension CanSignHttpExchanges, ainsi que d'un type de clé particulier. DigiCert fournit des certificats comportant cette extension. Vous avez besoin d'un fichier CSR pour l'émission d'un certificat. Vous devez donc le générer à 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 obtenez un fichier CSR qui se présente comme suit:

Faites les vérifications suivantes :

La période de validité ne doit pas dépasser 90 jours.
La case Inclure l'extension CanSignHttpExchanges dans le certificat est cochée. qui se trouve sous Options de certificat supplémentaires.

</ph> Case à cocher **Inclure l'extension CanSignHttpExchanges dans le certificat**

Si votre certificat ne remplit pas ces conditions, les navigateurs et les distributeurs refuseront votre échange signé pour des raisons de sécurité. Ce guide suppose que le nom de fichier du certificat que vous avez obtenu de DigiCert est mySxg.pem.

Étape 2: Installez `libsxg`

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

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 package Debian

Vous pouvez installer le package de la manière habituelle dans 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: Compiler `libsxg` manuellement

Si vous n'utilisez pas un environnement compatible avec les fichiers .deb, vous pouvez créer libsxg vous-même. Comme condition préalable, vous devez 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: Installez le plug-in `nginx`

Le plug-in nginx vous permet de générer des échanges signés de manière dynamique au lieu de les générer de manière statique avant la diffusion.

Option 1: Installer le plug-in à partir d'un package 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 package tarball et le créer 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 offre une grande flexibilité. Installez nginx n'importe où dans votre système, puis spécifiez le chemin d'accès correspondant à module/config/log/pidfile. Dans ce guide, nous partons du principe que vous l'installez dans /opt/nginx.

Étape 4: Configurez le plug-in `nginx` pour qu'il fonctionne avec un échange signé

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 contenus SXG nécessite le protocole 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 de certificat SXG pour SSL ou inversement. Vous aurez donc besoin de deux certificats. Le fichier de configuration dans /etc/nginx/nginx.conf devrait ressembler à ce qui 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 l'échange signé, car il localise la chaîne de certificats. La chaîne de certificats contient des informations de certificat et d'agrafage OCSP au format cbor. Notez qu'il n'est pas nécessaire de diffuser le fichier cert.cbor depuis la même origine. Vous pouvez le diffuser via n'importe quel CDN ou autre service de diffusion de fichiers statiques, à condition qu'il soit compatible avec HTTPS.
sxg_validitiy_url devrait diffuser les informations liées à l'en-tête de la signature SXG. Si une page n'a pas été modifiée depuis le dernier échange signé, le téléchargement de l'intégralité du fichier SXG n'est pas techniquement nécessaire. La mise à jour seule des informations d'en-tête de signature devrait donc réduire le trafic réseau. Toutefois, les détails ne sont pas encore implémentés.

Lancez nginx et vous êtes prêt à diffuser des échanges signés !

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

Ensuite, démarrez nginx. Vous pouvez maintenant obtenir votre échange signé.

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: Diffuser le backend de votre application

Dans les exemples ci-dessus, nginx diffuse des fichiers statiques dans le répertoire racine. Toutefois, vous pouvez utiliser des directives en amont pour que vos applications créent des connexions SXG pour les backends d'applications Web arbitraires (comme Ruby on Rails, Django ou Express), tant que votre nginx fonctionne en tant que serveur HTTP(S) frontal.

upstream app {
    server 127.0.0.1:8080;
}

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

Étape 6: Test

Utiliser l'outil dump-signedExchange pour vérifier que les échanges signés sont corrects, qu'aucune erreur n'est signalée et que les en-têtes et le corps de la requête.

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 connaître votre avis à l'adresse webpackage-dev@chromium.org. Vous pouvez également participer à la discussion sur les spécifications ou signaler un bug à l'équipe. Vos commentaires nous aideront à améliorer le processus de normalisation et à résoudre les problèmes d'implémentation. Merci !