SXG 확장 프로그램으로 TLS 인증서를 생성하고 SXG 파일 생성 도구를 설치하며 SXG 파일을 제공하도록 nginx를 구성하는 방법
서명된 HTTP 교환 (SXG)은 사용자가 콘텐츠 크리에이터와 콘텐츠 배급사를 쉽게 구분할 수 있도록 하는 새로운 웹 기술입니다. 이 가이드에서는 SXG를 설정하는 방법을 보여줍니다.
교차 브라우저 지원
Chrome, Samsung 등 여러 Chromium 기반 브라우저에서 SXG 지원 인터넷, Microsoft Edge에 해당합니다. 이 문서의 합의 및 표준화 섹션을 출처 서명 HTTP 교환 에서 최신 정보를 확인하세요.
기본 요건
웹사이트에 SXG를 구현하려면 다음 요건을 충족해야 합니다.
- DNS 항목을 포함하여 도메인을 제어합니다.
- 인증서를 가져옵니다. SXG는 전용 인증서를 발급해야 합니다. 특히 TLS 키나 인증서는 재사용할 수 없습니다.
- HTTPS를 통해 SXG를 생성하고 제공할 수 있는 HTTP 서버가 있어야 합니다.
가정
이 가이드에서는 다음을 가정합니다.
- OpenSSL 1.1.1 환경을 사용합니다. 이 가이드는 amd64 ISA에서 Ubuntu 18.04 LTS를 사용하여 작성되었습니다.
sudo
를 실행하여 실행 파일을 설치할 수 있어야 합니다.nginx
를 HTTP 서버로 사용합니다.- 현재 DigiCert에서 SXG 관련 확장 프로그램을 지원하는 유일한 제공업체인 것으로 보이기 때문에 DigiCert를 사용하여 SXG 관련 확장 프로그램을 포함하는 인증서를 생성합니다.
또한 이 도움말의 예시 명령어에서는 도메인이 website.test
이라고 가정하므로 website.test
을 실제 도메인으로 바꿔야 합니다.
1단계: SXG 인증서 받기
SXG를 생성하려면 CanSignHttpExchanges
확장자가 있는 TLS 인증서와 특정 키 유형이 필요합니다.
DigiCert는 이 확장자를 통해 인증서를 제공합니다.
인증서 발급을 위해 CSR 파일이 필요하므로 다음 명령어를 사용하여 생성합니다.
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"
다음과 같은 CSR 파일이 생성됩니다.
-----BEGIN CERTIFICATE REQUEST-----
MIHuMIGVAgEAMDMxDTALBgNVBAoMBFRlc3QxCzAJBgNVBAYTAlVTMRUwEwYDVQQD
DAx3ZWJzaXRlLnRlc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS7IVaeMvid
S5UO7BspzSe5eqT5Qk6X6dCggUiV/vyqQaFDjA/ALyTofgXpbCaksorPaDhdA+f9
APdHWkTbbdv1oAAwCgYIKoZIzj0EAwIDSAAwRQIhAIb7n7Kcc6Y6pU3vFr8SDNkB
kEadlVKNA24SVZ/hn3fjAiAS2tWXhYdJX6xjf2+DL/smB36MKbXg7VWy0K1tWmFi
Sg==
-----END CERTIFICATE REQUEST-----
다음 사항을 확인하세요.
- 유효 기간은 90일을 초과하지 않습니다.
- 인증서에 CanSignHttpExchanges 확장 프로그램 포함 체크박스가 선택되어 있습니다. 이 인증서 옵션은 추가 인증서 옵션 아래에 있습니다.
![](https://web.developers.google.cn/static/articles/how-to-set-up-signed-http-exchanges/image/kFWTZFXNvwkHnwRu7y8Q.png?authuser=9&hl=ko)
인증서가 이러한 조건과 일치하지 않으면 브라우저와 배포자에서 보안상의 이유로 SXG를 거부합니다.
이 가이드에서는 DigiCert에서 받은 인증서의 파일 이름이 mySxg.pem
이라고 가정합니다.
2단계: libsxg
설치하기
SXG 형식은 복잡하며 도구를 사용하지 않고는 생성하기 어렵습니다. 다음 옵션 중 하나를 사용하여 SXG를 생성할 수 있습니다.
- Go로 작성된 gen-signedexchange 도구
- C로 작성된
libsxg
라이브러리.
이 가이드에서는 libsxg
를 사용합니다.
옵션 1: Debian 패키지에서 libsxg
설치
OpenSSL (libssl-dev
) 버전이 일치하면 일반적인 Debian 방법으로 패키지를 설치할 수 있습니다.
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
옵션 2: libsxg
를 수동으로 빌드
.deb
파일과 호환되는 환경을 사용하지 않는 경우 libsxg
를 직접 빌드할 수 있습니다.
전제조건으로 git
, cmake
, openssl
, 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
3단계: nginx
플러그인 설치하기
nginx
플러그인을 사용하면 SXG를 제공하기 전에 정적으로 생성하는 대신 동적으로 생성할 수 있습니다.
옵션 1: Debian 패키지에서 플러그인 설치
nginx
용 SXG 모듈은 GitHub에 배포됩니다.
Debian 기반 시스템에서는 바이너리 패키지로 설치할 수 있습니다.
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
옵션 2: 수동으로 플러그인 빌드
nginx
모듈을 빌드하려면 nginx
소스 코드가 필요합니다.
아래 명령어를 사용하여 tarball을 가져와 SXG 동적 모듈과 함께 빌드할 수 있습니다.
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
nginx
구성은 유연성이 높습니다.
시스템의 아무 곳에나 nginx
를 설치한 후 각 경로 module/config/log/pidfile
를 지정합니다.
이 가이드에서는 /opt/nginx
에 설치한다고 가정합니다.
4단계: SXG와 호환되도록 nginx
플러그인 구성
옵션 1: Debian에서 설치한 nginx
모듈 구성
이전에 3단계, 옵션 1을 사용한 경우 이 안내를 따르세요.
SXG 콘텐츠를 전송하려면 HTTPS가 필요합니다. DigiCert, Let's Encrypt 및 기타 서비스에서 SSL/TLS 인증서를 받을 수 있습니다. SXG 인증서를 SSL용으로 사용하거나 그 반대로 사용할 수 없으므로 두 개의 인증서가 필요합니다. /path/to/ssl/
에 SSL 키/인증서 쌍을, /path/to/sxg/
에 SXG 키/인증서 쌍을 설정했다고 가정하면 /etc/nginx/nginx.conf
의 구성 파일은 다음과 유사합니다.
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
는 인증서 체인을 찾기 때문에 브라우저가 SXG를 올바르게 로드하는 데 필수적입니다. 인증서 체인에는 cbor 형식의 인증서 및 OCSP 스테이플링 정보가 포함됩니다. 동일한 출처의cert.cbor
파일을 제공할 필요는 없습니다. HTTPS를 지원하는 한 CDN 또는 기타 정적 파일 제공 서비스를 통해 제공할 수 있습니다.sxg_validitiy_url
는 SXG 서명 헤더 관련 정보를 제공할 계획입니다. 마지막 SXG 이후 페이지가 수정되지 않은 경우 전체 SXG 파일을 다운로드할 필요는 기술적으로 필요하지 않습니다. 따라서 서명 헤더 정보만 업데이트하면 네트워크 트래픽이 줄어들 수 있습니다. 하지만 세부정보는 아직 구현되지 않았습니다.
nginx
를 시작하면 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)
옵션 2: 소스에서 빌드된 nginx
모듈 구성
이전에 3단계, 옵션 2를 사용한 경우 이 안내를 따르세요.
/opt/nginx
아래에 설치된 nginx
시스템을 다음 예시와 유사하게 구성합니다.
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;
}
}
그런 다음 nginx
를 시작합니다. 이제 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)
5단계: 애플리케이션 백엔드 제공
위의 예에서 nginx
는 루트 디렉터리에 정적 파일을 제공하지만 nginx
가 프론트 HTTP (S) 서버로 작동하는 경우 애플리케이션에 업스트림 지시문을 사용하여 임의의 웹 애플리케이션 백엔드(예: Ruby on Redis, Django 또는 Express)에 SXG를 만들 수 있습니다.
upstream app {
server 127.0.0.1:8080;
}
server {
location / {
proxy_pass http://app;
}
}
6단계: 테스트
dump-signedexchange 도구 사용 를 사용하여 게재 중인 SXG가 올바른지 테스트하고 오류가 보고되지 않는지 확인하며 헤더가 본문은 예상대로입니다.
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
의견 보내기
SXG를 담당하고 있는 Chromium 엔지니어들은 webpackage-dev@chromium.org를 통해 여러분의 의견을 듣고자 합니다. 사양 토론에 참여하거나 팀에 버그를 신고할 수도 있습니다. 여러분의 의견은 표준화 과정을 진행하고 구현 문제를 해결하는 데 큰 도움이 됩니다. 감사합니다.