[Daily morning study] HTTPS와 TLS 핸드셰이크 과정

30 Oct 2026 in Daily morning study / Network

#daily morning study

HTTPS란

HTTP에 SSL/TLS 암호화 계층을 추가한 프로토콜. 기본 포트는 443.

HTTPS가 제공하는 보안 속성:

기밀성(Confidentiality): 데이터를 암호화해 도청 방지
무결성(Integrity): 전송 중 데이터 변조 감지
인증(Authentication): 서버(혹은 클라이언트)가 신뢰할 수 있는 대상인지 확인

TLS란

TLS(Transport Layer Security)는 SSL의 후속 버전. 실제로 지금 쓰이는 건 TLS 1.2 / TLS 1.3이며 SSL이라는 이름은 관습적으로 남아있다.

버전	출시	현황
SSL 3.0	1996	폐기 (POODLE 취약점)
TLS 1.0 / 1.1	1999 / 2006	폐기 (2020년, RFC 8996)
TLS 1.2	2008	현재도 널리 사용
TLS 1.3	2018	최신 권장 버전

TLS 1.2 핸드셰이크 과정

TLS 1.2는 총 2-RTT(Round Trip Time) 이 필요하다.

Client                                Server
  |                                     |
  |--- ClientHello ------------------>  |
  |  (지원 TLS 버전, 암호 스위트 목록,     |
  |   클라이언트 랜덤값)                  |
  |                                     |
  |<-- ServerHello -------------------- |
  |  (선택된 TLS 버전, 암호 스위트,        |
  |   서버 랜덤값)                        |
  |                                     |
  |<-- Certificate ------------------- |
  |  (서버 인증서 = 공개키 포함)           |
  |                                     |
  |<-- ServerHelloDone --------------- |
  |                                     |
  |--- ClientKeyExchange ----------->  |
  |  (Pre-Master Secret 전달,           |
  |   서버 공개키로 암호화)               |
  |                                     |
  |--- ChangeCipherSpec ------------->  |
  |--- Finished --------------------->  |
  |                                     |
  |<-- ChangeCipherSpec --------------- |
  |<-- Finished ----------------------  |
  |                                     |
  |=== 암호화된 애플리케이션 데이터 교환 ===|

각 단계 상세

1. ClientHello

클라이언트가 지원하는 TLS 버전 목록
지원하는 암호 스위트(Cipher Suite) 목록
클라이언트 랜덤값 (32바이트 난수)

2. ServerHello

서버가 선택한 TLS 버전 1개
선택한 암호 스위트 1개
서버 랜덤값 (32바이트 난수)

3. Certificate

서버의 X.509 인증서를 클라이언트에 전달
인증서 안에는 서버의 공개키가 포함됨
클라이언트는 CA(Certificate Authority) 체인을 검증

4. ClientKeyExchange

Pre-Master Secret 생성 → 서버 공개키로 암호화 → 전송
서버는 자신의 개인키로 복호화해 Pre-Master Secret 획득

5. Master Secret 생성

클라이언트와 서버 양쪽에서 독립적으로 계산:

Master Secret = PRF(Pre-Master Secret, "master secret", ClientRandom + ServerRandom)

이 Master Secret에서 실제 암호화에 쓸 세션 키들을 파생

6. ChangeCipherSpec + Finished

“이제부터 협상한 키로 암호화해서 통신하겠다”는 신호
Finished 메시지 = 지금까지 핸드셰이크 과정 전체의 MAC(무결성 검증)

암호 스위트(Cipher Suite)

하나의 암호 스위트는 4개의 알고리즘을 명시한다.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 ↑     ↑     ↑       ↑           ↑
 |  키교환  인증   대칭암호화    MAC/해시
 프로토콜

구성 요소	역할	예시
키 교환	Pre-Master Secret 안전하게 교환	RSA, ECDHE, DHE
인증	서버 신원 검증	RSA, ECDSA
대칭 암호화	실제 데이터 암호화	AES-128-GCM, ChaCha20
MAC	메시지 무결성	SHA256, SHA384

TLS 1.3 핸드셰이크 — 1-RTT로 단축

TLS 1.3은 핸드셰이크를 대폭 간소화해 1-RTT로 끝낸다.

Client                                Server
  |                                     |
  |--- ClientHello ------------------>  |
  |  (지원 그룹, 키 공유(KeyShare),      |
  |   클라이언트 랜덤값)                  |
  |                                     |
  |<-- ServerHello ------------------- |
  |<-- EncryptedExtensions ----------- |
  |<-- Certificate ------------------- |
  |<-- CertificateVerify ------------- |
  |<-- Finished ----------------------  |
  |                                     |
  |--- Finished --------------------->  |
  |                                     |
  |=== 암호화된 애플리케이션 데이터 교환 ===|

TLS 1.3 주요 변경 사항:

RSA 키 교환 제거 → ECDHE만 사용 (PFS 강제)
ServerHello 이후 즉시 암호화 → 인증서도 암호화된 상태로 전달
0-RTT 재연결 지원 (Session Ticket을 이용한 Early Data)
취약한 알고리즘(MD5, SHA-1, RC4, DES 등) 완전 제거

PFS(Perfect Forward Secrecy)란

과거에 캡처된 트래픽이 나중에 서버 개인키가 유출되더라도 복호화되지 않는 성질.

RSA 키 교환: PFS 없음 — 개인키 유출 시 과거 세션 전부 복호화 가능
DHE / ECDHE 키 교환: PFS 있음 — 세션마다 임시 키 쌍 생성, 사용 후 폐기

TLS 1.3이 ECDHE를 강제하는 이유가 바로 PFS 보장이다.

X.509 인증서 구조

X.509 Certificate
├── 버전 (Version): v3
├── 일련번호 (Serial Number)
├── 서명 알고리즘 (Signature Algorithm)
├── 발급자 (Issuer): CA 정보
├── 유효기간 (Validity): Not Before / Not After
├── 주체 (Subject): 도메인(CN), 조직(O) 등
├── 공개키 (Subject Public Key Info)
└── 확장 필드 (Extensions)
    ├── SAN (Subject Alternative Names): 적용 도메인 목록
    ├── Key Usage
    └── ...

인증서 체인 검증

Root CA (브라우저/OS에 내장)
   ↓ 서명
Intermediate CA
   ↓ 서명
End-Entity Certificate (서버 인증서)

브라우저는 서버가 보내온 인증서에서 Root CA까지 체인을 따라가며 서명을 검증한다. Root CA는 자체 서명(self-signed)이며 브라우저와 OS에 미리 내장되어 있다.

OCSP와 CRL — 인증서 폐기 확인

인증서가 유효기간 내에도 폐기될 수 있다. 이를 확인하는 방법:

방법	설명	단점
CRL (Certificate Revocation List)	CA가 배포하는 폐기 목록	파일 크기가 커질 수 있음
OCSP (Online Certificate Status Protocol)	실시간으로 CA에 상태 조회	매 연결마다 추가 RTT
OCSP Stapling	서버가 OCSP 응답을 미리 캐싱해서 함께 전달	서버 구현 필요

OCSP Stapling이 성능과 프라이버시 측면에서 현재 권장되는 방식이다.

HSTS (HTTP Strict Transport Security)

서버가 브라우저에게 “이 도메인은 HTTPS만 사용하라”고 지시하는 헤더.

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

max-age: HSTS 정책을 적용할 기간(초)
includeSubDomains: 서브도메인에도 적용
preload: 브라우저 내장 목록에 등록 요청

HSTS가 없으면 사용자가 처음 http://로 접속할 때 리다이렉트를 받는 사이에 MITM 공격 가능(SSL Stripping). HSTS는 이 첫 번째 요청조차 HTTPS로 강제한다.

정리

항목	TLS 1.2	TLS 1.3
핸드셰이크 RTT	2-RTT	1-RTT (0-RTT 재연결 지원)
키 교환	RSA, DHE, ECDHE	ECDHE만 (PFS 강제)
PFS	선택적	필수
서버 인증서 전송	평문	암호화
지원 암호 스위트	많음 (일부 취약)	5개만 (모두 AEAD)

[Daily morning study] HTTPS와 TLS 핸드셰이크 과정

HTTPS란

TLS란

TLS 1.2 핸드셰이크 과정

각 단계 상세

암호 스위트(Cipher Suite)

TLS 1.3 핸드셰이크 — 1-RTT로 단축

PFS(Perfect Forward Secrecy)란

X.509 인증서 구조

인증서 체인 검증

OCSP와 CRL — 인증서 폐기 확인

HSTS (HTTP Strict Transport Security)

정리

🐒🇰🇷

Error

HTTPS란

TLS란

TLS 1.2 핸드셰이크 과정

각 단계 상세

암호 스위트(Cipher Suite)

TLS 1.3 핸드셰이크 — 1-RTT로 단축

PFS(Perfect Forward Secrecy)란

X.509 인증서 구조

인증서 체인 검증

OCSP와 CRL — 인증서 폐기 확인

HSTS (HTTP Strict Transport Security)

정리

Templates (for web app):

Error