HSTS (HTTP Strict Transport Security)이란?

# HSTS (HTTP Strict Transport Security)

간단히 기술하자면, Web Site에 접속할 때, 강제적으로 HTTPS Protocol로만 접속하게 하는 기능.

HTTPS Protocol을 지원하는 Web Site에서 자신은 HTTPS Protocol만 사용해서 통신할 수 있음을 접속하고자 하는 Web Browser에게 알려 주는 기능이다. 요약하면, 보안을 강화시킬 목적으로, Web Browser에게 HTTPS Protocol만 사용하도록 강제하는 기능이다.

HSTS 사용하기 위해선 Web Browser에서도 HSTS 기능을 지원해야 제대로 동작한다.
(IE는 11 버전부터, Chrome은 4 버전부터 지원)

HSTS 기능을 사용하려면 Web Server 및 Browser 둘 다 기능을 지원해야 한다고 했는데, 해당 기능을 지원하는 웹 서버를 “HSTS enabled Server” 라고 칭한다.

HSTS 기능은 Web Site의 보안에 관련된 Policy를 설정하는 기능에 속한다. 실제로 사용되고 있으면서도, 사용자들에게는 잘 알려지지 않은 기능.

---

# HSTS 기능을 사용하는 목적

사용자가 특정 Web Site에 접속할 때, 해당 Web Site가 HTTPS Protocol을 지원하는 지, 하지 않는 지 알지 못하는 경우가 대부분이다. 따라서 Web Browser로 접속 시, 주소창에 “https://” 또는 “http://” 와 같은 Protocol 이름을 입력하지 않고, 단지 도메인 이름(예를 들면, www.naver.com)만 입력.

그러면, Web Browser는 먼저 HTTP Protocol(“http://” 사용)로 해당 도메인에 접속을 시도.

해당 도메인이 HTTPS Protocol만을 지원하는 Web Site라면, ”301 Redirect” 또는 ”302 Redirect” response를 보내어, Web Browser로 하여금 HTTPS Protocol로 다시 접속하라고 지시.

사용자는 접속한 후에, 주소창 옆에 있는 자물쇠 아이콘 또는 접속된 URL주소 앞에 있는 “https://”를 보고, 해당 Web Site가 지원하는 Protocol이 HTTPS Protocol 인지 인식.

만약 해커와 같은 공격자가, 중간자공격(MITM attack)을 하여, 중간에 Proxy Server를 두고, 사용자와는 HTTP 통신을 하고, 실제 Site 와는 HTTPS 통신을 해도, 사용자는 전혀 인식을 하지 못함.

즉 사용자가 실제 Site 와 주고 받는 모든 정보는 공격자에게 노출이 되며, 이러한 공격을 “SSL Stripping” 공격(attack)이라고 부르며, 이러한 공격을 방지하기 위하여 HSTS 기능을 사용한다. SSL Stripping은 SSL/TLS Hijacking이라고도 부름.

즉 사용자가 실수로 HTTPS Protocol을 지원하는 Site를, HTTP Protocol로 접속 했을 때, 중간자 공격에 의해, HTTP Protocol을 사용한 통신을 하게 되고, 이로 인해 통신 정보가 공격자에게 노출이 되는 것을 방지하고자 하는 목적으로 사용된다. 또한 cookie hijacking을 방지하는 용도로도 사용됨.

---

# HSTS 기능의 동작

HSTS를 지원하는 Web Browser는 내부에 HSTS List를 보유하고 있다. 즉 HTTPS Protocol을 사용해야만 하는 Web Site에 대한 정보를 가지고 있음.

사용자가 Web Browser 주소창에 도메인 이름을 입력하면(또는 실수로 “http://” 를 사용하여 URL 주소를 입력하면), 또는 Link된 URL 주소를 클릭하면, 도메인 주소만 추출하여, HSTS List에 있는 지, 확인하여 있다면,(도메인 이름에 HSTS가 설정되어 있으면), HTTPS Protocol을 사용하여 접속하게 된다.

Web Browser가, HSTS 기능이 설정된 Site에 HTTPS Protocol로 접속할 경우, Web Browser가 이전에 접속한 적인 없는, HTTPS Protocol 지원 Site에 HTTP Protocol로 접속하면, 앞에서 언급 했듯이 “301 Redirect” Reply Message로 인해, 다시 HTTPS Protocol로 접속하게 된다. Web Server는 HTTPS Reply Message에 HSTS Policy를 넣어서 보낸다. (암호화 되기 전 packet인, HTTP response header field에 "Strict-Transport-Security" 필드 정보 삽입)

Web Browser는 이 정보를 받아서 내부 HSTS List를 구성. 참고로, Max Age 값, Subdomain 적용여부 값, Preloaded List에 추가여부 값을 함께 전달. Max Age 값은 HSTS List 에 존속하는 시간을 나타내며, Subdomain에도 HSTS를 적용할 지 여부를 알려준다. (Age 값이 0(zero)인 경우는 HSTS Policy를 삭제하라는 명령이라고 함)

만약, Web Browser가 HTTP Protocol로 Web Server에 접속하고, HTTP Reply Message에 HSTS Policy 정보가 들어 있는 경우는, 무시된다고 함.

참고로, HSTS response header의 Syntax 는 아래와 같습니다.

Strict-Transport-Security: max-age=<expire-time>

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

Strict-Transport-Security: max-age=<expire-time>; preload

---

# Preloaded HSTS Lists

이미 만들어져 있는 HSTS Lists를 Web Browser에 제공하는 기능도 지원하고 있는데, 이러한 HSTS Lists를 “Preloaded HSTS Lists” 라고 함. Preloaded HSTS Lists는, Web Browser 설치 시 또는 Update 시에 Web Browser Vendor에 의해 제공된다. (참고로 MS사는 분기별로 Update)

Preloaded HSTS Lists를 사용하는 목적은 만약 없다면, Web Browser가 HTTPS Protocol을 지원하는 Web Site를, HTTP Protocol을 사용하여, 처음으로 접속 하였을 때, SSL Stripping 공격을 받을 가능성이 있기 때문에 이것을 방지하기 위한 목적이다.

Web Site 소유자가 자신의 Site를 “Preloaded HSTS Lists” 에 포함되도록 하려면 “hstspreload.org” Site에 신청을 해야 한다. 요구하는 기능을 충족한 다음에, 양식에 맞추어 신청을 하면 된다. 자신의 Site가 “Preloaded HSTS Lists”에 포함되어 있는지 확인하는 것도 “hstspreload.org” Site에서 할 수 있다.

또한 Web Browser 사용자가 직접 자신의 Web browser에서 특정 Web Site를 HSTS List에 추가할 수 있도록 기능을 제공하는 Web Browser도 있다. (Chrome Browser인 경우는, 주소창에 “chrome://net-internals/#hsts” 입력하여 설정할 수 있다. 물론 설정된 값을 확인 및 삭제 하는 기능도 존재함.)

HTTP만 지원하는 Web Site를 HSTS List에 추가 하였거나, 공격자에 의해 HTTP Protocol을 지원하는 Site로 Redirect 된 경우는 “Your connection is not private” 와 같은 의미를 가진 경고 메시지가 나타나며 Web Site에는 접속하지 못함. 참고로 DNS Spoofing에 의한 Redirection은 IP 주소 자체가 변경된 것이므로 여기에 해당되지 않는다.

“HSTS Lists” 와 “Preloaded HSTS List” 가 각각 존재하는 것이 아니고, 개념상 미리 만들어져 있는 "HSTS Lists"를 "Preloaded HSTS Lists"라고 부르는 것.

---

# 배포 권장사항(몰라도 되는 팁)

사이트의 모든 하위 도메인을 검사하고 HTTPS를 통해 제대로 작동하는지 확인.
HSTS를 모든 HTTPS 응답에 헤더를 추가하고 max-age 헤더값을 단계적으로 증가.
더 이상 문제가 없다고 확신되면 max-age를 2년을 늘리고 preload옵션을 추가.

# HSTS 옵션

max-age : 브라우저가 HSTS 정책을 적용할 기간(초)를 설정
includeSubdomains : 도메인(example.com)의 서브 도메인(api.example.com 등에도 HSTS 설정을 적용
preload : 해당 도메인이 블우저의 preload list에 추가되며 브라우저에서는 HSTS 헤더가 없더라도 HTTP 요청을 HTTPS로 강제 변환하여 전송

추가적으로 설정 방법은 구글링 권고

---

# HSTS 장점
HTTPS 프로토콜을 강제하는 방법으로는 HSTS 대신, HTTP 요청을 HTTPS로 리다이렉트하는 방법도 있을 것이다.
,,, 그래서 HSTS의 장점은?

HSTS를 사용하면 클라이언트는 HTTP 프로토콜을 통한 통신을 아예 시도하지 않는다. 이는 중요한 보안 장점으로, 클라이언트는 처음부터 HTTPS로 요청을 보내기 때문에 중간자 공격을 미연에 방지할 수 있다.

아래는 HTTPS를 강제하는 두 가지 방법을 비교하여 설명한 것이다.

1. Redirect를 통한 HTTPS 강제

1. 클라이언트가 먼저 HTTP로 접속을 시도. 중간자가 암호화되지 않은 패킷을 가로채고, 서버와 통신.
2. 서버는 클라이언트의 HTTP 요청을 받으면 HTTPS로 리다이렉트 요청을 보낸다.
3. 중간자는 클라이언트에게 HTTP로 응답을 보내며, 클라이언트는 이후 계속적으로 HTTP 요청을 보낸다.
4. 중간자는 클라이언트의 HTTP 요청을 HTTPS로 변경하여 서버에 요청을 보낸다.
5. 이 과정에서 중간자는 SSL Stripping 공격에 노출될 수 있다.

 

2. HSTS를 통한 HTTPS 강제

1. 클라이언트가 처음에 HTTP로 접속을 시도. 브라우저는 HSTS가 설정된 도메인임을 인식하고, HTTP 요청을 보내지 않는다.
2. 브라우저는 대신 HTTPS로 서버에 요청.
3. 중간자는 SSL로 암호화된 패킷을 도청할 수 없다.
4. 서버는 HTTPS 요청에 대한 응답을 보낸다.

HSTS를 사용하면 클라이언트는 HTTP 통신을 시도하지 않으므로 보안적인 측면에서 더 안전하다.
또한, HSTS는 IETF 표준이기도 하여 신뢰성이 높다.