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

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

Vous savez 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 qu'il diffuse ces fichiers.

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é multinavigateur

Plusieurs navigateurs basés sur Chromium sont compatibles avec SXG, y compris Google Chrome, Samsung Internet et Microsoft Edge. Pour obtenir des informations à jour, consultez la section "Consensus et standardisation" du document Échanges HTTP signés à l'origine.

Prérequis

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

Contrôlez votre domaine, y compris les entrées DNS.
Obtenir des certificats L'échange signé 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:

Vous disposez d'un environnement OpenSSL 1.1.1. Ce guide a été écrit avec Ubuntu 18.04 LTS sur amd64 ISA.
Vous devez pouvoir exécuter sudo pour installer des exécutables.
Utilisez nginx en tant que serveur HTTP.
utilisent DigiCert pour générer des certificats incluant 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 de cet article supposent que votre domaine est website.test. Vous devez donc remplacer website.test par votre 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 avec cette extension. Vous avez besoin d'un fichier CSR pour l'émission d'un certificat. Générez-le donc à 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 obtiendrez un fichier CSR qui se présente comme suit:

Faites les vérifications suivantes :

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

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

Si votre certificat ne remplit pas ces conditions, les navigateurs et les distributeurs le refuseront pour des raisons de sécurité. Dans ce guide, nous partons 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 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 comme à l'accoutumée 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 compiler 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 dynamiques de manière dynamique plutôt que 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 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 offre une grande flexibilité. Installez nginx n'importe où dans votre système, puis spécifiez le chemin d'accès de module/config/log/pidfile. Dans ce guide, nous partons du principe que vous devez l'installer dans /opt/nginx.

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

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

Suivez ces instructions si vous avez utilisé l'étape 3, option 1.

La diffusion de contenu échange signé 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, si 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 sur le certificat et l'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 d'autres services de diffusion de fichiers statiques, à condition qu'il soit compatible avec le protocole 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 échange signé, il n'est techniquement pas nécessaire de télécharger l'intégralité du fichier SXG. Ainsi, la mise à jour des informations de l'en-tête de signature seule devrait réduire le trafic réseau. Toutefois, les détails ne sont pas encore pris en compte.

Démarrez nginx et vous êtes prêt à diffuser un échange signé !

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` créé à partir de la source

Suivez ces instructions si vous avez utilisé l'étape 3, option 2.

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 désormais obtenir un é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 les fichiers statiques dans le répertoire racine, mais vous pouvez utiliser des instructions en amont pour vos applications afin de créer des échanges signés pour des backends d'applications Web arbitraires (comme Ruby on Rails, Django ou Express) à condition que votre nginx fonctionne comme un serveur HTTP(S) frontal.

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 échanges signé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 de Chromium qui travaillent sur le mécanisme SXG souhaitent recevoir vos commentaires à 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 dans une démarche de normalisation et à résoudre les problèmes de mise en œuvre. Merci !