TLS 1.3은 현재 버전의 Transport Layer Security 프로토콜로, 2018년 8월 RFC 8446으로 발표되었습니다. 점진적 업데이트가 아닌 근본적인 재설계로, HTTPS를 이전 버전보다 더 빠르고, 더 간단하고, 더 안전하게 만듭니다.
2026년 현재 62%의 웹사이트가 TLS 1.3을 지원하며, 모든 주요 브라우저가 2018년부터 이를 지원해왔습니다.
TLS 1.2에서 변경된 점
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| 핸드셰이크 | 2 왕복 | 1 왕복 (1-RTT) |
| 재연결 | 1 왕복 | 0-RTT (첫 메시지와 함께 데이터 전송) |
| 암호화 스위트 | 37개 (약한 것 다수) | 5개 (모두 안전) |
| 순방향 비밀성 | 선택 사항 | 필수 |
| RSA 키 교환 | 지원 | 제거 |
| 정적 DH | 지원 | 제거 |
| CBC 암호 | 지원 | 제거 |
| RC4, DES, 3DES | 일부 설정 | 제거 |
| 핸드셰이크에서 MD5, SHA-1 | 허용 | 제거 |
| 핸드셰이크의 인증서 | 평문 (보임) | 암호화됨 |
| 압축 | 선택 사항 | 제거 (CRIME 방지) |
| 재협상 | 지원 | 제거 |
설계 철학: 잘못 설정할 수 있는 모든 것을 제거. TLS 1.2에는 37개의 암호화 스위트가 있는데, 일부는 안전하고 일부는 취약합니다. TLS 1.3에는 5개가 있으며, 모두 안전합니다.
TLS 1.3의 5가지 암호화 스위트
TLS_AES_256_GCM_SHA384 ← 가장 강력, 가장 일반적
TLS_AES_128_GCM_SHA256 ← 널리 사용됨, 약간 더 빠름
TLS_CHACHA20_POLY1305_SHA256 ← ARM/모바일에 최적 (AES-NI 없음)
TLS_AES_128_CCM_SHA256 ← IoT/임베디드
TLS_AES_128_CCM_8_SHA256 ← IoT/임베디드 (짧은 태그)이것들을 잘못 설정할 수 없습니다 — 모두 강력한 키를 가진 AEAD 암호입니다. TLS 1.2에서처럼 “실수로 약한 암호를 활성화”할 위험이 없습니다.
1-RTT 핸드셰이크: 왜 더 빠른가
TLS 1.2 핸드셰이크 (2 왕복):
클라이언트 → 서버: ClientHello (지원 암호)
서버 → 클라이언트: ServerHello, Certificate, KeyExchange
클라이언트 → 서버: KeyExchange, ChangeCipherSpec, Finished
서버 → 클라이언트: ChangeCipherSpec, Finished
[암호화된 데이터 흐름 전 4개 메시지]TLS 1.3 핸드셰이크 (1 왕복):
클라이언트 → 서버: ClientHello + KeyShare
서버 → 클라이언트: ServerHello + KeyShare + Certificate + Finished
클라이언트 → 서버: Finished
[1 왕복 후 암호화된 데이터 흐름 가능]클라이언트가 첫 번째 메시지에서 키 공유 매개변수를 전송합니다 — 서버가 먼저 알고리즘을 지정할 때까지 기다릴 필요 없음. 이것이 핸드셰이크를 2 왕복에서 1로 줄입니다.
0-RTT 재개
재방문자(이전에 연결한 적이 있는)의 경우, TLS 1.3은 0-RTT를 지원합니다 — 첫 번째 메시지와 함께 암호화된 애플리케이션 데이터 전송:
클라이언트 → 서버: ClientHello + KeyShare + EarlyData (암호화된 요청)
서버 → 클라이언트: ServerHello + 응답핸드셰이크가 완료되기 전에 요청이 전송됩니다. 트레이드오프: 0-RTT 데이터는 재생 공격에 취약하므로 멱등 요청(GET, POST가 아닌)에만 사용해야 합니다.
필수 순방향 비밀성
TLS 1.2에서는 RSA 키 교환을 사용할 수 있었습니다 — 서버의 장기 RSA 키가 프리마스터 비밀을 직접 복호화합니다. 누군가 트래픽을 기록했다가 나중에 서버의 개인키를 탈취하면 모든 과거 대화를 복호화할 수 있습니다.
TLS 1.3은 RSA 키 교환을 완전히 제거합니다. 모든 키 교환은 임시 Diffie-Hellman(ECDHE)을 사용합니다 — 모든 연결에 대해 고유한 키 쌍이 생성됩니다. 서버의 개인키를 탈취해도 과거 세션을 복호화하는 데 도움이 되지 않습니다. 순방향 비밀성에 대해 더 알아보기 →
암호화된 인증서
TLS 1.2에서는 서버 인증서(도메인 이름 포함)가 핸드셰이크 중 평문으로 전송됩니다. 수동 관찰자가 어떤 사이트에 연결하는지 볼 수 있습니다.
TLS 1.3에서는 인증서가 핸드셰이크 키가 파생된 후에 전송됩니다 — 암호화됩니다. SNI(Server Name Indication)는 TLS 1.3에서도 여전히 보이지만, **Encrypted Client Hello(ECH)**가 향후 이것도 암호화할 것입니다.
TLS 1.3 활성화 방법
이미 활성화되어 있는지 확인
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# 예상: TLSv1.3Nginx (1.13+ + OpenSSL 1.1.1+)
ssl_protocols TLSv1.2 TLSv1.3;TLS 1.3은 최신 Nginx에서 기본 활성화됩니다 — 비활성화하지만 않으면 됩니다.
Apache (2.4.37+ + OpenSSL 1.1.1+)
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1이것은 TLS 1.2와 1.3을 활성화합니다.
OpenSSL 버전 확인
openssl version
# 필요: TLS 1.3 지원을 위한 OpenSSL 1.1.1+OpenSSL이 이전 버전이면 업그레이드하거나 OS를 업그레이드하세요.
TLS 1.3만 강제해야 하나요?
아직은 아닙니다. 약 38%의 사이트가 TLS 1.3을 지원하지 않으며, 일부 클라이언트(기업 프록시, Java 8, 구형 임베디드 시스템)는 TLS 1.2만 지원합니다. 오늘 TLS 1.2를 제거하면 일부 사용자가 접속할 수 없게 됩니다.
권장 설정: TLS 1.2와 1.3 모두 지원. 최신 클라이언트에게 TLS 1.3의 속도를 제공하면서 호환성을 유지합니다. 이것이 Google, Cloudflare, 대부분의 주요 사이트가 사용하는 방식입니다.
자주 묻는 질문
TLS 1.3에 새 인증서가 필요한가요?
아닙니다. 동일한 인증서가 TLS 1.2와 1.3에서 모두 작동합니다. 인증서는 프로토콜에 독립적입니다 — 어떤 TLS 버전이 사용하든 공개키와 CA 서명을 포함합니다.
TLS 1.3이 성능에 영향을 미치나요?
네, 긍정적으로. 1-RTT 핸드셰이크로 첫 연결에서 50-100ms를 절약합니다. 0-RTT 재개는 재방문자에 대한 핸드셰이크 지연을 완전히 제거합니다. HTTP/2(HTTPS 필요)와 결합하면 TLS 1.3 사이트는 측정 가능하게 빠릅니다.
TLS 1.2는 아직 안전한가요?
네, AEAD 암호화 스위트(AES-GCM, ChaCha20-Poly1305)와 ECDHE 키 교환을 사용하는 경우. TLS 1.2에서 CBC 암호를 피하세요 — 공격(BEAST, Lucky13)에 취약합니다. TLS 1.3이 더 좋지만, 최신 암호를 사용하는 TLS 1.2는 여전히 안전합니다.
TLS 1.4는?
TLS 1.4는 계획되어 있지 않습니다. IETF는 TLS 1.3을 예측 가능한 미래의 목표로 봅니다. 다음 주요 변경은 기존 ECDHE와 하이브리드로 후양자 키 교환(ML-KEM)을 도입하는 것으로, 새 버전이 아닌 TLS 1.3 내에서 이루어질 것입니다.