NGINX 웹 서버에서 SSL Perfect Forward Secrecy 구현

이 페이지에서

더 나아가기: 장기간 HTTP Strict Transport Security(HSTS) 구현\n
축하합니다!\n
참조:

이 HOW-TO는 Debian 및 Ubuntu 시스템에서 NGINX 웹 서버로 Perfect Forward Secrecy를 구현하는 과정을 설명합니다. 이 프로세스는 다른 GNU/Linux 시스템에 쉽게 적용할 수 있습니다.

요컨대, Perfect Forward Secrecy는 다음을 보장합니다. "... 한 메시지의 손상이 다른 메시지의 손상으로 이어질 수 없으며 또한 여러 메시지의 손상으로 이어질 수 있는 단일 비밀 값이 없습니다." 자세한 내용은 http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy를 참조하세요.

OpenSSL의 Heartbleed 취약점이 2014년 초에 공개되었을 때 PFS가 SSL/TLS를 심각한 용량으로 사용하는 모든 시스템에 필수라는 것이 점점 더 분명해졌습니다.

내 결과와 결과를 비교하고 싶다면 https://indietorrent.org에서 내 참조 구현을 테스트할 수 있습니다.

더 이상 고민하지 않고 PFS를 구현하도록 NGINX를 구성하겠습니다.

NGINXs 구성 디렉토리로 이동할 수 있습니다.

cd /etc/nginx/

충분히 강력한 Diffie-Hellman 매개변수를 생성해야 합니다. 일부에서는 4096비트가 과도하고 시스템 CPU에 과도한 부담을 줄 것이라고 주장하지만 최신 컴퓨팅 성능을 사용하면 이는 가치 있는 절충안으로 보입니다. 자세한 내용은 아래 참조 섹션을 참조하십시오.

openssl dhparam -out dh4096.pem 4096

당면한 작업에 특정한 이 구성 파일을 포함 파일로 분류하면 편리합니다. 이렇게 하면 많은 시스템에서 PFS를 구현하는 것이 더 간단해집니다.

vi /etc/nginx/perfect-forward-secrecy.conf

위 파일에 다음을 붙여넣습니다.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;

NGINX의 기본 구성 파일(기본적으로 /etc/nginx/nginx.conf)에 다음 줄을 삽입하여 위 파일을 포함하도록 NGINX 구성을 수정합니다. http {} 블록:

# See: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# This MUST come AFTER the lines that includes .../sites-enabled/*, otherwise SSLv3 support may be re-enabled accidentally.
include perfect-forward-secrecy.conf;

변경 사항을 적용하려면 NGINX를 다시 시작하십시오.

service nginx restart

https://www.ssllabs.com/ssltest/analyze.html의 테스트에서 세션 재개(캐싱) 아니요(ID가 할당되었지만 허용되지 않음)가 빨간색으로 표시되고 서버가 SNI를 구현하는 경우 최상위 수준에 다음을 추가합니다. http {} 블록(즉, 이전에 추가한 위치 바로 아래 nginx.conf에 추가):

# See: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

다시 NGINX를 다시 시작하여 변경 사항을 적용합니다.

service nginx restart

위 테스트는 더 이상 이 문제를 보고하지 않아야 합니다(문제가 전체 테스트 점수를 줄이지 않더라도).

더 나아가기: 장기간 HTTP Strict Transport Security(HSTS) 구현

이는 다음과 같은 경우 쉽고 수행할 가치가 있는 작업입니다.

이 헤더가 설정된 모든 호스트(즉, 해당 웹사이트의 모든 페이지)의 모든 리소스에 대해 SSL을 강제하려고 합니다.\n
"도메인 이름 불일치" 등과 같이 이 헤더가 설정된 모든 호스트에서 요청된 모든 리소스에 대한 SSL 경고를 수락하거나 무시할 수 있는 기능이 없는 상태로 살 수 있습니다. HSTS의 본질은 다음과 같습니다. SSL 인증서와 관련된 경고 및 오류 조건은 무시할 수 없습니다.\n

이 헤더를 설정하면 헤더를 지원하지 않는 브라우저에서 의도하지 않은 결과가 발생할 수 있는지 여부에 대한 정보를 얻기 위해 인터넷을 샅샅이 뒤졌습니다. 그러나 예를 들어 Internet Explorer 6에서 이 구현을 테스트하고 HSTS가 구현되지 않은 브라우저는 단순히 헤더를 무시함으로써 내 우려를 완화할 수 있었습니다. 완벽한!

/etc/nginx/perfect-forward-secrecy.conf 하단에 다음 줄을 추가하고 변경 사항을 저장하기만 하면 됩니다.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# This will prevent certain click-jacking attacks, but will prevent
# other sites from framing your site, so delete or modify as necessary!
add_header X-Frame-Options SAMEORIGIN;

다시 시작하는 대신 다시 로드하면 NGINX가 이러한 특정 변경 사항을 선택하도록 할 수 있습니다.

service nginx reload

https://www.ssllabs.com/ssltest/analyze.html에서 구현을 테스트하여 HSTS가 의도한 대로 작동하는지 확인할 수 있습니다. HSTS가 올바르게 구현된 경우 점수 바로 아래에 "이 서버는 장기 HTTP Strict Transport Security를 지원합니다. 등급이 A+로 설정되었습니다."라는 녹색 상자가 표시됩니다.

축하합니다!

이제 인터넷에서 가장 안전한 SSL/TLS 구현 중 하나를 갖게 되었습니다.

참조:

https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy