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

Podpisane wymiany 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 różnych przeglądarek

Kilka przeglądarek opartych na Chromium obsługuje SXG, w tym Google Chrome, Samsung. Internet i Microsoft Edge. Zobacz sekcję Konsensus i standaryzacja w Wymiana HTTP z podpisem źródła .

Wymagania wstępne

Aby wdrożyć SXG w witrynie, musisz:

mieć kontrolę nad domeną, w tym nad wpisami DNS;
Uzyskaj certyfikaty. SXG wymaga wystawienia dedykowanego certyfikatu. W szczególności nie można ponownie używać klucza ani certyfikatu TLS.
Musisz mieć serwer HTTP, który może generować i udostępniać SXG przez HTTPS.

Założenia

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

mieć środowisko OpenSSL 1.1.1, Ten przewodnik został napisany z użyciem systemu Ubuntu 18.04 LTS w systemie ISA amd64.
Musisz mieć możliwość uruchamiania plików wykonywalnych przy użyciu systemu sudo.
Użyj adresu nginx jako serwera HTTP.
korzystają z usługi DigiCert, aby generować certyfikaty, które obejmują rozszerzenia związane z SXG, ponieważ obecnie jest to jedyny dostawca, który obsługuje te rozszerzenia.

W przykładowych poleceniach w tym artykule przyjęto też, że Twoja domena to website.test, więc musisz zastąpić ciąg website.test swoją rzeczywistą domeną.

Krok 1. Uzyskaj certyfikat SXG

Aby wygenerować SXG, potrzebujesz certyfikatu TLS z rozszerzeniem CanSignHttpExchanges, a także określonego typu klucza. DigiCert zapewnia certyfikaty przy użyciu tego rozszerzenia. Do wystawiania certyfikatu potrzebujesz pliku żądania podpisania certyfikatu, 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"

Zobaczysz plik żądania podpisania certyfikatu, który będzie wyglądał tak:

Sprawdź, czy:

Okres ważności nie przekracza 90 dni.
pole wyboru Uwzględnij rozszerzenie CanSignHttpExchanges w certyfikacie jest włączone. który można znaleźć w sekcji „Additional Certificate options” (Dodatkowe opcje certyfikatu).

. Pole wyboru **Umieść rozszerzenie CanSignHttpExchanges w certyfikacie**.

Jeśli Twój certyfikat nie spełnia tych warunków, przeglądarki i dystrybutorzy odrzucili Twój certyfikat SXG ze względów bezpieczeństwa. W tym przewodniku przyjęto, że nazwa pliku certyfikatu uzyskanego z DigiCert to mySxg.pem.

Krok 2. Zainstaluj aplikację `libsxg`

Format SXG jest złożony i trudny do wygenerowania bez użycia narzędzi. Do wygenerowania SXG możesz użyć jednej z tych opcji:

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

W tym przewodniku: libsxg.

Opcja 1. Zainstaluj `libsxg` z pakietu Debiana

Możesz zainstalować ten pakiet w standardowy sposób systemu Debian, o ile wersja OpenSSL (libssl-dev) jest taka sama.

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. Skompiluj plik `libsxg` ręcznie

Jeśli nie używasz środowiska zgodnego z plikami .deb, możesz samodzielnie utworzyć aplikację libsxg. Warunkiem wstępnym jest zainstalowanie tych usług: 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 SXG zamiast statycznego generowania ich przed wyświetleniem.

Opcja 1. Zainstaluj wtyczkę z pakietu Debian

Moduł SXG dla języka nginx jest rozpowszechniany na GitHubie. W systemach opartych na Debianie możesz go zainstalować 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. Skompiluj wtyczkę ręcznie

Skompilowanie modułu nginx wymaga kodu źródłowego nginx. Możesz pobrać plik tar i utworzyć go wraz z modułem dynamicznym SXG, korzystając z 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 ma dużą elastyczność. Zainstaluj nginx w dowolnym miejscu w systemie, a potem podaj odpowiednią ścieżkę module/config/log/pidfile. W tym przewodniku zakładamy, że instalujesz ją w usłudze /opt/nginx.

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

Opcja 1. Skonfiguruj moduł `nginx` zainstalowany z systemu Debian

Wykonaj te instrukcje, jeśli wcześniej zdarzyło Ci się korzystać z kroku 3, opcji 1.

Dostarczanie treści SXG wymaga protokołu HTTPS. Certyfikat SSL/TLS możesz uzyskać m.in. od DigiCert, Let's Encrypt i innych usług. Pamiętaj, że NIE MOŻNA używać certyfikatu SXG z protokołem SSL ani na odwrót, dlatego potrzebujesz dwóch certyfikatów. Plik konfiguracji w /etc/nginx/nginx.conf powinien wyglądać podobnie do tej poniżej przy założeniu, ż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 do prawidłowego ładowania SXG przez przeglądarki, ponieważ lokalizuje łańcuch certyfikatów. Łańcuch certyfikatów zawiera informacje o certyfikacie i zszywaniu protokołu OCSP w formacie cbor. Pamiętaj, że nie musisz udostępniać pliku cert.cbor z tego samego źródła. Możesz udostępniać je przez dowolne sieci CDN lub inne usługi statycznego wyświetlania plików, o ile obsługują one HTTPS.
W sxg_validitiy_url zaplanowano wyświetlanie informacji związanych z nagłówkiem SXG-podpis. Jeśli strona nie była modyfikowana od czasu ostatniego SXG, ze względów technicznych nie jest wymagane pobranie całego pliku SXG. Aktualizacja samych informacji w nagłówku podpisu powinna więc ograniczyć ruch w sieci. Szczegóły nie zostały jeszcze wprowadzone.

Uruchom usługę nginx, aby skorzystać z usług 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 na podstawie źródła

Wykonaj te instrukcje, jeśli wcześniej zdarzyło Ci się korzystać z kroku 3, opcji 2.

Skonfiguruj system nginx zainstalowany w katalogu /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 zdobyć 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. Udostępnij backend aplikacji

W powyższych przykładach nginx udostępnia pliki statyczne w katalogu głównym, ale możesz użyć dyrektyw nadrzędnych dla aplikacji, aby utworzyć SXG dla dowolnych backendów aplikacji internetowych (takich jak Ruby on Rails, Django czy Express), o ile nginx działa jako serwer HTTP(S).

upstream app {
    server 127.0.0.1:8080;
}

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

Krok 6. Przetestuj

Użyj narzędzia dump- signedExchange. aby sprawdzić, czy wyświetlane SXG są prawidłowe, sprawdzić, czy nie są zgłaszane błędy i 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 Chromium, którzy pracują nad SXG, chcą poznać Twoją opinię 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 będzie bardzo przydatna w procesie standaryzacji i rozwiązaniu problemów z implementacją. Dziękujemy!