HTTPS TLS, HSTS

HTTP의 한계

기본적으로 HTTP 프로토콜은 평문(plain text)으로 데이터를 주고 받고,

이는 로그인 정보, 세션 쿠키, API 응답 등 모든 통신 내용이 노출될 수 있는 위험을 내포한다.

이런 HTTP의 한계를 이용한 대표적인 공격으로는

중간자 공격(MITM, Man-in-the-Middle)이 있으며, 공격자는 이 공격을 통해 사용자의 네트워크

트래픽을 가로채고 내용을 열람하거나 수정할 수 있다. (e.g. 카페 와이파이에서 비밀번호 유출)

이를 해결하기 위해, 평문의 데이터를 전송, 즉 주고 받을 때

전송 구간을 암호화(Encryption) 하는 것을 도입하고자 했다.

이 암호화를 수행하는 기술을 TLS(Transport Layer Security) 라 한다.

 

TLS?

웹 통신을 암호화하기 위한 표준 프로토콜,

이전에는 SSL(Secure Sockets Layer)이라 불렸지만, 여러 보안 결함이 발견되었다.

여러 보안 결함들을 해결하고 추가적인 보안 기능을 제공하도록 개선된 것이 TLS(버전 업그레이드).

TLS는 통신 과정에서 다음 세 가지를 보장한다.

  • 기밀성(Confidentiality): 제3자가 데이터를 읽을 수 없음.
  • 무결성(Integrity): 데이터가 중간에서 변조되지 않음.
  • 인증(Authentication): 서버 또는 클라이언트가 신뢰할 수 있는 대상임을 검증.

 

TLS 핸드셰이크 과정

TLS는 실제 데이터 전송 전에 암호화된 연결을 수립(handshake)한다.

 

Client Hello

브라우저(클라이언트)가 서버에 TLS를 사용하고 싶은 의사와 가능한 암호화 알고리즘을 제안한다.

 

Server Hello

서버가 암호화 알고리즘을 선택, 공개키가 담긴 SSL 인증서를 전달한다.

 

인증서 검증

브라우저는 이 인증서가 신뢰할 수 있는 기관(CA, Certificate Authority)에서 발급된 것인지 검증,

인증서에 포함된 도메인, 만료일, 서명 정보 등을 검사한다.

 

비밀키 교환

브라우저와 서버는 공개키 암호화를 통해 세션 키를 교환,

이후 데이터는 이 세션 키로 대칭 암호화되어 통신한다.

 

 

HTTPS는 TLS 위의 HTTP

HTTPS = HTTP + TLS

HTTP의 내용(요청 메서드, 헤더, 바디 등)은 그대로, ‘전송하는 과정’만 암호화한다.

HTTPS의 효과

  • 통신 중 비밀번호, 쿠키, API 응답이 노출되지 않음.
  • 세션 하이재킹(Session Hijacking), 쿠키 탈취 등의 위험이 크게 줄어든다.
  • HTTP/2, HTTP/3 등 최신 프로토콜은 모두 HTTPS를 기반으로 동작.

 

HSTS(HTTP Strict Transport Security)

HTTPS를 적용했다고 완전히 안전한 것은 아니다.

최초 접속이 HTTP로 이루어지는 상황을 생각해보자.

e.g.

사용자가 http://example.com 을 입력하여 접속 시도,

브라우저에서는 먼저 HTTP로 요청 → 서버가 301 리다이렉트 → HTTP로 이동하게 된다.

이때, 이 첫 요청 사이에 공격자가 개입하면 여전히 중간자 공격 가능성이 존재하게 된다.

HSTS로 해결할 수 있다

HSTS는 서버가 브라우저에 다음 헤더를 내려주는 방식이다.

Strict-Transport-Security: max-age=3153600; includeSubDomains; preload

이후 브라우저는 해당 도메인에 대해,

  • 무조건 HTTPS로만 접속하도록 강제.
  • HTTP 요청 시도하지 않음(리다이렉트 이전에 차단)
  • preload 옵션을 등록 시 주요 브라우저의 HSTS Preload List에 도메인이 포함되어, 첫 방문 전에 HTTPS만 사용 가능.

즉, 사용자가 HTTP로 접속하도록 허용하지 않는다.

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다