
F5 NGINX Plus Release 33(R33)의 출시를 발표하게 되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R33의 새로운 기능 및 향상된 기능은 다음과 같습니다.
NGINX Plus의 라이선싱 변경 사항: NGINX Plus R33부터 모든 고객은 각 상용 NGINX Plus 인스턴스에 JWT(JSON Web Token) 라이선스를 배포해야 합니다. 또한 각 인스턴스는 라이선스 상태를 검증하고 연결된 고객의 경우 F5 라이선스 엔드포인트에 F5 NGINX 사용량을 보고하고, 오프라인/에어 갭 고객의 경우 F5 NGINX Instance Manager에 보고합니다.
포스트 퀀텀 암호화(Post Quantum Cryptography) 지원 : NGINX Plus R33은 NGINX의 포스트 퀀텀 암호화에 대한 지원을 발표하여 장기적인 데이터 전송 보안을 보장하고 기업이 암호화의 향후 변화에 대비할 수 있도록 합니다.
NGINX JavaScript의 QuickJS 런타임 지원: QuickJS는 ES2023 사양을 지원하고, 즉시 가비지 수집을 제공하며, 기존 JavaScript 런타임 엔진보다 성능 향상을 제공하는 가볍고 포함 가능한 JavaScript 엔진입니다. 사용 편의성을 위해 이 런타임은 공존하며 NGINX JavaScript 모듈의 기존 JavaScript 런타임에 대한 드롭인 대체품으로 제공됩니다.
스트림 모듈의 OCSP 스테이플링 지원: NGINX Plus R33은 스트림 모듈에서 OCSP(온라인 인증서 상태 프로토콜) 스테이플링 및 클라이언트 인증서 확인에 대한 지원을 도입했습니다.
릴리스를 마무리하는 것은 NGINX 오픈 소스에서 상속된 새로운 기능과 버그 수정, NGINX JavaScript 모듈에 대한 업데이트입니다.
행동의 중요한 변화
참고: NGINX Plus R32 이외의 릴리스에서 업그레이드하는 경우 현재 버전과 이 버전 사이의 모든 릴리스에 대한 이전 NGINX Plus 릴리스 발표 블로그의 Important Changes in Behavior 섹션을 검토해야 합니다.
NGINX 라이선싱 변경 사항
NGINX Plus R33 릴리스부터 NGINX가 작동하려면 유효한 JWT 라이선스가 필요합니다. 서브스크립션당 단일 JWT 라이선스가 있으며 해당 서브스크립션과 연결된 각 NGINX 인스턴스에 배치해야 합니다.
또한 모든 고객은 상용 NGINX 사용량을 F5에 보고해야 합니다. 기본적으로 사용 보고서는 자동으로 F5 라이선스 엔드포인트로 전송됩니다. 네트워크 제한 환경의 경우 NGINX 인스턴스 관리자를 통해 사용 보고서를 라우팅하는 옵션이 있습니다.
플랫폼 지원 변경 사항
이 릴리스에서 지원되는 플랫폼이 다음과 같이 변경되었습니다.
추가된 플랫폼:
제거된 플랫폼:
- CentOS 7 / RHEL 7 / 오라클 리눅스 7
- 알파인 리눅스 3.16
더 이상 사용되지 않는 플랫폼:
새로운 기능 세부 정보
NGINX Plus의 라이선스 변경 사항:
NGINX Plus R33 릴리스를 통해 NGINX 상용 제품의 라이선스 부여 방식에 주목할 만한 변경 사항을 도입하고 있습니다. 전제 조건으로, 모든 NGINX 인스턴스에 JWT 라이선스를 배포해야 합니다. 구독당 단일 라이선스가 있으며 해당 구독에 포함된 모든 인스턴스에 설치해야 합니다. 라이선스는 MyF5 계정에서 얻을 수 있습니다. 라이선스를 받고 NGINX 인스턴스에 배포하는 방법에 대한 지침은 여기를 참조하십시오.
NGINX Plus R33 릴리스를 통해 모든 NGINX 고객은 상용 NGINX 사용량도 F5에 보고해야 합니다.
기본적으로 사용량은 F5 라이선싱 엔드포인트에 보고됩니다. 연결 요구 사항에 대해서는 여기의 지침을 참조하십시오.
NGINX 인스턴스에 외부 네트워크 제한이 있는 환경의 경우 NGINX 사용량을 F5로 보내는 연결된 모드와 연결이 끊긴 모드를 모두 제공하는 NGINX 인스턴스 관리자에 사용량을 보고해야 합니다. NGINX 인스턴스를 구성하고 상용 사용 텔레메트리를 NGINX 인스턴스 관리자로 보내는 방법에 대한 지침은 여기를 참조하십시오.
이러한 변경 사항에 대한 전체 개요는 NGINX 라이선스 문서를 참조하십시오.
Post Quantum Cryptography 지원:
양자 컴퓨팅의 발전으로 RSA 및 ECC와 같은 기존 암호화 알고리즘은 잠재적인 양자 컴퓨터 공격에 취약해지고 있습니다. 이를 위해서는 이러한 공격에 저항하는 포스트 양자 암호화(PQC)로의 전환이 필요합니다.
NGINX Plus R33에서 PQC(Post Quantum Cryptography)에 대한 초기 지원을 발표하게 되어 기쁩니다.
NGINX는 OpenSSL 3.x용 Open Quantum Safe 공급자 라이브러리(oqs-provider)를 사용하여 PQC 지원을 제공합니다. 이 라이브러리는 OQS(Open Quantum Safe) 프로젝트에서 사용할 수 있습니다. oqs-provider 라이브러리는 OQS 프로젝트에서 지원하는 모든 포스트 퀀텀 알고리즘에 대한 지원을 OpenSSL-3 의존 애플리케이션의 TLS와 같은 네트워크 프로토콜에 추가합니다. oqs-provider에서 제공하는 모든 암호/알고리즘은 NGINX에서 지원됩니다.
oqs-provider를 사용하여 PQC 지원으로 NGINX를 구성하려면 다음 단계를 수행합니다.
- 필요한 종속성 설치
sudo apt update sudo apt install -y build-essential git cmake ninja-build libssl-dev pkg-config
|
- liboqs 다운로드 및 설치
git clone --branch main https://github.com/open-quantum-safe/liboqs.git cd liboqs mkdir build && cd build cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DOQS_DIST_BUILD=ON .. ninja sudo ninja install
|
- oqs-provider 다운로드 및 설치
git clone --branch main https://github.com/open-quantum-safe/oqs-provider.git cd oqs-provider mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl .. make -j$(nproc) sudo make install
|
- oqs-provider 지원으로 OpenSSL 다운로드 및 설치
git clone https://github.com/openssl/openssl.git cd openssl ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl linux-x86_64 make -j$(nproc) sudo make install_sw
|
- oqs-provider에 대한 OpenSSL 구성
/usr/local/ssl/openssl.cnf: openssl_conf = openssl_init
[openssl_init] providers = provider_sect
[provider_sect] default = default_sect oqsprovider = oqsprovider_sect
[default_sect] activate = 1
[oqsprovider_sect] activate = 1
|
- 포스트 퀀텀 인증서 생성
export OPENSSL_CONF=/usr/local/ssl/openssl.cnf
# Generate CA key and certificate /usr/local/ssl/bin/openssl req -x509 -new -newkey dilithium3 -keyout ca.key -out ca.crt -nodes -subj "/CN=Post-Quantum CA" -days 365 # Generate server key and certificate signing request (CSR) /usr/local/ssl/bin/openssl req -new -newkey dilithium3 -keyout server.key -out server.csr -nodes -subj "/CN=your.domain.com" # Sign the server certificate with the CA /usr/local/ssl/bin/openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365
|
- 포스트 퀀텀 인증서를 사용하도록 NGINX 구성\
server {
listen 0.0.0.0:443 ssl; ssl_certificate /path/to/server.crt; ssl_certificate_key /path/to/server.key; ssl_protocols TLSv1.3; ssl_ecdh_curve kyber768;
location / { return 200 "$ssl_curve $ssl_curves"; } }
|
NGINX JavaScript 모듈의 QuickJS 런타임 지원:
NGINX JavaScript는 서버 측 사용 사례 및 요청별 처리를 위해 특별히 설계된 NGINX 및 NGINX Plus를 위한 고유한 JavaScript 구현입니다. 복잡한 구성 솔루션을 구현하기 위해 JavaScript 코드로 NGINX 구성 구문을 확장합니다.
오늘날 NGINX JavaScript 모듈에서 사용되는 JavaScript 런타임 엔진은 전적으로 NGINX 팀에서 개발하고 유지 관리합니다. 기능 개발 및 우선 순위 지정 측면에서 분명한 이점이 있지만 빠르게 발전하는 JavaScript 사양은 따라잡기 어려운 작업입니다. NGINX JavaScript는 현재 ECMAScript 6 이상의 요소와 함께 ECMAScript 5.1을 따릅니다.
사양 문제를 해결하기 위해 NGINX JavaScript 모듈 버전 0.8.6에서 QuickJS 런타임에 대한 미리 보기 지원을 도입하게 되어 기쁩니다. QuickJS는 ES2023 사양을 지원하고, 즉시 사용할 수 있는 가비지 수집을 제공하며, 향상된 성능을 제공하는 가볍고 포함 가능한 JavaScript 엔진입니다. 그리고 두 가지 장점을 모두 제공하기 위해 QuickJS는 NGINX JavaScript 런타임과 공존하며 njs 스크립트에서 드롭인 대체품으로 사용할 수 있습니다. 기존 기능에 대한 전체 지원은 향후 릴리스에서 사용할 수 있습니다.
njs 스크립트에서 QuickJS를 활용하는 방법과 현재 지원되는 함수에 대한 자세한 내용은 설명서를 참조하세요.
스트림 모듈의 OCSP 클라이언트 확인 및 스테이플링 지원:
OCSP(Online Certificate Status Protocol)는 SSL 인증서가 해지되었는지 확인하기 위한 프로토콜입니다. SSL 협상 시간을 줄이기 위해 CRL의 대안으로 만들어졌습니다. CRL(인증서 해지 목록)을 사용하면 브라우저가 해지된 인증서 일련 번호 목록을 다운로드하고 현재 인증서를 확인하므로 SSL 협상 시간이 늘어납니다. OCSP에서 클라이언트 인증서가 제공되면 브라우저는 OCSP URL로 요청을 보내고 인증서의 유효성 상태가 포함된 응답을 받습니다.
현재 NGINX Plus는 http 모듈에서 OCSP 클라이언트 인증서 확인 및 스테이플링을 지원합니다. R33에서는 OCSP 클라이언트 인증서 확인 및 스테이플링 지원을 스트림 모듈에도 제공합니다.
SSL 클라이언트 인증서의 OCSP 유효성 검사를 사용하도록 설정하려면 인증서 확인을 가능하게 하는 ssl_verify_client 지시문(on 또는 선택 사항으로 설정해야 함)과 함께 새 ssl_ocsp 지시문을 포함합니다.
통사론:
ssl_ocsp on | off | leaf; (default is off, the leaf parameter enables validation of the client certificate only.)
|
그러나 OCSP에는 개인 정보 보호와 CA 서버의 과부하라는 두 가지 문제가 있습니다. OCSP는 브라우저가 인증서 유효성을 확인하기 위해 CA에 연결하도록 요구하기 때문에 개인 정보가 손상됩니다. CA는 어떤 웹 사이트가 액세스되고 있으며 누가 액세스했는지 알고 있습니다. 또한 HTTPS 웹 사이트에 많은 방문자가 있는 경우 CA의 OCSP 서버는 방문자의 모든 OCSP 요청을 처리해야 합니다.
여기에서 OCSP 스테이플링이 작동합니다. OCSP 스테이플링은 성능을 개선하고 방문자 개인 정보를 유지하면서 SSL 협상의 성능을 향상시키는 것을 목표로 하는 TLS/SSL 확장입니다. OCSP 스테이플링을 사용하면 인증서 보유자(읽기 웹 서버)가 OCSP 서버를 직접 쿼리하고 응답을 캐시합니다. 이 응답은 인증서 상태 요청 확장 응답을 통해 TLS/SSL 핸드셰이크와 함께 "스테이플"됩니다. 결과적으로 CA의 서버는 요청으로 인한 부담을 갖지 않으며 브라우저는 더 이상 사용자의 브라우징 습관을 제3자에게 공개할 필요가 없습니다.
OCSP 스테이플링을 활성화하려면 ssl_stapling 지시문을 사용합니다.
ssl_stapling on | off; (default is off)
|
스트림 컨텍스트에서 OCSP 인증서 확인 및 스테이플링을 위해 이러한 지시문 및 관련 지시문을 사용하는 방법에 대한 자세한 내용은 NGINX 설명서를 참조하십시오.
NGINX Plus R33의 기타 개선 사항 및 버그 수정
HTTP 응답 트레일러 지원
HTTP 응답 트레일러를 사용하면 발신자가 청크 메시지 끝에 추가 필드를 추가할 수 있으며 응답 본문과 함께 처리 상태, 디지털 서명 등과 같은 추가 동적 콘텐츠를 전달하는 데 사용할 수 있습니다. HTTP/1.1로 트레일러를 활성화하는 방법 및 HTTP 트레일러를 사용할 수 없는 사용 사례에 대해서는 여기를 참조하십시오.
현재 트레일러는 grpc_pass 지시문을 사용하는 gRPC 프록시에서만 지원됩니다. 이 개선 사항은 proxy_pass의 트레일러에 대한 지원도 추가합니다. 새로운 지시문 proxy_pass_trailers가 도입되어 프록시된 업스트림에서 클라이언트로 트레일러 필드를 전달할 수 있습니다.
샘플 구성
location / { proxy_http_version 1.1; proxy_set_header Connection "te"; proxy_set_header TE "trailers"; proxy_pass_trailers on; proxy_pass ... }
|
SSL 키 로깅
이 향상된 기능을 사용하면 파일에 대한 클라이언트 및 업스트림 연결 중에 생성된 SSL 키를 로깅할 수 있습니다. 이는 SSL 트래픽의 암호를 해독하고 SSL 키를 검사하려는 경우 문제를 해결하는 데 유용합니다. 파일은 SSLKEYLOGFILE 형식이며 지시문에 인수로 전달됩니다.
ssl_key_log, proxy_ssl_key_log, grpc_ssl_key_log 및 uwsgi_ssl_key_log 지시문은 SSL 키 로깅을 지원하기 위해 R33 릴리스에 도입되었습니다.
SSL 키를 파일에 로깅하기 위한 샘플 구성:
ssl_key_log /tmp/sslkey.log; proxy_key_log /tmp/sslkey.log;
|
SSL 클라이언트 인증서 확인 개선 사항
NGINX Plus R33 릴리스에서는 ssl_verify_client 지시문을 사용할 때 클라이언트 SSL 인증서 확인에 "ssl_client_certificate" 지시문이 더 이상 필요하지 않습니다. 이 변경은 ssl_client_certificate 지시문에 하나 이상의 신뢰할 수 있는 CA 인증서가 있어야 하는 이전 요구 사항을 완화합니다. 필요한 경우 ssl_trusted_certificate 지시문을 사용하여 모든 신뢰할 수 있는 CA 인증서를 지정할 수도 있습니다.
버그 수정:
- SSL 인증서 캐싱: 중복된 DN(고유 이름)이 있는 항목을 포함하는 신뢰할 수 있는 CA 번들의 로드를 수정했습니다.
NGINX 오픈 소스에서 상속된 변경 사항
NGINX Plus R33은 NGINX 오픈 소스 1.27.2를 기반으로 하며 NGINX Plus R32가 출시된 이후(NGINX 오픈 소스 1.27.0, 1.27.1 및 1.27.2).
기능:
- SSL 인증서, 비밀 키 및 CRL은 이제 시작 시 또는 재구성 중에 캐시됩니다.
- 스트림 모듈에서 OCSP를 사용한 클라이언트 인증서 유효성 검사에 대한 지원이 추가되었습니다.
- 스트림 모듈에서 OCSP 스테이플링에 대한 지원이 추가되었습니다.
- ngx_http_proxy_module에서 proxy_pass_trailers 지시문에 대한 지원이 추가되었습니다.
- ssl_client_certificate 지시문은 이제 보조 정보가 있는 인증서를 지원합니다.
- "proxy_limit_rate", "fastcgi_limit_rate", "scgi_limit_rate" 및 "uwsgi_limit_rate" 지시문에서 변수를 지원합니다.
변경:
- ssl_client_certificate 지시문은 클라이언트 SSL 인증서 확인에 더 이상 필요하지 않습니다.
- stream 모듈 처리기는 더 이상 필수가 아닙니다.
버그 수정:
- 새 HTTP/2 연결은 이전 작업자 프로세스의 정상 종료를 무시할 수 있습니다.
- "gzip", "gunzip", "ssi", "sub_filter" 또는 "grpc_pass" 지시문을 사용할 때 수명이 긴 요청에 대한 메모리 소비가 줄었습니다.
안전:
- CVE-2024-7347 - ngx_http_mp4_module에서 특수하게 조작된 mp4 파일을 처리하면 작업자 프로세스 충돌이 발생할 수 있습니다.
최신 릴리스에서 상속된 새로운 변경 사항, 기능, 버그 수정 및 해결 방법의 전체 목록은 NGINX 변경 사항을 참조하십시오 .
NGINX JavaScript 모듈에 대한 변경 사항
NGINX Plus R33은 NGINX JavaScript(njs) 모듈 버전 0.8.7의 변경 사항을 통합합니다. 다음은 0.8.4 (NGINX Plus R32와 함께 제공되는 버전) 이후 njs의 주목할만한 변경 사항 목록입니다.
기능
- QuickJS JavaScript 엔진에 대한 초기 지원이 도입되었습니다.
- 지시문에 대한 선택적 nocache 플래그js_set 추가되었습니다.
- HTTP 모듈에서 캡처 그룹 변수가 노출되었습니다.
- 공유 딕셔너리의 add(), set(), incr() 메서드에 대한 timeout 인자를 추가했습니다.
변경
- UTF-8 인코딩에서 유효하지 않은 바이트는 다음에서 대체 문자로 변환됩니다.
- r.variables.var, r.requestText, r.responseText, s.variables.var
- upload 또는 download 이벤트 유형이 있는 s.on() 콜백의 data 인수
- js_body_filter 지시문의 data 인수입니다.
버그 수정
- 함수에서 비어 있는 레이블이 지정된 명령문의 처리를 수정했습니다.
- 인수 없이 호출될 때의 Function 생성자 처리를 수정했습니다.
- Buffer.prototype.writeInt8()과 친구들을 수정했습니다.
- Buffer.prototype.writeFloat()와 친구들을 수정했습니다.
- Buffer.prototype.lastIndexOf()를 수정했습니다.
- Buffer.prototype.write()를 수정했습니다.
- 오류 생성에서 초기화되지 않은 경고를 수정했습니다.
- UTF-8 디코딩에서 'ctx.codepoint' 초기화가 수정되었습니다.
- Array.prototype.pop()의 '길이' 초기화를 수정했습니다.
- fs.readdir()과 fs.realpath()에서 encode arg 처리를 수정했습니다.
- 중복된 js_set 변수 검사를 수정했습니다.
- 포트가 비표준일 때 요청 Host 헤더를 수정했습니다.
- ngx.fetch() 및 r.subrequest() 에서 길이가 0인 요청 본문 처리를 수정했습니다 .
- Headers.get()의 heap-buffer-overflow를 수정했습니다.
- r.subrequest() 에러 처리를 수정했습니다.
- zlib.inflate()를 수정했습니다.
- 길이가 0인 인수로 String.prototype.replaceAll()을 수정했습니다.
- Array.prototype.toSpliced(), Array.prototype.toReversed(), Array.prototype.toSorted()에서 예외 후 retval 처리를 수정했습니다.
- RegExp.prototype[@@replace]()를 $', $' 및 유니코드 문자가 있는 문자열을 포함하는 대체로 수정했습니다.
- decodeURI()와 decodeURIComponent()에서 1바이트 오버리드를 수정했습니다.
- 인수 범위 추적이 수정되었습니다.
- Date.parse()의 정수 오버플로우를 수정했습니다.
모든 기능, 변경 사항 및 버그 수정의 전체 목록은 njs 변경 로그를 참조하십시오.
F5 NGINX Plus Release 33(R33)의 출시를 발표하게 되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R33의 새로운 기능 및 향상된 기능은 다음과 같습니다.
NGINX Plus의 라이선싱 변경 사항: NGINX Plus R33부터 모든 고객은 각 상용 NGINX Plus 인스턴스에 JWT(JSON Web Token) 라이선스를 배포해야 합니다. 또한 각 인스턴스는 라이선스 상태를 검증하고 연결된 고객의 경우 F5 라이선스 엔드포인트에 F5 NGINX 사용량을 보고하고, 오프라인/에어 갭 고객의 경우 F5 NGINX Instance Manager에 보고합니다.
포스트 퀀텀 암호화(Post Quantum Cryptography) 지원 : NGINX Plus R33은 NGINX의 포스트 퀀텀 암호화에 대한 지원을 발표하여 장기적인 데이터 전송 보안을 보장하고 기업이 암호화의 향후 변화에 대비할 수 있도록 합니다.
NGINX JavaScript의 QuickJS 런타임 지원: QuickJS는 ES2023 사양을 지원하고, 즉시 가비지 수집을 제공하며, 기존 JavaScript 런타임 엔진보다 성능 향상을 제공하는 가볍고 포함 가능한 JavaScript 엔진입니다. 사용 편의성을 위해 이 런타임은 공존하며 NGINX JavaScript 모듈의 기존 JavaScript 런타임에 대한 드롭인 대체품으로 제공됩니다.
스트림 모듈의 OCSP 스테이플링 지원: NGINX Plus R33은 스트림 모듈에서 OCSP(온라인 인증서 상태 프로토콜) 스테이플링 및 클라이언트 인증서 확인에 대한 지원을 도입했습니다.
릴리스를 마무리하는 것은 NGINX 오픈 소스에서 상속된 새로운 기능과 버그 수정, NGINX JavaScript 모듈에 대한 업데이트입니다.
행동의 중요한 변화
참고: NGINX Plus R32 이외의 릴리스에서 업그레이드하는 경우 현재 버전과 이 버전 사이의 모든 릴리스에 대한 이전 NGINX Plus 릴리스 발표 블로그의 Important Changes in Behavior 섹션을 검토해야 합니다.
NGINX 라이선싱 변경 사항
NGINX Plus R33 릴리스부터 NGINX가 작동하려면 유효한 JWT 라이선스가 필요합니다. 서브스크립션당 단일 JWT 라이선스가 있으며 해당 서브스크립션과 연결된 각 NGINX 인스턴스에 배치해야 합니다.
또한 모든 고객은 상용 NGINX 사용량을 F5에 보고해야 합니다. 기본적으로 사용 보고서는 자동으로 F5 라이선스 엔드포인트로 전송됩니다. 네트워크 제한 환경의 경우 NGINX 인스턴스 관리자를 통해 사용 보고서를 라우팅하는 옵션이 있습니다.
플랫폼 지원 변경 사항
이 릴리스에서 지원되는 플랫폼이 다음과 같이 변경되었습니다.
추가된 플랫폼:
제거된 플랫폼:
더 이상 사용되지 않는 플랫폼:
새로운 기능 세부 정보
NGINX Plus의 라이선스 변경 사항:
NGINX Plus R33 릴리스를 통해 NGINX 상용 제품의 라이선스 부여 방식에 주목할 만한 변경 사항을 도입하고 있습니다. 전제 조건으로, 모든 NGINX 인스턴스에 JWT 라이선스를 배포해야 합니다. 구독당 단일 라이선스가 있으며 해당 구독에 포함된 모든 인스턴스에 설치해야 합니다. 라이선스는 MyF5 계정에서 얻을 수 있습니다. 라이선스를 받고 NGINX 인스턴스에 배포하는 방법에 대한 지침은 여기를 참조하십시오.
NGINX Plus R33 릴리스를 통해 모든 NGINX 고객은 상용 NGINX 사용량도 F5에 보고해야 합니다.
기본적으로 사용량은 F5 라이선싱 엔드포인트에 보고됩니다. 연결 요구 사항에 대해서는 여기의 지침을 참조하십시오.
NGINX 인스턴스에 외부 네트워크 제한이 있는 환경의 경우 NGINX 사용량을 F5로 보내는 연결된 모드와 연결이 끊긴 모드를 모두 제공하는 NGINX 인스턴스 관리자에 사용량을 보고해야 합니다. NGINX 인스턴스를 구성하고 상용 사용 텔레메트리를 NGINX 인스턴스 관리자로 보내는 방법에 대한 지침은 여기를 참조하십시오.
이러한 변경 사항에 대한 전체 개요는 NGINX 라이선스 문서를 참조하십시오.
Post Quantum Cryptography 지원:
양자 컴퓨팅의 발전으로 RSA 및 ECC와 같은 기존 암호화 알고리즘은 잠재적인 양자 컴퓨터 공격에 취약해지고 있습니다. 이를 위해서는 이러한 공격에 저항하는 포스트 양자 암호화(PQC)로의 전환이 필요합니다.
NGINX Plus R33에서 PQC(Post Quantum Cryptography)에 대한 초기 지원을 발표하게 되어 기쁩니다.
NGINX는 OpenSSL 3.x용 Open Quantum Safe 공급자 라이브러리(oqs-provider)를 사용하여 PQC 지원을 제공합니다. 이 라이브러리는 OQS(Open Quantum Safe) 프로젝트에서 사용할 수 있습니다. oqs-provider 라이브러리는 OQS 프로젝트에서 지원하는 모든 포스트 퀀텀 알고리즘에 대한 지원을 OpenSSL-3 의존 애플리케이션의 TLS와 같은 네트워크 프로토콜에 추가합니다. oqs-provider에서 제공하는 모든 암호/알고리즘은 NGINX에서 지원됩니다.
oqs-provider를 사용하여 PQC 지원으로 NGINX를 구성하려면 다음 단계를 수행합니다.
sudo apt install -y build-essential git cmake ninja-build libssl-dev pkg-config
cd liboqs
mkdir build && cd build
cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local -DOQS_DIST_BUILD=ON ..
ninja
sudo ninja install
cd oqs-provider
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl ..
make -j$(nproc)
sudo make install
cd openssl
./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl linux-x86_64
make -j$(nproc)
sudo make install_sw
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect
[default_sect]
activate = 1
[oqsprovider_sect]
activate = 1
# Generate CA key and certificate
/usr/local/ssl/bin/openssl req -x509 -new -newkey dilithium3 -keyout ca.key -out ca.crt -nodes -subj "/CN=Post-Quantum CA" -days 365
# Generate server key and certificate signing request (CSR)
/usr/local/ssl/bin/openssl req -new -newkey dilithium3 -keyout server.key -out server.csr -nodes -subj "/CN=your.domain.com"
# Sign the server certificate with the CA
/usr/local/ssl/bin/openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -days 365
server {
listen 0.0.0.0:443 ssl;
ssl_certificate /path/to/server.crt;
ssl_certificate_key /path/to/server.key;
ssl_protocols TLSv1.3;
ssl_ecdh_curve kyber768;
location / {
return 200 "$ssl_curve $ssl_curves";
}
}
NGINX JavaScript 모듈의 QuickJS 런타임 지원:
NGINX JavaScript는 서버 측 사용 사례 및 요청별 처리를 위해 특별히 설계된 NGINX 및 NGINX Plus를 위한 고유한 JavaScript 구현입니다. 복잡한 구성 솔루션을 구현하기 위해 JavaScript 코드로 NGINX 구성 구문을 확장합니다.
오늘날 NGINX JavaScript 모듈에서 사용되는 JavaScript 런타임 엔진은 전적으로 NGINX 팀에서 개발하고 유지 관리합니다. 기능 개발 및 우선 순위 지정 측면에서 분명한 이점이 있지만 빠르게 발전하는 JavaScript 사양은 따라잡기 어려운 작업입니다. NGINX JavaScript는 현재 ECMAScript 6 이상의 요소와 함께 ECMAScript 5.1을 따릅니다.
사양 문제를 해결하기 위해 NGINX JavaScript 모듈 버전 0.8.6에서 QuickJS 런타임에 대한 미리 보기 지원을 도입하게 되어 기쁩니다. QuickJS는 ES2023 사양을 지원하고, 즉시 사용할 수 있는 가비지 수집을 제공하며, 향상된 성능을 제공하는 가볍고 포함 가능한 JavaScript 엔진입니다. 그리고 두 가지 장점을 모두 제공하기 위해 QuickJS는 NGINX JavaScript 런타임과 공존하며 njs 스크립트에서 드롭인 대체품으로 사용할 수 있습니다. 기존 기능에 대한 전체 지원은 향후 릴리스에서 사용할 수 있습니다.
njs 스크립트에서 QuickJS를 활용하는 방법과 현재 지원되는 함수에 대한 자세한 내용은 설명서를 참조하세요.
스트림 모듈의 OCSP 클라이언트 확인 및 스테이플링 지원:
OCSP(Online Certificate Status Protocol)는 SSL 인증서가 해지되었는지 확인하기 위한 프로토콜입니다. SSL 협상 시간을 줄이기 위해 CRL의 대안으로 만들어졌습니다. CRL(인증서 해지 목록)을 사용하면 브라우저가 해지된 인증서 일련 번호 목록을 다운로드하고 현재 인증서를 확인하므로 SSL 협상 시간이 늘어납니다. OCSP에서 클라이언트 인증서가 제공되면 브라우저는 OCSP URL로 요청을 보내고 인증서의 유효성 상태가 포함된 응답을 받습니다.
현재 NGINX Plus는 http 모듈에서 OCSP 클라이언트 인증서 확인 및 스테이플링을 지원합니다. R33에서는 OCSP 클라이언트 인증서 확인 및 스테이플링 지원을 스트림 모듈에도 제공합니다.
SSL 클라이언트 인증서의 OCSP 유효성 검사를 사용하도록 설정하려면 인증서 확인을 가능하게 하는 ssl_verify_client 지시문(on 또는 선택 사항으로 설정해야 함)과 함께 새 ssl_ocsp 지시문을 포함합니다.
통사론:
(default is off, the leaf parameter enables validation of the client certificate only.)
그러나 OCSP에는 개인 정보 보호와 CA 서버의 과부하라는 두 가지 문제가 있습니다. OCSP는 브라우저가 인증서 유효성을 확인하기 위해 CA에 연결하도록 요구하기 때문에 개인 정보가 손상됩니다. CA는 어떤 웹 사이트가 액세스되고 있으며 누가 액세스했는지 알고 있습니다. 또한 HTTPS 웹 사이트에 많은 방문자가 있는 경우 CA의 OCSP 서버는 방문자의 모든 OCSP 요청을 처리해야 합니다.
여기에서 OCSP 스테이플링이 작동합니다. OCSP 스테이플링은 성능을 개선하고 방문자 개인 정보를 유지하면서 SSL 협상의 성능을 향상시키는 것을 목표로 하는 TLS/SSL 확장입니다. OCSP 스테이플링을 사용하면 인증서 보유자(읽기 웹 서버)가 OCSP 서버를 직접 쿼리하고 응답을 캐시합니다. 이 응답은 인증서 상태 요청 확장 응답을 통해 TLS/SSL 핸드셰이크와 함께 "스테이플"됩니다. 결과적으로 CA의 서버는 요청으로 인한 부담을 갖지 않으며 브라우저는 더 이상 사용자의 브라우징 습관을 제3자에게 공개할 필요가 없습니다.
OCSP 스테이플링을 활성화하려면 ssl_stapling 지시문을 사용합니다.
(default is off)
스트림 컨텍스트에서 OCSP 인증서 확인 및 스테이플링을 위해 이러한 지시문 및 관련 지시문을 사용하는 방법에 대한 자세한 내용은 NGINX 설명서를 참조하십시오.
NGINX Plus R33의 기타 개선 사항 및 버그 수정
HTTP 응답 트레일러 지원
HTTP 응답 트레일러를 사용하면 발신자가 청크 메시지 끝에 추가 필드를 추가할 수 있으며 응답 본문과 함께 처리 상태, 디지털 서명 등과 같은 추가 동적 콘텐츠를 전달하는 데 사용할 수 있습니다. HTTP/1.1로 트레일러를 활성화하는 방법 및 HTTP 트레일러를 사용할 수 없는 사용 사례에 대해서는 여기를 참조하십시오.
현재 트레일러는 grpc_pass 지시문을 사용하는 gRPC 프록시에서만 지원됩니다. 이 개선 사항은 proxy_pass의 트레일러에 대한 지원도 추가합니다. 새로운 지시문 proxy_pass_trailers가 도입되어 프록시된 업스트림에서 클라이언트로 트레일러 필드를 전달할 수 있습니다.
샘플 구성
proxy_http_version 1.1;
proxy_set_header Connection "te";
proxy_set_header TE "trailers";
proxy_pass_trailers on;
proxy_pass ...
}
SSL 키 로깅
이 향상된 기능을 사용하면 파일에 대한 클라이언트 및 업스트림 연결 중에 생성된 SSL 키를 로깅할 수 있습니다. 이는 SSL 트래픽의 암호를 해독하고 SSL 키를 검사하려는 경우 문제를 해결하는 데 유용합니다. 파일은 SSLKEYLOGFILE 형식이며 지시문에 인수로 전달됩니다.
ssl_key_log, proxy_ssl_key_log, grpc_ssl_key_log 및 uwsgi_ssl_key_log 지시문은 SSL 키 로깅을 지원하기 위해 R33 릴리스에 도입되었습니다.
SSL 키를 파일에 로깅하기 위한 샘플 구성:
proxy_key_log /tmp/sslkey.log;
SSL 클라이언트 인증서 확인 개선 사항
NGINX Plus R33 릴리스에서는 ssl_verify_client 지시문을 사용할 때 클라이언트 SSL 인증서 확인에 "ssl_client_certificate" 지시문이 더 이상 필요하지 않습니다. 이 변경은 ssl_client_certificate 지시문에 하나 이상의 신뢰할 수 있는 CA 인증서가 있어야 하는 이전 요구 사항을 완화합니다. 필요한 경우 ssl_trusted_certificate 지시문을 사용하여 모든 신뢰할 수 있는 CA 인증서를 지정할 수도 있습니다.
버그 수정:
NGINX 오픈 소스에서 상속된 변경 사항
NGINX Plus R33은 NGINX 오픈 소스 1.27.2를 기반으로 하며 NGINX Plus R32가 출시된 이후(NGINX 오픈 소스 1.27.0, 1.27.1 및 1.27.2).
기능:
변경:
버그 수정:
안전:
최신 릴리스에서 상속된 새로운 변경 사항, 기능, 버그 수정 및 해결 방법의 전체 목록은 NGINX 변경 사항을 참조하십시오 .
NGINX JavaScript 모듈에 대한 변경 사항
NGINX Plus R33은 NGINX JavaScript(njs) 모듈 버전 0.8.7의 변경 사항을 통합합니다. 다음은 0.8.4 (NGINX Plus R32와 함께 제공되는 버전) 이후 njs의 주목할만한 변경 사항 목록입니다.
기능
변경
버그 수정
모든 기능, 변경 사항 및 버그 수정의 전체 목록은 njs 변경 로그를 참조하십시오.