nginx가 HSTS를 구성하는 방법

Netcraft는 최근 SSL/TLS 웹사이트 테스트에 대한 연구 결과를 발표했으며 사용자 중 5%만이 HTTP Strict Transport Security HSTS를 올바르게 구현했다고 밝혔습니다.

HSTS란 무엇입니까

HTTPS(SSL 및 TLS)는 사용자와 웹사이트 간의 통신 보안을 보장하여 공격자가 가로채거나 수정하고 가장하는 것을 어렵게 만듭니다. 사용자가 도메인 이름이나 http:// 링크를 수동으로 입력하면 웹 사이트에 대한 첫 번째 요청은 일반 http를 사용하여 암호화되지 않습니다. 가장 안전한 웹사이트는 사용자를 https 연결로 안내하는 리디렉션을 즉시 다시 보냅니다. 그러나 중간자 공격자가 초기 http 요청을 가로채서 사용자의 후속 응답을 제어할 수 있습니다.

당연히 이러한 잠재적인 보안 문제를 해결하기 위해 HSTS가 탄생했습니다. 사용자가 도메인 이름이나 http 연결을 입력하더라도 브라우저는 엄격하게 https 연결로 업그레이드됩니다.

HSTS 작동 방식

HSTS 정책은 보안 HTTPS 사이트에서 전송된 HTTP 응답 헤더에서 발행됩니다.

Strict-Transport-Security: max-age=31536000

브라우저가 HTTPS 사이트에서 이 헤더를 보면 해당 도메인 이름은 HTTPS(SSL 또는 TLS)를 통해서만 액세스할 수 있다는 것을 알게 됩니다. 그리고 이 정보를 1년인 31536000에 캐시합니다.

선택적인 includeSubDomains 매개변수는 이 정책이 현재 도메인 아래의 모든 하위 도메인에 적용된다는 것을 브라우저에 알려줍니다.

Strict-Transport-Security: max-age=31536000; includeSubDomains

nginx는 HSTS를 구성합니다

nginx 구성 파일에 HSTS 응답 헤더를 설정합니다.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

always 매개변수는 내부에서 생성된 오류 응답을 포함하여 모든 응답에 이 헤더가 설정되도록 보장합니다. 1.7.5 이전의 nginx 버전은 Always 매개변수를 지원하지 않으며 내부적으로 생성된 오류 응답은 이 헤더 정보를 설정하지 않습니다.

add_header 지시문 상속 규칙:

nginx 구성 블록은 add_header 지시문이 있는 캡슐화 블록을 상속하므로 최상위 서버 블록에 add_header 지시문만 배치하면 됩니다. 또한 중요한 예외가 있습니다. 블록에 add_header 지시어 자체가 포함되어 있으면 포함하는 블록에서 헤더를 상속하지 않으므로 모든 add_header 지시어를 다시 정의해야 합니다.

server {
    listen 443 ssl;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
 
    # This 'location' block inherits the STS header
    location / {
        root /usr/share/nginx/html;
    }
 
    # Because this 'location' block contains another 'add_header' directive,
    # we must redeclare the STS header
    location /servlet {
        add_header X-Served-By "My Servlet Handler";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        proxy_pass http://localhost:8080;
    }
}

HTTP 엄격한 전송 보안 테스트:

사용자가 HSTS 정책을 제안하면 해당 캐시 정보 기간은 max-age로 지정됩니다. 이 시간 동안 브라우저는 암호화되지 않은 HTTP를 통한 웹 서비스에 대한 액세스를 거부하고 인증서 오류에 대한 예외 제공을 거부합니다(웹 사이트가 이전에 유효하고 신뢰할 수 있는 인증서를 제출한 경우). includeSubDomanis 매개변수가 지정된 경우 이러한 제한사항은 현재 도메인 아래의 모든 하위 도메인에도 적용됩니다.

HSTS를 테스트할 때 max-age 시간을 더 짧게 설정하세요.

모든 HTTPS 응답에 STS 헤더가 필요한지 여부:

우리의 목표는 사용자가 HTTPS 응답을 시작할 때 가능한 한 빨리 HSTS 정책을 렌더링하는 것입니다. 세션 중에 HSTS 정책을 수신하더라도 여전히 HTTP 하이재킹 공격에 취약합니다. 브라우저는 STS 헤더를 한 번만 보면 되므로 모든 위치 블록과 모든 응답에 STS 헤더를 추가할 필요는 없습니다. 하지만 단순히 홈페이지나 로그인 페이지에 추가하는 것만으로는 충분하지 않을 수 있으며, 캐시된 응답에만 추가하면 클라이언트가 보지 못할 수도 있습니다. 동적 콘텐츠에 특히 주의하면서 URL을 최대한 많이 포함하도록 하세요.

HTTP와 HTTPS를 병렬로

웹사이트를 HTTP와 HTTPS 모두에서 실행해야 하는 경우도 있습니다.

server {
    listen  80;
    listen  443 ssl;
    ...
}

때때로 http 요청을 https

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
 
    # Discourage deep links by using a permanent redirect to home page of HTTPS site
    return 301 https://$host;
 
    # Alternatively, redirect all HTTP links to the matching HTTPS page
    # return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl;
    server_name www.ttlsa.com;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

로 리디렉션해야 하는 경우도 있습니다. HSTS를 강화

HTTP 가로채기로부터 클라이언트를 보호하세요. from 선언된 max-age까지 STS 헤더를 봅니다. 그러나 HSTS는 HTTP 세션 하이재킹에 대한 완벽한 솔루션은 아닙니다. HTTP를 통해 HSTS로 보호되는 웹사이트에 액세스하는 경우 사용자는 여전히 취약합니다.

1. 이전에 해당 웹사이트를 방문한 적이 없습니다.

2. 최근에 운영 체제를 다시 설치했습니다.

3. 최근에 브라우저를 다시 설치했습니다.

4. 새 버전으로 전환하세요. browser

5. 휴대폰 등 새로운 기기로 전환

6. 브라우저 캐시 삭제

7. 최근 사이트를 방문하지 않았으며 최대 사용 기간이 만료되었습니다

이 문제를 해결하려면 Google은 "HSTS 사전 로드 목록" 사이트 도메인 이름과 하위 도메인 이름을 유지해야 한다고 주장하며 https://hstspreload.appspot.com/을 통해 도메인 이름을 제출합니다. 이 도메인 이름 목록은 주요 웹 브라우저에 배포되고 하드 코딩됩니다. 이 목록의 도메인 이름에 액세스하는 클라이언트는 HTTPS를 적극적으로 사용하고 HTTP를 사용하는 사이트에 대한 액세스를 거부합니다.

STS 헤더가 설정되거나 도메인이 HSTS 사전 로드 목록에 제출되면 이를 제거할 수 없습니다. 이는 HTTPS를 통해 도메인 이름을 사용할 수 있도록 하는 단방향 결정입니다.

위 내용은 nginx가 HSTS를 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!