Diese Seite wurde von der Cloud Translation API übersetzt.

Signed HTTP Exchanges (SXG) mit nginx einrichten

Hier erfahren Sie, wie Sie ein TLS-Zertifikat mit SXG-Erweiterungen generieren, Tools zum Generieren von SXG-Dateien installieren und nginx für die Bereitstellung von SXG-Dateien konfigurieren.

Hiroki Kumazaki

Signed HTTP Exchanges (SXG) ist eine neue Webtechnologie, mit der Nutzer Creator von Content-Distributoren leichter unterscheiden können. In dieser Anleitung erfährst du, wie du SXG einrichtest.

Browserübergreifende Unterstützung

SXG wird von mehreren Chromium-basierten Browsern unterstützt, darunter Google Chrome, Samsung Internet und Microsoft Edge. Aktuelle Informationen finden Sie im Abschnitt „Konsens und Standardisierung“ des Artikels Von Ursprung signierte HTTP-Austausche.

Vorbereitung

Damit du SXG auf deiner Website implementieren kannst, müssen folgende Voraussetzungen erfüllt sein:

Sie haben die Kontrolle über Ihre Domain, einschließlich DNS-Einträgen.
Zertifikate abrufen Für SXG ist die Ausstellung eines speziellen Zertifikats erforderlich. Insbesondere können Sie Ihren TLS-Schlüssel oder Ihr TLS-Zertifikat nicht wiederverwenden.
Sie benötigen einen HTTP-Server, der SXG-Dateien über HTTPS generieren und bereitstellen kann.

Annahmen

In diesem Leitfaden wird davon ausgegangen, dass Sie Folgendes haben:

Sie benötigen eine OpenSSL 1.1.1-Umgebung. Diese Anleitung wurde mit Ubuntu 18.04 LTS auf amd64 ISA geschrieben.
Sie können sudo ausführen, um ausführbare Dateien zu installieren.
Verwenden Sie nginx als HTTP-Server.
Sie verwenden DigiCert, um Zertifikate mit SXG-bezogenen Erweiterungen zu generieren, da dies derzeit der einzige Anbieter ist, der diese Erweiterungen unterstützt.

Außerdem wird in den Beispielbefehlen in diesem Artikel davon ausgegangen, dass Ihre Domain website.test lautet. Sie müssen website.test also durch Ihre tatsächliche Domain ersetzen.

Schritt 1: Zertifikat für SXG abrufen

Zum Generieren von SXG benötigen Sie ein TLS-Zertifikat mit der Erweiterung CanSignHttpExchanges sowie einen bestimmten Schlüsseltyp. DigiCert stellt Zertifikate mit dieser Erweiterung bereit. Für die Ausstellung eines Zertifikats benötigen Sie eine CSR-Datei. Generieren Sie sie mit den folgenden Befehlen:

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"

Sie erhalten eine CSR-Datei, die wie folgt aussieht:

Prüfen Sie Folgendes:

Die Gültigkeitsdauer darf 90 Tage nicht überschreiten.
Das Kästchen CanSignHttpExchanges-Erweiterung in das Zertifikat aufnehmen ist unter „Zusätzliche Zertifikatoptionen“ aktiviert.

Das Kästchen **CanSignHttpExchanges-Erweiterung in das Zertifikat aufnehmen**.

Wenn dein Zertifikat diese Bedingungen nicht erfüllt, lehnen Browser und Distributoren deinen SXG aus Sicherheitsgründen ab. In diesem Leitfaden wird davon ausgegangen, dass der Dateiname des Zertifikats, das Sie von DigiCert erhalten haben, mySxg.pem lautet.

Schritt 2: `libsxg` installieren

Das SXG-Format ist komplex und ohne Tools nur schwer zu generieren. Du kannst eine der folgenden Optionen verwenden, um SXG zu generieren:

Das in Go geschriebene Tool gen-signedexchange
Die in C geschriebene libsxg-Bibliothek

In diesem Leitfaden wird libsxg verwendet.

Option 1: `libsxg` über ein Debian-Paket installieren

Sie können das Paket auf die übliche Debian-Weise installieren, sofern die OpenSSL-Version (libssl-dev) übereinstimmt.

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: `libsxg` manuell erstellen

Wenn Sie keine Umgebung verwenden, die mit .deb-Dateien kompatibel ist, können Sie libsxg selbst erstellen. Als Voraussetzung müssen Sie git, cmake, openssl und gcc installieren.

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

Schritt 3: `nginx`-Plug-in installieren

Mit dem nginx-Plug-in können Sie SXG-Dateien dynamisch generieren, anstatt sie vor dem Ausliefern statisch zu generieren.

Option 1: Plug-in aus einem Debian-Paket installieren

Das SXG-Modul für nginx wird auf GitHub bereitgestellt. Auf Debian-basierten Systemen können Sie es als Binärpaket installieren:

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: Plug-in manuell erstellen

Für das Erstellen des nginx-Moduls ist der nginx-Quellcode erforderlich. Du kannst den Tarball herunterladen und zusammen mit dem SXG-dynamischen Modul mit den folgenden Befehlen erstellen:

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

Die nginx-Konfiguration ist sehr flexibel. Installieren Sie nginx an einer beliebigen Stelle in Ihrem System und geben Sie dann einen entsprechenden Pfad zu module/config/log/pidfile an. In diesem Leitfaden wird davon ausgegangen, dass Sie es unter /opt/nginx installieren.

Schritt 4: `nginx`-Plug-in für die Verwendung mit SXG konfigurieren

Option 1: Über Debian installiertes `nginx`-Modul konfigurieren

Folgen Sie dieser Anleitung, wenn Sie zuvor Schritt 3, Option 1 verwendet haben.

Für die Bereitstellung von SXG-Inhalten ist HTTPS erforderlich. Sie können ein SSL/TLS-Zertifikat von DigiCert, Let's Encrypt und anderen Diensten erhalten. Sie können KEIN SXG-Zertifikat für SSL oder umgekehrt verwenden. Sie benötigen also zwei Zertifikate. Die Konfigurationsdatei in /etc/nginx/nginx.conf sollte in etwa so aussehen, vorausgesetzt, Sie geben das SSL-Schlüssel/Zertifikatpaar in /path/to/ssl/ und das SXG-Schlüssel/Zertifikatpaar in /path/to/sxg/ ein:

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 ist für die korrekte Ladung von SXG in Browsern unerlässlich, da damit die Zertifikatskette ermittelt wird. Die Zertifikatskette enthält Zertifikat- und OCSP-Stapling-Informationen im cbor-Format. Die Datei cert.cbor muss nicht am selben Ursprung bereitgestellt werden. Sie können sie über beliebige CDNs oder andere Dienste zum Bereitstellen statischer Dateien bereitstellen, sofern diese HTTPS unterstützen.
sxg_validitiy_url soll Informationen zum SXG-Signatur-Header enthalten. Wenn eine Seite seit der letzten SXG-Datei nicht geändert wurde, ist es technisch nicht erforderlich, die gesamte SXG-Datei herunterzuladen. Allein durch die Aktualisierung der Informationen im Signaturheader wird der Netzwerkverkehr voraussichtlich reduziert. Die Details sind jedoch noch nicht implementiert.

Starte nginx und du kannst SXG bereitstellen.

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: Ein aus der Quelle erstelltes `nginx`-Modul konfigurieren

Folgen Sie dieser Anleitung, wenn Sie zuvor Schritt 3, Option 2 verwendet haben.

Konfigurieren Sie Ihr nginx-System, das unter /opt/nginx installiert ist, so, dass es in etwa so aussieht wie im folgenden Beispiel:

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

Starten Sie dann nginx. Jetzt kannst du dein SXG erhalten!

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)

Schritt 5: Anwendungs-Back-End bereitstellen

In den obigen Beispielen dient nginx zum Bereitstellen statischer Dateien im Stammverzeichnis. Sie können jedoch Upstream-Richtlinien für Ihre Anwendungen verwenden, um SXG für beliebige Webanwendungs-Back-Ends (z. B. Ruby on Rails, Django oder Express) zu erstellen, solange nginx als HTTP(S)-Front-Server dient.

upstream app {
    server 127.0.0.1:8080;
}

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

Schritt 6: Testen

Mit dem dump-signedexchange-Tool können Sie prüfen, ob die gesendeten SXGs korrekt sind, ob keine Fehler gemeldet werden und ob die Header und der Body wie erwartet sind.

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

Feedback geben

Die Chromium-Entwickler, die an SXG arbeiten, freuen sich über Ihr Feedback unter webpackage-dev@chromium.org. Sie können auch an der Diskussion zur Spezifikation teilnehmen oder dem Team einen Fehler melden. Ihr Feedback trägt wesentlich zum Standardisierungsprozess bei und hilft uns, Implementierungsprobleme zu beheben. Vielen Dank!