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 einfacher von Inhaltsanbietern unterscheiden können. In dieser Anleitung erfährst du, wie du SXG einrichtest.

Browserübergreifende Unterstützung

Mehrere Chromium-basierte Browser unterstützen SXG, darunter Google Chrome und Samsung Internet und Microsoft Edge. Weitere Informationen finden Sie im Abschnitt „Konsens und Standardisierung“ des Von Ursprung signierte HTTP-Austausche finden Sie aktuelle Informationen.

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.
Du benötigst einen HTTP-Server, der SXG über HTTPS generieren und bereitstellen kann.

Annahmen

In diesem Leitfaden wird Folgendes vorausgesetzt:

Sie benötigen eine OpenSSL 1.1.1-Umgebung. Diese Anleitung wurde mit Ubuntu 18.04 LTS auf amd64 ISA verfasst.
Sie müssen sudo ausführen können, um ausführbare Dateien zu installieren.
Verwende nginx als HTTP-Server.
über DigiCert Zertifikate generieren, die SXG-bezogene Erweiterungen enthalten, da es derzeit anscheinend der einzige Anbieter ist, der diese Erweiterungen unterstützt.

Außerdem wird bei den Beispielbefehlen in diesem Artikel davon ausgegangen, dass Ihre Domain website.test ist. Daher müssen Sie website.test 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 mit dieser Erweiterung Zertifikate bereit. Für die Ausstellung eines Zertifikats benötigen Sie eine CSR-Datei. Generieren Sie sie daher 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:

Der Gültigkeitszeitraum darf 90 Tage nicht überschreiten.
Das Kästchen CanSignHttpExchanges-Erweiterung in das Zertifikat einfügen ist aktiviert, unter „Zusätzliche Zertifikatoptionen“ zu finden.

</ph> Klicken Sie auf das Kästchen neben **CanSignHttpExchanges-Erweiterung in das Zertifikat einfügen**.

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 die Verwendung von Tools schwer zu generieren. Du kannst eine der folgenden Optionen verwenden, um SXG zu generieren:

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

In dieser Anleitung wird libsxg verwendet.

Option 1: `libsxg` aus einem Debian-Paket installieren

Sie können das Paket wie gewohnt in Debian installieren, solange 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 kannst du SXG-Dateien dynamisch generieren, anstatt sie vor der Bereitstellung statisch zu generieren.

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

Das SXG-Modul für nginx ist auf GitHub verfügbar. 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

Zum Erstellen des Moduls nginx ist der Quellcode von nginx erforderlich. Mit den folgenden Befehlen kannst du das Tarball-Paket abrufen und zusammen mit dem dynamischen SXG-Modul 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 äußerst flexibel. Installieren Sie nginx an einer beliebigen Stelle in Ihrem System und geben Sie dann den entsprechenden Pfad module/config/log/pidfile an. In dieser Anleitung wird davon ausgegangen, dass Sie es auf /opt/nginx installieren.

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

Option 1: `nginx`-Modul vom Typ „Installierte aus Debian“ 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. Beachten Sie, dass Sie kein SXG-Zertifikat für SSL verwenden können (und umgekehrt). Daher benötigen Sie 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 wichtig, damit Browser SXG richtig laden können, weil die Zertifikatskette gefunden 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 alle CDNs oder andere Dienste zur Bereitstellung statischer Dateien bereitstellen, solange HTTPS unterstützt wird.
sxg_validitiy_url soll Informationen zum SXG-Signatur-Header bereitstellen. Wenn eine Seite seit der letzten SXG-Datei nicht geändert wurde, ist das Herunterladen der gesamten SXG-Datei aus technischer Sicht nicht erforderlich. Allein durch das Aktualisieren der Signatur-Header-Informationen wird daher voraussichtlich der Netzwerkverkehr reduziert. Die Details sind jedoch noch nicht implementiert.

Starte nginx und du kannst SXG ausliefern.

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: Integriertes `nginx`-Modul konfigurieren

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

Konfiguriere dein unter /opt/nginx installiertes nginx-System so, dass es dem folgenden Beispiel ähnelt:

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

Starte dann nginx. Hol dir deinen 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)

Schritt 5: Anwendungs-Back-End bereitstellen

In den obigen Beispielen stellt nginx statische Dateien im Stammverzeichnis bereit. Sie können jedoch Upstream-Anweisungen für Ihre Anwendungen verwenden, um SXG für beliebige Webanwendungs-Back-Ends (wie Ruby on Rails, Django oder Express) zu erstellen, solange Ihr nginx als Front-HTTP(S)-Server fungiert.

upstream app {
    server 127.0.0.1:8080;
}

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

Schritt 6: Testen

Verwenden Sie das dump-SignedExchange-Tool. um zu testen, ob die ausgelieferten SXGs korrekt sind und ob keine Fehler gemeldet werden. Außerdem solltest du prüfen, ob die Header korrekt sind. und Text 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 auf dein Feedback unter webpackage-dev@chromium.org. Sie können sich auch an der Diskussion über Spezifikationen beteiligen oder dem Team einen Fehler melden. Ihr Feedback hilft uns bei der Standardisierung und bei Problemen mit der Implementierung. Vielen Dank!