Ta strona została przetłumaczona przez Cloud Translation API.

Jak skonfigurować podpisane wymiany HTTP (SXG) przy użyciu nginx

Jak wygenerować certyfikat TLS z rozszerzeniami SXG, zainstalować narzędzia do generowania plików SXG i skonfigurować nginx do obsługi plików SXG.

Hiroki Kumazaki

Podpisana wymiana HTTP (SXG) to nowa technologia internetowa, która ułatwia użytkownikom odróżnianie twórców treści od dystrybutorów treści. Z tego przewodnika dowiesz się, jak skonfigurować SXG.

Obsługa w różnych przeglądarkach

SXG obsługują niektóre przeglądarki oparte na Chromium, w tym Google Chrome, Samsung Internet i Microsoft Edge. Najnowsze informacje znajdziesz w sekcji „Konsensus i standardy” w artykule Wymiana danych HTTP z podpisem źródłowym.

Wymagania wstępne

Aby wdrożyć SXG w swojej witrynie, musisz:

mieć kontrolę nad domeną, w tym nad wpisami DNS;
Pobieranie certyfikatów. SXG wymaga wydania specjalnego certyfikatu. W szczególności nie możesz ponownie użyć klucza ani certyfikatu TLS.
mieć serwer HTTP, który może generować i przesyłać SXG przez HTTPS;

Założenia

W tym przewodniku przyjęto założenie, że:

Użyj środowiska OpenSSL w wersji 1.1.1. Ten przewodnik został napisany na podstawie Ubuntu 18.04 LTS na procesorze amd64 ISA.
Możliwość uruchamiania sudo w celu instalowania plików wykonywalnych.
Użyj nginx jako serwera HTTP.
Używasz DigiCert do generowania certyfikatów, które zawierają rozszerzenia związane z SXG, ponieważ wydaje się, że jest to obecnie jedyny dostawca, który obsługuje te rozszerzenia.

Przykładowe polecenia w tym artykule zakładają, że Twoja domena to website.test, więc musisz zastąpić website.test swoją domeną.

Krok 1. Pobierz certyfikat SXG

Aby wygenerować SXG, musisz mieć certyfikat TLS z rozszerzeniem CanSignHttpExchanges oraz określony typ klucza. DigiCert udostępnia certyfikaty z tym rozszerzeniem. Do wydania certyfikatu potrzebny jest plik CSR, więc wygeneruj go za pomocą tych poleceń:

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"

Otrzymasz plik CSR, który będzie wyglądał tak:

Sprawdź, czy:

Okres ważności nie przekracza 90 dni.
W polu wyboru Uwzględnij w certyfikacie rozszerzenie CanSignHttpExchanges (znajdziesz je w sekcji Dodatkowe opcje certyfikatu) zaznacz pole wyboru.

Zaznacz pole wyboru **Uwzględnij rozszerzenie CanSignHttpExchanges w certyfikacie**.

Jeśli certyfikat nie spełnia tych warunków, przeglądarki i dystrybutorzy odrzucą SXG ze względów bezpieczeństwa. W tym przewodniku zakładamy, że nazwa pliku certyfikatu otrzymanego od DigiCert to mySxg.pem.

Krok 2. Zainstaluj `libsxg`

Format SXG jest skomplikowany i trudno go wygenerować bez użycia narzędzi. Aby wygenerować SXG, możesz użyć jednej z tych opcji:

Narzędzie gen-signedexchange napisane w języku Go.
Biblioteka libsxg napisana w C.

W tym przewodniku używamy libsxg.

Opcja 1. Zainstaluj `libsxg` z pakietu Debiana

Pakiet możesz zainstalować w zwykły sposób w systemie Debian, o ile wersja OpenSSL (libssl-dev) jest zgodna.

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

Opcja 2. Ręczne tworzenie `libsxg`

Jeśli nie używasz środowiska zgodnego z plikami .deb, możesz samodzielnie skompilować libsxg. Wstępnie musisz zainstalować git, cmake, openssl i 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

Krok 3. Zainstaluj wtyczkę `nginx`

Wtyczka nginx umożliwia dynamiczne generowanie plików SXG zamiast statycznych przed ich wyświetleniem.

Opcja 1. Zainstaluj wtyczkę z pakietu Debiana

Moduł SXG dla nginx jest rozpowszechniany na GitHubie. W systemach opartych na Debianie możesz zainstalować go jako pakiet binarny:

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

Opcja 2. Ręczne skompilowanie wtyczki

Kompilacja modułu nginx wymaga kodu źródłowego nginx. Możesz pobrać plik tarball i skompilować go wraz z modułem dynamicznym SXG, używając tych poleceń:

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

Konfiguracja nginx jest bardzo elastyczna. Zainstaluj nginx w dowolnym miejscu w systemie, a następnie określ odpowiednią ścieżkę module/config/log/pidfile. W tym przewodniku przyjęto założenie, że instalujesz go w /opt/nginx.

Krok 4. Skonfiguruj wtyczkę `nginx` do współpracy z SXG

Opcja 1. Skonfiguruj moduł zainstalowany z Debiana `nginx`

Jeśli wcześniej zastosowałeś(-aś) krok 3, opcję 1, wykonaj te instrukcje.

Przesyłanie treści SXG wymaga protokołu HTTPS. Certyfikat SSL/TLS możesz uzyskać od DigiCert, Let's Encrypt i innych usług. Pamiętaj, że nie możesz używać certyfikatu SXG do SSL ani odwrotnie, dlatego potrzebujesz 2 certyfikatów. Plik konfiguracji w /etc/nginx/nginx.conf powinien wyglądać podobnie do tego, zakładając, że para klucz/certyfikat SSL znajduje się w /path/to/ssl/, a para klucz/certyfikat SXG – w /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 jest niezbędny, aby przeglądarki mogły prawidłowo wczytywać SXG, ponieważ wskazuje łańcuch certyfikatów. Łańcuch certyfikatów zawiera informacje o certyfikacie i sztaplowaniu OCSP w formacie cbor. Pamiętaj, że nie musisz przesyłać pliku cert.cbor z tego samego źródła. Możesz go wyświetlać za pomocą dowolnej sieci CDN lub innej usługi wyświetlania plików statycznych, o ile obsługuje protokół HTTPS.
sxg_validitiy_url ma służyć do dostarczania informacji związanych z nagłówkiem podpisu SXG. Jeśli od ostatniego SXG strona nie została zmodyfikowana, technicznie nie jest wymagane pobieranie całego pliku SXG. Dlatego samo zaktualizowanie informacji z nagłówka podpisu powinno zmniejszyć ruch w sieci. Szczegóły nie są jednak jeszcze zaimplementowane.

Uruchom nginx, aby wyświetlać SXG.

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)

Opcja 2. Skonfiguruj moduł `nginx` utworzony z źródła

Postępuj zgodnie z tymi instrukcjami, jeśli wcześniej wykonałeś(-aś) krok 3, opcja 2.

Skonfiguruj system nginx zainstalowany w ramach /opt/nginx tak, aby wyglądał podobnie do tego przykładu:

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

Następnie uruchom nginx. Teraz możesz pobrać plik 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)

Krok 5. Uruchom backend aplikacji

W powyższych przykładach usługa nginx udostępnia pliki statyczne w katalogu głównym, ale możesz użyć dyrektyw upstream w swoich aplikacjach, aby utworzyć SXG dla dowolnego backendu aplikacji internetowej (np. Ruby on Rails, Django czy Express), o ile usługa nginx działa jako serwer HTTP(S) front-end.

upstream app {
    server 127.0.0.1:8080;
}

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

Krok 6. Test

Użyj narzędzia dump-signedexchange, aby sprawdzić, czy wyświetlane SXG są prawidłowe, czy nie występują błędy oraz czy nagłówki i treść są zgodne z oczekiwaniami.

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

Prześlij opinię

Inżynierowie z zespołu Chromium pracujący nad SXG chętnie poznają Twoją opinię. Napisz do nich na adres webpackage-dev@chromium.org. Możesz też dołączyć do dyskusji na temat specyfikacji lub zgłosić błąd zespołowi. Twoja opinia znacznie ułatwi proces standaryzacji i pomoże rozwiązać problemy z wdrażaniem. Dziękujemy!