맨위로가기

HTTP 스트릭트 트랜스포트 시큐리티

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

HTTP Strict Transport Security (HSTS)는 웹 사이트가 HTTPS 연결만 사용하도록 브라우저에 지시하는 웹 보안 정책이다. 2012년 RFC 6797로 게시되었으며, 중간자 공격으로부터 사용자를 보호하는 데 도움을 준다. HSTS는 서버가 HTTPS 연결을 통해 헤더를 제공하여 구현되며, 웹 브라우저는 HSTS 정책에 따라 보안되지 않은 링크를 자동으로 보안 링크로 변경하고, TLS 인증서가 신뢰되지 않는 경우 연결을 종료한다. HSTS는 TLS의 안전성이 위협받거나, 초기 요청이 안전하지 않은 채널을 통해 이루어진 경우, 또는 HSTS preload list에 없는 사이트의 경우 등 몇 가지 한계가 있다. 주요 브라우저들은 HSTS를 지원하며, HSTS preload list를 통해 이러한 한계를 일부 해결하고 있다.

더 읽어볼만한 페이지

  • 컴퓨터 보안 표준 - ISO/IEC 27002
    ISO/IEC 27002는 조직이 정보 보안을 효과적으로 관리하도록 지침을 제공하는 정보 보안 표준으로, 정보 보안 정책, 조직 구조, 물리적 보안 등 다양한 영역을 다룬다.
  • 컴퓨터 보안 표준 - 콘텐츠 보안 정책
    콘텐츠 보안 정책(CSP)은 웹 사이트의 XSS 공격과 데이터 주입 공격을 완화하기 위해 웹 서버 응답 헤더에 선언적 허용 목록 정책을 적용하여 인라인 JavaScript, CSS, 동적 코드 평가 등을 비활성화하는 웹 브라우저 보안 기능이다.
  • 전송 계층 보안 - 공개 키 기반 구조
    공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다.
  • 전송 계층 보안 - HTTPS
    HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
  • 암호학 - 양자 컴퓨터
    양자 컴퓨터는 양자역학적 현상을 이용하여 정보를 처리하는 컴퓨터로, 큐비트를 통해 0과 1을 동시에 표현하여 특정 연산에서 기존 컴퓨터보다 빠른 속도를 보이며 암호 해독, 신약 개발 등 다양한 분야에 혁신을 가져올 것으로 기대된다.
  • 암호학 - 암호화
    암호화는 정보를 보호하기 위해 사용되는 기술로서, 단순한 문자 치환 방식에서 시작하여 현대에는 강력한 암호화 표준과 다양한 종류로 발전했으며, IT 시스템 전반에 적용되지만, 사이버 공격과 양자 컴퓨팅의 발전에 대한 대응이 필요한 기술이다.
HTTP 스트릭트 트랜스포트 시큐리티
개요
이름HTTP Strict Transport Security (HSTS)
목적웹사이트 보안 강화 메커니즘
설명웹 브라우저가 HTTPS 연결만 사용하도록 강제하여 중간자 공격과 같은 보안 위협을 줄이는 기술
기술 상세
작동 방식서버가 HTTP 응답 헤더를 통해 HSTS 정책을 브라우저에 전달
브라우저는 해당 정책을 준수하여 지정된 기간 동안 해당 도메인에 대한 모든 연결을 HTTPS로만 시도
HTTP 응답 헤더Strict-Transport-Security
구성 요소max-age: HSTS 정책이 유효한 기간 (초 단위)
includeSubDomains: 모든 하위 도메인에도 HSTS 정책을 적용할지 여부 (선택 사항)
preload: 브라우저 제조사에 HSTS 정책을 미리 로드하도록 요청 (선택 사항)
예시Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age31536000 (1년)
includeSubDomains하위 도메인 포함
preloadpreload 사용
보안 효과
SSL 스트리핑 공격 방지공격자가 HTTPS 연결을 HTTP로 다운그레이드하여 정보를 가로채는 것을 방지
쿠키 하이재킹 방지HTTPS를 통해서만 쿠키를 전송하도록 하여 쿠키 탈취 위험을 줄임
구현 고려 사항
초기 설정웹 서버에 HSTS 헤더를 추가하고, 적절한 max-age 값을 설정
Preload List 등록브라우저에 HSTS 정책을 미리 로드하도록 HSTS preload list에 등록 권장
주의 사항HSTS 정책을 활성화하기 전에 HTTPS가 정상적으로 작동하는지 확인
max-age 값을 너무 높게 설정하면 되돌리기 어려우므로 신중하게 결정
표준
RFCRFC 6797

2. 역사

HSTS 규격은 Collin Jackson과 Adam Barth가 "ForceHTTPS: Protecting High-Security Web Sites from Network Attacks"라는 논문에서 설명한 작업을 기반으로 한다.[6] 또한, Jeff Hodges와 Andy Steingruebl이 2010년 논문 ''The Need for Coherent Web Security Policy Framework(s)''에서 제시한 웹 보안 개선 비전의 일부를 실현한 것이기도 하다.[7]

최초의 초안 규격은 페이팔(PayPal) 소속이었던 Jeff Hodges, Collin Jackson, Adam Barth가 작성하여 2009년 9월 18일에 게시되었다.[5] 당시 "STS"(Strict Transport Security)로 명명되었던 이 규격은 커뮤니티의 피드백을 반영하여 개정되었고, 2009년 12월 18일에 새로운 버전이 게시되었다.[4]

2010년 6월 17일, 저자들은 이를 인터넷 드래프트로 제출하면서 규격 이름을 "Strict Transport Security"(STS)에서 "HTTP Strict Transport Security"(HSTS)로 변경했다. 이는 해당 규격이 HTTP 프로토콜에만 적용된다는 점을 명확히 하기 위함이었다.[3] 하지만 HSTS 규격에 정의된 HTTP 응답 헤더 필드의 이름은 여전히 "Strict-Transport-Security"로 유지되었다.

HSTS 규격은 2012년 10월 2일 IESG에서 제안된 표준 RFC로 발행하도록 승인되었으며, 최종적으로 2012년 11월 19일에 RFC 6797로 게시되었다.[2]

3. 작동 방식

HSTS는 웹 서버가 웹 브라우저에게 특정 기간 동안 오직 HTTPS만을 사용하여 접속해야 한다고 알리는 웹 보안 메커니즘이다. 서버는 HTTPS 응답 헤더에 `Strict-Transport-Security` 정보를 포함시켜 HSTS 정책을 전달하며, HTTP를 통한 HSTS 헤더는 무시된다.[1]

이 정책을 수신한 브라우저는 이후 해당 웹사이트에 접속할 때, 사용자가 HTTP 주소를 입력하더라도 자동으로 HTTPS로 요청을 변경한다. 또한, 서버의 TLS 인증서가 유효하지 않거나 연결 보안을 보장할 수 없는 경우에는 사용자에게 경고하고 연결을 차단하여 보안을 강화한다.

HSTS는 사용자가 HTTP로 접속 시도 시 발생할 수 있는 중간자 공격, 특히 HTTPS 연결을 HTTP로 다운그레이드하는 SSL 스트리핑(SSL Stripping) 공격을 효과적으로 방지하는 데 도움을 준다.

3. 1. HSTS 메커니즘 개요

서버는 HTTPS 연결을 통해 `Strict-Transport-Security` 헤더를 제공하여 HSTS 정책을 구현한다. HTTP를 통한 HSTS 헤더는 무시된다.[1] 예를 들어, 서버는 향후 1년 동안 해당 도메인에 대한 요청이 HTTPS만을 사용하도록 다음과 같은 헤더를 보낼 수 있다 (`max-age`는 초 단위로 지정되며, 31,536,000은 윤년이 아닌 1년과 같다):

`Strict-Transport-Security: max-age=31536000`

웹 애플리케이션이 사용자 에이전트(웹 브라우저)에 HSTS 정책을 발행하면, 적합한 사용자 에이전트는 다음과 같이 동작한다:

# 웹 애플리케이션을 참조하는 모든 보안되지 않은 링크를 자동으로 보안 링크로 변경한다 (예: `http://example.com/some/page/`는 서버에 액세스하기 전에 `https://example.com/some/page/`로 수정된다).

# 연결의 보안을 보장할 수 없는 경우(예: 서버의 TLS 인증서가 신뢰되지 않는 경우), 사용자 에이전트는 연결을 종료해야 하며 사용자에게 웹 애플리케이션에 액세스하도록 허용해서는 안 된다.

HSTS 정책은 웹 애플리케이션 사용자를 일부 수동적 (도청) 및 능동적 네트워크 공격으로부터 보호하는 데 도움이 된다. 사용자의 브라우저가 해당 웹 애플리케이션에 대해 HSTS 정책을 적용받는 동안, 중간자 공격자는 사용자와 웹 애플리케이션 서버 간의 요청 및 응답을 가로채는 능력이 크게 감소한다.

웹 서버가 웹 브라우저에 대해 보안 HTTPS만으로 서비스를 제공하고 싶은 경우, 사용자 편의성 측면에서 HTTP로 접속했을 때 HTTPS의 URI로 리다이렉트하는 경우가 있다. 이 경우 웹 서버의 응답에 리다이렉트 지시를 포함시키지만, HTTP는 변조 감지 기능을 갖지 않기 때문에 공격자가 이를 악의적인 사이트로 리다이렉트하는 지시로 변경하거나, HTTPS의 내용을 HTTP로 중계(SSL Stripping)하더라도 웹 브라우저는 이를 알 수 없어 중간자 공격을 허용하게 된다.

HSTS에서는 사용자가 웹 브라우저에 스킴이 http인 URI를 입력하는 등 HTTP로 접속하려고 할 때, 미리 웹 서버가 HSTS를 활성화하도록 지시한 도메인인 경우, 웹 브라우저가 강제로 HTTPS로 접속을 변경하여 접근함으로써 이 문제를 해결한다.

3. 2. HSTS 정책

서버는 HTTPS 연결을 통해 `Strict-Transport-Security` 헤더를 전달하여 HSTS 정책을 구현한다. HTTP를 통한 HSTS 헤더는 무시된다.[1] 예를 들어, 서버는 앞으로 1년 동안 해당 도메인에 대한 요청이 HTTPS만을 사용하도록 다음과 같은 헤더를 보낼 수 있다 (max-age는 초 단위로 지정되며, 31,536,000은 윤년이 아닌 1년과 같다):

Strict-Transport-Security: max-age=31536000

웹 애플리케이션이 사용자 에이전트(예: 웹 브라우저)에 HSTS 정책을 전달하면, 해당 사용자 에이전트는 다음과 같이 동작한다:

  • 웹 애플리케이션을 가리키는 모든 안전하지 않은 링크를 자동으로 안전한 링크로 변경한다. 예를 들어, http://example.com/some/page/는 서버에 접속하기 전에 https://example.com/some/page/로 수정된다.
  • 연결 보안을 보장할 수 없는 경우(예: 서버의 TLS 인증서를 신뢰할 수 없는 경우), 사용자 에이전트는 연결을 종료해야 하며 사용자가 해당 웹 애플리케이션에 접근하는 것을 허용해서는 안 된다.


HSTS 정책은 웹 애플리케이션 사용자를 도청과 같은 수동적 공격 및 능동적인 네트워크 공격으로부터 보호하는 데 도움을 준다. 사용자의 브라우저가 특정 웹 애플리케이션에 대해 HSTS 정책을 적용하는 동안, 중간자 공격자가 사용자와 웹 서버 사이의 요청과 응답을 가로채는 것이 훨씬 어려워진다.

웹 서버가 사용자에게 안전한 HTTPS 연결만을 제공하고자 할 때, 편의를 위해 HTTP로 접속한 사용자를 HTTPS URI로 리다이렉트하는 경우가 많다. 하지만 이 초기 HTTP 응답은 암호화되지 않아 공격자가 중간에서 응답을 조작하여 악의적인 사이트로 리다이렉트하거나, HTTPS 통신을 HTTP로 변조하여 중계하는 SSL 스트리핑 공격(일종의 중간자 공격)을 수행할 수 있다. 웹 브라우저는 이러한 공격을 감지하기 어렵다.

HSTS는 이러한 문제를 해결하기 위해, 사용자가 HTTP URI를 입력하는 등 HTTP로 접속을 시도할 때, 해당 도메인이 이전에 HSTS를 사용하도록 설정되었다면 웹 브라우저가 강제로 HTTPS로 연결을 변경하도록 한다.

4. 보안

HSTS는 웹 보안을 강화하는 중요한 기술이지만, 모든 종류의 공격을 막을 수 있는 것은 아니다. HSTS가 주로 해결하는 보안 위협은 중간자 공격의 일종인 SSL 스트리핑(SSL stripping)이다.[8][9] SSL 스트리핑은 사용자의 안전한 HTTPS 연결을 공격자가 중간에서 가로채어 암호화되지 않은 HTTP 연결로 몰래 바꾸는 공격 기법이다. 사용자는 연결이 안전하지 않다는 사실을 알아채기 어려울 수 있다. HSTS는 웹사이트가 브라우저에게 항상 HTTPS만을 사용하여 통신하도록 강제함으로써 이러한 유형의 공격을 효과적으로 방어한다.

또한 HSTS는 Firesheep과 같이 공개된 도구를 이용해 쿠키 정보를 탈취하여 로그인 계정을 도용하는 공격을 방지하는 데도 도움을 줄 수 있다.[12]

하지만 HSTS에도 몇 가지 근본적인 한계점이 존재한다.


  • 최초 연결 시의 취약점: 사용자가 HSTS를 사용하는 웹사이트에 처음 방문하는 경우, 브라우저는 아직 해당 사이트가 HSTS를 요구하는지 알지 못한다. 이 첫 연결 시점에 공격자가 개입하면 HSTS 정책을 무력화시킬 수 있다.[28] 구글 크롬, 파이어폭스, 인터넷 익스플로러, 마이크로소프트 엣지 등의 브라우저는 HSTS 사이트 목록을 미리 내장하는 '프리로드 리스트(preload list)' 방식으로 이 문제를 일부 완화하려 하지만, 모든 웹사이트를 포함할 수는 없는 한계가 있다.[10][11][15]
  • 시간 기반 공격: HSTS 정책은 특정 유효 기간(max-age) 동안만 유효하다. 만약 공격자가 사용자의 시스템 시간을 NTP 공격 등을 통해 미래로 조작할 수 있다면, 브라우저는 HSTS 정책이 만료되었다고 판단하여 HTTPS 강제 연결을 하지 않을 수 있다.[13]
  • TLS 자체의 취약점: HSTS는 기본적으로 HTTPS 연결, 즉 TLS 통신 자체가 안전하다고 가정한다. 따라서 만약 TLS 프로토콜 자체에 심각한 보안 취약점이 발견된다면, HSTS만으로는 이를 막을 수 없다.[27]

4. 1. HSTS가 해결하는 문제

HSTS가 해결하는 가장 중요한 보안 문제는 중간자 공격의 일종인 SSL 스트리핑(SSL stripping)이다. 이는 2009년 블랙햇 페더럴(Black Hat Federal) 강연에서 Moxie Marlinspike가 처음 공개한 공격 기법이다.[8][9] SSL 스트리핑 공격은 안전한 HTTPS 연결을 일반 HTTP 연결로 사용자 모르게 바꾸는 방식으로 작동한다. 사용자는 연결이 안전하지 않다는 사실 자체는 확인할 수 있지만, 원래 그 연결이 반드시 안전해야 하는 연결이었는지 판단하기는 어렵다. 당시 많은 웹사이트가 TLS/SSL을 사용하지 않았기 때문에, 사용자는 현재 연결이 HTTP인 것이 공격 때문인지 아니면 원래 웹사이트가 TLS/SSL을 지원하지 않는 것인지 구별할 방법이 없었다. 또한 연결 수준이 낮아지는 과정에서 사용자에게 별다른 경고가 표시되지 않아, 매우 주의 깊은 사용자가 아니라면 공격을 알아채기 어렵다. Moxie Marlinspike가 개발한 sslstrip 도구는 이러한 공격을 자동으로 수행한다.

HSTS는 웹사이트 접속 시 항상 TLS/SSL을 사용해야 한다고 웹 브라우저에 미리 알려줌으로써 이 문제를 해결한다. 웹 브라우저는 HSTS 지시를 받은 사이트에 대해서는 사용자가 HTTP로 접속하려고 해도 강제로 HTTPS로 연결을 변경한다. 예를 들어, 웹 서버가 보안을 위해 HTTP 접속을 HTTPS URI로 리다이렉트하도록 설정했더라도, 이 리다이렉트 과정 자체가 HTTP 통신이므로 중간자 공격에 취약할 수 있다. 공격자는 리다이렉트 지시를 악의적인 사이트로 변경하거나, HTTPS 내용을 HTTP로 중계(SSL 스트리핑)할 수 있다. 하지만 HSTS를 사용하면 브라우저가 처음부터 HTTPS 연결을 시도하므로 이러한 중간자 공격을 막을 수 있다.

다만, 사용자가 HSTS를 지원하는 사이트에 처음 방문할 때는 공격자가 HSTS 헤더 정보를 제거할 수 있는 취약점이 있다. 구글 크롬, 파이어폭스, 인터넷 익스플로러, 마이크로소프트 엣지 같은 브라우저들은 HSTS를 사용하는 사이트 목록을 미리 내장하여 이 문제를 완화하려고 시도한다.[10][11][15] 하지만 이 방식은 인터넷의 모든 웹사이트를 포함하기에는 한계가 있다. (자세한 내용은 한계 참조)

또한 HSTS는 Firesheep과 같이 널리 알려진 도구를 이용한 쿠키 기반 웹사이트 로그인 정보 탈취를 방지하는 데도 도움이 된다.[12]

4. 2. HSTS의 한계

HSTS 정책이 적용되기 전의 최초 연결 시에는 중간자 공격에 취약하다는 한계가 있다. 사용자가 특정 웹사이트에 처음 접속하거나 HSTS 정책의 유효 기간(`max-age`)이 만료된 후 다시 접속할 때, 브라우저는 해당 사이트가 HSTS를 사용하는지 알 수 없으므로 공격자가 HTTPS 연결을 안전하지 않은 HTTP 연결로 바꿔치기할 수 있다.[28] 이는 웹사이트 주소(URI)를 피싱과 같이 신뢰할 수 없는 출처로부터 얻었을 경우에도 마찬가지이다. 이 초기 연결의 취약점 문제는 HSTS 사전 로드 목록(Preload List)을 통해 일부 완화될 수 있다.

또한 HSTS는 시간에 의존적이라는 제약을 갖는다. 공격자가 사용자의 컴퓨터 시간을 조작하는 공격(예를 들어, 가짜 NTP 패킷을 이용하는 방식)에 성공하면, 브라우저는 HSTS 정책이 만료되었다고 잘못 판단하여 HTTPS 강제 연결을 시도하지 않을 수 있다.[13]

4. 2. 1. HSTS Preload List

HSTS는 웹사이트 접속 시 HTTPS 연결을 강제하는 보안 기능이지만, 사용자가 특정 웹사이트에 처음 접속할 때는 해당 사이트가 HSTS를 사용하는지 알 수 없다는 문제가 있다. 이 때문에 첫 연결 시에는 중간자 공격 등에 취약할 수 있다.[28]

이러한 초기 연결의 취약점을 해결하기 위해 주요 웹 브라우저들은 'HSTS 사전 로드 목록(HSTS Preload List)' 기능을 도입했다. 구글 크롬, 모질라 파이어폭스, 인터넷 익스플로러/마이크로소프트 엣지 등은 HSTS를 지원하는 것으로 알려진 웹사이트들의 목록을 미리 가지고 있다.[14][10][11][15] 이 목록은 브라우저 자체에 포함되어 배포되며, 사용자가 목록에 있는 사이트에 처음 접속하더라도 브라우저는 즉시 HTTPS 연결을 시도하게 된다.

하지만 HSTS 사전 로드 목록 방식은 현실적으로 전 세계의 모든 웹사이트를 포함하도록 확장하기는 어렵다는 한계점을 가진다. 이에 대한 잠재적인 대안으로는 DNS 레코드를 이용해 HSTS 정책을 선언하고, DNSSEC를 통해 이 정보를 안전하게 확인하는 방법이 제안되고 있다.[16]

HSTS 사전 로드 목록에도 불구하고 몇 가지 한계점이 존재한다.

  • 가짜 도메인 공격: 주나데 알리(Junade Ali)는 HSTS가 가짜 도메인을 이용한 공격에는 효과가 없음을 지적했다. 예를 들어, DNS 스푸핑 공격[18]이나 실제 도메인과 매우 유사하게 만든 도메인(예: `www.example.com` 대신 `www.example.org`)을 사용하는 경우, 사전 로드 목록에 없는 도메인을 통해 중간자 공격이 이루어질 수 있다.[17]
  • TLS 자체의 취약점: HSTS는 TLS 연결 자체의 보안을 강화하지는 못한다. 따라서 BEAST나 CRIME과 같이 TLS 프로토콜 자체를 공격하는 방법에는 대응하기 어렵다. HSTS는 기본적으로 HTTPS 연결이 안전하다는 전제 하에 작동하므로, TLS 자체의 보안이 깨지면 HSTS 역시 무력화될 수 있다.[27]
  • 서버 공격: 웹 서버 자체가 해킹당하는 경우에는 HSTS가 아무런 보호 기능을 제공하지 못한다. 공격자가 서버를 장악하면 정상적인 HTTPS 통신을 통해 악의적인 콘텐츠를 전달할 수 있다.

4. 3. 기타 보안 고려 사항

HSTS는 HTTPS 연결의 보안을 강화하지만, 몇 가지 중요한 한계점을 가지고 있다.

우선, HSTS는 TLS 자체의 보안성에 의존한다.[27] 만약 TLS 프로토콜 자체에 BEAST나 CRIME과 같은 심각한 취약점이 발견될 경우, HSTS는 이를 방어할 수 없다. 이는 HSTS가 암호화된 연결이 이미 안전하다고 가정하고 작동하기 때문이다. HSTS 정책 시행과 TLS 자체의 보안 문제는 서로 독립적인, 즉 직교 관계에 있다. 또한, 웹 서버 자체가 해킹당하는 경우에도 HSTS는 무력하다. 공격자가 서버를 장악하면 정상적인 TLS 연결을 통해 악의적인 콘텐츠를 전송할 수 있기 때문이다.

HSTS의 또 다른 약점은 최초 접속 시의 취약점이다.[28] 사용자가 특정 웹사이트에 처음 접속할 때는 브라우저가 해당 사이트가 HSTS를 사용하는지 알지 못한다. 이 순간에 중간자 공격이 발생하면 사용자는 자신도 모르게 암호화되지 않은 HTTP 연결을 하거나 가짜 인증서가 사용된 HTTPS 연결을 할 수 있다.

이 문제를 해결하기 위해 주요 웹 브라우저(구글 크롬, 모질라 파이어폭스, 인터넷 익스플로러/마이크로소프트 엣지 등)는 HSTS 사전 로드 목록(HSTS Preload List)을 사용한다.[14][10][11][15] 이 목록에는 HSTS를 지원하는 것으로 알려진 사이트들의 정보가 미리 포함되어 있어, 해당 사이트에 처음 접속할 때부터 강제로 HTTPS를 사용하게 만든다. 하지만 이 목록이 전 세계 모든 웹사이트를 포함하는 것은 현실적으로 불가능하다.

HSTS 사전 로드 목록에 없거나 아직 HSTS 정책을 수신하지 못한 사이트의 경우, DNS 기반 공격에 취약할 수 있다. 주나데 알리(Junade Ali)는 DNS 스푸핑[18]이나 실제 도메인과 혼동하기 쉬운 유사 도메인(예: ''www.example.com'' 대신 ''www.example.org'')을 이용한 공격을 통해 중간자 공격자가 가짜 사이트로 트래픽을 유도할 수 있다고 지적했다.[17] 이러한 공격은 HSTS 정책이 적용되기 전에 이루어질 수 있다. 잠재적인 해결책으로 DNS 레코드에 HSTS 정책을 명시하고 DNSSEC를 통해 안전하게 접근하는 방안이 논의되고 있지만, 이 역시 최종 통신망 문제 등 해결해야 할 과제가 있다.[16]

5. 개인 정보 문제

HSTS는 방문하는 브라우저에 거의 지울 수 없는 식별 정보(슈퍼쿠키)를 남기는 데 악용될 수 있다. 이러한 정보는 브라우저의 시크릿 모드와 같은 개인 정보 보호 기능을 사용하더라도 계속 유지될 수 있다는 문제점이 있다. 예를 들어, 특정 웹 페이지가 여러 도메인에 HTTP 요청을 보내도록 만들 수 있다. 만약 20개의 다른 도메인에 요청을 보내게 되면, 각 도메인에 대해 이전에 HSTS 헤더가 설정되었는지(즉, HTTPS로 접속하는지) 여부를 확인하여 20개의 '비트' 정보를 얻을 수 있다. 이론적으로 이는 220, 즉 백만 명이 넘는 방문자를 구별할 수 있는 식별자를 만드는 것과 같다.[19]

6. 브라우저 지원

크로미움 45 내의 HTTPS 엄격 전송 보안 설정을 보여주는 설정 페이지로, "en.wikipedia.org" 도메인에 대한 보안 정책의 상태를 보여준다.

7. 구현 모범 사례

실제 배포 시 모범 사례를 따르면 쿠키 삽입 공격과 같은 특정 위협을 피할 수 있다.


  • HSTS 호스트는 최상위 도메인 이름에서 HSTS 정책을 선언해야 한다. 예를 들어, `https://sub.example.com`의 HSTS 호스트는 `https://example.com`에서도 HSTS 헤더로 응답해야 한다. 헤더는 `includeSubDomains` 지시문을 지정해야 한다.
  • 또한, `https://www.example.com`의 호스트는 `https://example.com`의 리소스 요청을 포함하여 상위 도메인에도 HSTS를 설정해야 한다. 이는 공격자가 MITM 공격을 통해 상위 도메인(예: `http://nonexistentpeer.example.com`)에 대한 참조를 삽입하여 수행할 수 있는 잠재적인 쿠키 삽입 공격으로부터 사용자를 보호하기 위함이다.

참조

[1] 웹사이트 Strict-Transport-Security https://developer.mo[...] Mozilla 2018-01-31
[2] 웹사이트 "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)" https://www.ietf.org[...] 2012-10-02
[3] 웹사이트 Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...) http://www.ietf.org/[...] 2010-06-30
[4] 웹사이트 Strict Transport Security -06 http://lists.w3.org/[...] 2009-12-18
[5] 웹사이트 Strict Transport Security -05 http://lists.w3.org/[...] 2009-09-18
[6] 웹사이트 ForceHTTPS: Protecting High-Security Web Site from Network Attacks https://crypto.stanf[...] 2008-04
[7] 웹사이트 The Need for Coherent Web Security Policy Framework(s) http://www.thesecuri[...] 2010-10-29
[8] 간행물 New Tricks For Defeating SSL In Practice https://blackhat.com[...]
[9] Youtube Defeating SSL Using Sslstrip MFol6IMbZ7Y
[10] 웹사이트 Strict Transport Security https://www.chromium[...] 2010-07-08
[11] 웹사이트 Preloading HSTS https://blog.mozilla[...] 2012-11-01
[12] 웹사이트 Firesheep and HSTS (HTTP Strict Transport Security) http://identitymeme.[...] 2010-10-31
[13] 간행물 Bypassing HTTP Strict Transport Security https://www.blackhat[...] 2014-10-17
[14] 웹사이트 Chromium HSTS Preloaded list https://cs.chromium.[...] 2019-07-10
[15] 웹사이트 HTTP Strict Transport Security comes to Internet Explorer http://blogs.msdn.co[...] 2015-02-16
[16] 웹사이트 HTTP Strict Transport Security https://simon.butche[...] 2011-09-11
[17] 웹사이트 Performing & Preventing SSL Stripping: A Plain-English Primer https://blog.cloudfl[...] 2017-10-20
[18] 간행물 Detection and prevention of DNS spoofing attacks 2017
[19] 웹사이트 'The HSTS super cookie forcing you to choose: "privacy or security?" -' https://nakedsecurit[...] 2015-02-02
[20] 웹사이트 Strict Transport Security - The Chromium Projects https://dev.chromium[...] 2010-11-17
[21] 웹사이트 fyi: Strict Transport Security specification http://lists.w3.org/[...] 2009-09-18
[22] 웹사이트 Web specifications support in Opera Presto 2.10 http://www.opera.com[...] 2012-04-23
[23] 트윗 Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers. https://twitter.com/[...] 2013-12-20
[24] 웹사이트 HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7 http://blogs.windows[...] 2015-06-12
[25] 웹사이트 Internet Explorer Web Platform Status and Roadmap https://status.moder[...] 2014-04-14
[26] 웹사이트 Project Spartan and the Windows 10 January Preview Build - IEBlog https://blogs.msdn.m[...] 2015-01-22
[27] 웹사이트 Section 14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport https://datatracker.[...] IETF 2012-11
[28] 웹사이트 Section 14.6. Bootstrap MITM Vulnerability https://datatracker.[...] IETF 2012-11
[29] 웹인용 Strict-Transport-Security https://developer.mo[...] Mozilla 2018-01-31
[30] Cite IETF HTTP Strict Transport Security (HSTS) IETF 2012-11


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com