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.
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:
-----BEGIN CERTIFICATE REQUEST-----
MIHuMIGVAgEAMDMxDTALBgNVBAoMBFRlc3QxCzAJBgNVBAYTAlVTMRUwEwYDVQQD
DAx3ZWJzaXRlLnRlc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS7IVaeMvid
S5UO7BspzSe5eqT5Qk6X6dCggUiV/vyqQaFDjA/ALyTofgXpbCaksorPaDhdA+f9
APdHWkTbbdv1oAAwCgYIKoZIzj0EAwIDSAAwRQIhAIb7n7Kcc6Y6pU3vFr8SDNkB
kEadlVKNA24SVZ/hn3fjAiAS2tWXhYdJX6xjf2+DL/smB36MKbXg7VWy0K1tWmFi
Sg==
-----END CERTIFICATE REQUEST-----
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".
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 fichiercert.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 !