2026.08.05
2026.08.05
현대 TLS는 대칭키 암호와 비대칭키 암호를 함께 사용하는 복합적인 프로토콜입니다.
대표적으로 다음 두 기술을 결합합니다.
이 둘을 결합한 것이 인증된 키 교환입니다.
합의된 공유 비밀로부터 세션용 대칭키를 생성하고, 이후 실제 HTTP 요청과 응답은 대칭키 암호 방식으로 보호합니다.
TLS 1.3에서는 과거처럼 RSA 공개키로 비밀값을 암호화해 서버에 전달하는 RSA 키 운반 방식을 사용하지 않습니다.
모던한 TLS의 교환 방식을 이해할 때 가장 중요한 점은 이것입니다.
TLS는 실제 HTTP 데이터를 비대칭키로 계속 암호화하지 않습니다. 비대칭키는 주로 상대방 인증과 공유 대칭키 생성에 사용하고, 이후 데이터는 빠른 대칭키로 암호화합니다.
TLS 1.3의 핸드셰이크는 공식적으로도 인증된 키 교환, 즉 Authenticated Key Exchange로 정의됩니다.
하나의 동일한 키로 암호화하고 복호화합니다.
평문 + 대칭키 → 암호문
암호문 + 같은 대칭키 → 평문
대표적인 알고리즘:
AES-GCM
ChaCha20-Poly1305
장점은 매우 빠르다는 것이고, 단점은 통신 전에 양쪽이 같은 키를 어떻게 안전하게 나눠 가질 것인지가 어렵다는 것입니다.
서로 다른 두 키를 사용합니다.
공개키: 다른 사람에게 공개
개인키: 소유자만 보관
다만 “공개키로 암호화하고 개인키로 복호화한다”는 설명만으로는 현대 TLS를 정확히 설명할 수 없습니다.
TLS에서 비대칭키 기술은 크게 두 역할로 나뉩니다.
1. 디지털 서명
→ 서버가 진짜 서버인지 증명
2. 키 합의
→ 클라이언트와 서버가 동일한 대칭키 재료를 생성
현대 TLS에서는 이 두 역할이 분리되어 있습니다.
TLS는 통신 과정에서 주로 다음을 보장하려고 합니다.
중간에서 패킷을 훔쳐봐도 내용을 알 수 없어야 합니다.
HTTP 요청
Authorization 헤더
쿠키
응답 데이터
이것은 최종적으로 대칭키 암호가 담당합니다.
중간자가 데이터를 바꿨는지 검출할 수 있어야 합니다.
예를 들어 공격자가 다음 요청을:
송금액: 10,000원
이렇게 바꾸면:
송금액: 10,000,000원
TLS 레코드 검증에 실패해야 합니다.
현대 TLS의 AES-GCM이나 ChaCha20-Poly1305는 암호화와 무결성 검증을 함께 제공하는 AEAD 방식입니다.
접속한 대상이 정말 해당 도메인의 서버인지 확인해야 합니다.
내가 접속한 서버가 정말 example.com인가?
공격자가 example.com인 척하는 것은 아닌가?
여기에 인증서와 디지털 서명이 사용됩니다.
다음 세 가지를 구분해야 합니다.
| 구분 | 목적 | 대표 알고리즘 |
|---|---|---|
| 인증서 공개키 | 서버 신원 인증 | RSA, ECDSA |
| 핸드셰이크 서명 | 개인키 보유 증명 | RSA-PSS, ECDSA, EdDSA |
| 키 교환·합의 | 세션키 재료 생성 | ECDHE, DHE |
특히 다음은 서로 다른 개념입니다.
RSA 인증서
≠ RSA 키 교환
서버가 RSA 인증서를 가지고 있어도 키 교환은 ECDHE로 할 수 있습니다.
예를 들어 TLS 1.2의 다음 암호 스위트가 그렇습니다.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
각 부분의 의미는 다음과 같습니다.
ECDHE
→ 키 합의 방식
RSA
→ 서버 서명·인증 방식
AES_128_GCM
→ 실제 데이터 암호화 방식
SHA256
→ 핸드셰이크 등에 사용하는 해시
즉 RSA가 들어 있다고 해서 HTTP 데이터를 RSA로 암호화한다는 뜻은 아닙니다.
사용자가 다음 주소로 접속한다고 해보겠습니다.
https://example.com
서버는 TLS 핸드셰이크 중 자신의 인증서를 보냅니다.
인증서에는 대략 다음 정보가 들어 있습니다.
도메인 이름: example.com
서버 공개키
발급자: 인증기관 CA
유효기간
사용 가능한 목적
CA의 디지털 서명
중요한 점은 인증서 안에 서버 개인키는 들어 있지 않는다는 것입니다.
서버:
공개키 → 인증서에 포함
개인키 → 서버 내부에 보관
인증기관 CA는 인증서 내용을 해시한 뒤, CA의 개인키로 서명합니다.
개념적으로는 다음과 같습니다.
인증서 내용
↓ 해시
해시값
↓ CA 개인키로 서명
CA 서명
클라이언트는 운영체제나 브라우저에 내장된 CA 공개키를 이용해 서명을 검증합니다.
인증서 내용 → 직접 해시 계산
CA 서명 → CA 공개키로 검증
두 결과가 일치하는지 확인
이를 통해 다음을 확인합니다.
1. 인증서가 CA에 의해 발급되었는가?
2. 인증서 내용이 발급 후 변조되지 않았는가?
하지만 CA 서명만 확인해서 끝나는 것은 아닙니다.
클라이언트는 추가로 다음을 검사합니다.
접속한 호스트명이 인증서의 SAN과 일치하는가?
유효기간이 지나지 않았는가?
신뢰할 수 있는 CA 체인인가?
서버 인증 용도로 발급된 인증서인가?
인증서가 폐기된 것은 아닌가?
서명 알고리즘이 허용되는가?
서버 인증서는 보통 루트 CA가 직접 서명하지 않습니다.
일반적으로 구조는 다음과 같습니다.
Root CA
↓ 서명
Intermediate CA
↓ 서명
example.com 서버 인증서
서버는 보통 클라이언트에게 다음을 보냅니다.
서버 인증서
중간 CA 인증서
루트 CA 인증서는 브라우저나 운영체제의 신뢰 저장소에 이미 들어 있습니다.
클라이언트는 다음 순서로 검증합니다.
서버 인증서
↓ 중간 CA 공개키로 검증
중간 CA 인증서
↓ 루트 CA 공개키로 검증
루트 CA
↓ 로컬 신뢰 저장소에 있는지 확인
이렇게 신뢰가 이어지는 구조를 인증서 체인 또는 신뢰 체인이라고 합니다.
그렇지 않습니다.
공격자는 공개된 서버 인증서를 복사할 수 있습니다. 인증서는 본래 공개 정보입니다.
따라서 서버는 다음도 증명해야 합니다.
인증서에 들어 있는 공개키와 대응되는 개인키를 실제로 보유하고 있다.
TLS 1.3에서는 서버가 CertificateVerify 메시지를 보냅니다.
개념적으로 다음과 같습니다.
지금까지의 TLS 핸드셰이크 메시지
↓ 해시
핸드셰이크 해시
↓ 서버 개인키로 서명
CertificateVerify
클라이언트는 인증서 안의 서버 공개키로 이 서명을 검증합니다.
성공한다면 다음을 알 수 있습니다.
이 서버는 인증서의 개인키를 실제로 가지고 있다.
핸드셰이크 메시지가 중간에서 변조되지 않았다.
이 서명은 현재 진행 중인 핸드셰이크에 결합되어 있다.
TLS 1.3의 서버 인증은 인증서를 제공하는 것뿐 아니라, 해당 인증서의 개인키로 유효한 서명을 만들어 개인키 보유 사실을 증명하는 구조입니다.
현대 TLS에서 가장 중요한 비대칭키 기술은 ECDHE입니다.
Elliptic Curve
Diffie-Hellman
Ephemeral
각 단어의 의미는 다음과 같습니다.
Elliptic Curve
→ 타원곡선 수학을 사용
Diffie-Hellman
→ 서로 비밀값을 직접 보내지 않고 공유 비밀을 합의
Ephemeral
→ 연결마다 임시 키를 새로 생성
클라이언트와 서버가 각각 임시 개인값을 생성합니다.
클라이언트 임시 개인키: a
서버 임시 개인키: b
그리고 각자 공개값을 계산합니다.
클라이언트 공개값: A
서버 공개값: B
둘은 공개값을 서로 교환합니다.
클라이언트 → 서버: A
서버 → 클라이언트: B
그런 다음 각자 다음을 계산합니다.
클라이언트:
자신의 개인키 a + 서버 공개키 B
→ 공유 비밀 S
서버:
자신의 개인키 b + 클라이언트 공개키 A
→ 공유 비밀 S
결과적으로 둘은 같은 값을 얻게 됩니다.
클라이언트 계산 결과 = 서버 계산 결과 = S
하지만 네트워크에 실제로 전송된 것은 다음뿐입니다.
A
B
임시 개인키인 a, b와 공유 비밀 S는 전송되지 않습니다.
조금 더 수학적으로 표현하면 공개된 기준점 G가 있습니다.
클라이언트는 임시 개인키 a를 정하고:
A = aG
서버는 임시 개인키 b를 정합니다.
B = bG
공개값 A, B를 교환한 뒤 클라이언트는:
aB = a(bG) = abG
서버는:
bA = b(aG) = abG
를 계산합니다.
결국 둘 다 같은 점을 얻습니다.
공유 비밀 = abG
공격자는 다음을 알고 있습니다.
G
A = aG
B = bG
하지만 A와 G를 보고 a를 역산하는 것은 적절한 곡선과 키 크기를 사용할 경우 계산상 매우 어렵습니다. 이 어려움이 타원곡선 이산로그 문제에 기반합니다.
실제 구현에서 공유된 타원곡선 점 자체를 그대로 AES 키로 사용하는 것은 아닙니다. 이 값은 HKDF 기반 키 스케줄의 입력 재료가 됩니다.
ECDHE 자체만으로는 막을 수 없습니다.
공격자가 클라이언트와 서버 사이에 있다면 다음처럼 각각 별도의 키 합의를 할 수 있습니다.
클라이언트 ↔ 공격자
공격자 ↔ 서버
클라이언트는 공격자의 공개값을 서버의 것이라고 믿고, 서버는 공격자의 공개값을 클라이언트의 것이라고 믿을 수 있습니다.
따라서 ECDHE 공개값과 핸드셰이크 전체를 서버의 인증서 개인키 서명에 결합해야 합니다.
즉 현대 TLS는 두 기술을 함께 사용합니다.
ECDHE
→ 공유 비밀을 안전하게 합의
RSA-PSS / ECDSA / EdDSA 서명
→ 그 키 합의 상대가 인증된 서버임을 증명
이 둘을 합치면 인증된 키 교환이 됩니다.
일반적인 서버 인증 TLS 1.3 연결을 단순화하면 다음과 같습니다.
클라이언트 서버
ClientHello
- 지원 TLS 버전
- 지원 암호 스위트
- 지원 그룹
- 클라이언트 ECDHE 공개값 A
-------------------------->
ServerHello
- TLS 1.3 선택
- 암호 스위트 선택
- 서버 ECDHE 공개값 B
<--------------------------
양쪽에서 ECDHE 공유 비밀 S 계산
양쪽에서 핸드셰이크 대칭키 생성
EncryptedExtensions
Certificate
CertificateVerify
Finished
<--------------------------
서버 인증서·서명·핸드셰이크 무결성 검증
Finished
-------------------------->
애플리케이션용 대칭키 생성
암호화된 HTTP 요청 <=======================> 암호화된 HTTP 응답
중요한 특징은 ServerHello 이후 대부분의 핸드셰이크 메시지 자체도 이미 암호화된다는 점입니다.
ECDHE 결과를 곧바로 AES 키로 쓰지 않습니다.
TLS 1.3은 HKDF 기반 키 스케줄을 사용합니다.
개념적으로는 다음과 같습니다.
ECDHE 공유 비밀
+ 핸드셰이크 메시지들의 해시
+ HKDF
↓
클라이언트 핸드셰이크 키
서버 핸드셰이크 키
클라이언트 애플리케이션 키
서버 애플리케이션 키
Finished 검증 키
IV
재개용 비밀값
여기서 중요한 점은 통신 방향별 키가 다르다는 것입니다.
클라이언트 → 서버 암호화 키
서버 → 클라이언트 암호화 키
따라서 하나의 동일한 AES 키로 양방향 통신을 모두 암호화하는 단순한 구조가 아닙니다.
또한 핸드셰이크 메시지의 해시가 키 생성 과정에 포함되기 때문에, 공격자가 알고리즘이나 공개값을 변조하면 양쪽에서 서로 다른 키가 생성되거나 Finished 검증이 실패합니다.
CertificateVerify는 서버의 개인키 보유와 서명을 검증합니다.
Finished는 양쪽이 동일한 핸드셰이크 비밀값을 계산했고, 지금까지의 핸드셰이크가 변조되지 않았음을 확인합니다.
개념적으로는 다음과 같습니다.
finished_key
+ 지금까지의 핸드셰이크 해시
↓ HMAC
Finished 검증값
상대방이 보낸 Finished가 예상값과 일치하면 다음을 확인할 수 있습니다.
상대방도 같은 공유 비밀을 계산했다.
핸드셰이크 메시지가 변경되지 않았다.
협상된 알고리즘과 파라미터가 양쪽에서 동일하다.
ECDHE에서 E, 즉 Ephemeral은 연결마다 임시 키를 만든다는 뜻입니다.
예를 들어 오늘 TLS 연결에서 사용한 서버 임시 개인키 b는 연결이 끝난 후 폐기됩니다.
나중에 공격자가 서버의 인증서 개인키를 탈취하더라도 다음은 알 수 없습니다.
과거 연결의 클라이언트 임시 개인키 a
과거 연결의 서버 임시 개인키 b
과거 ECDHE 공유 비밀 S
따라서 과거에 녹화한 암호화 트래픽을 서버 인증서 개인키만 가지고 복호화할 수 없습니다.
이를 순방향 비밀성, Forward Secrecy라고 합니다.
장기 인증서 개인키 유출
≠ 과거 세션키 전체 유출
IETF 권고에서도 순방향 비밀성을 제공하는 키 교환을 우선하도록 하고 있습니다.
단, 순방향 비밀성은 다음 상황까지 해결하지는 못합니다.
서버가 이미 침해된 상태에서 실시간으로 평문이나 세션키가 탈취됨
클라이언트 단말 자체가 악성코드에 감염됨
애플리케이션 로그에 민감정보를 평문으로 남김
TLS 1.2 이하에는 RSA를 키 교환에 직접 사용하는 방식이 있었습니다.
암호 스위트 이름은 다음과 같았습니다.
TLS_RSA_WITH_AES_128_GCM_SHA256
흐름은 대략 이렇습니다.
1. 서버가 RSA 공개키가 든 인증서를 전송
2. 클라이언트가 premaster secret을 무작위 생성
3. 서버 RSA 공개키로 premaster secret을 암호화
4. 서버가 RSA 개인키로 복호화
5. 양쪽이 premaster secret으로 대칭키 생성
그림으로 보면 다음과 같습니다.
클라이언트:
premaster secret 생성
↓ 서버 RSA 공개키로 암호화
암호화된 premaster secret
------------------------> 서버
서버:
RSA 개인키로 복호화
↓
premaster secret 획득
이 방식에서는 실제 세션키 자체를 직접 암호화했다기보다,
세션키를 만드는 원료인 premaster secret을 RSA로 운반했습니다.
그래서 RSA key transport라고 부릅니다.
공격자가 과거 TLS 패킷을 저장해 두었다고 가정해보겠습니다.
이후 서버의 RSA 개인키를 탈취하면:
저장해 둔 암호화된 premaster secret
↓ 탈취한 RSA 개인키로 복호화
premaster secret
↓
과거 세션키 복원
↓
과거 통신 복호화
가 가능할 수 있습니다.
RSA PKCS#1 v1.5 복호화 오류의 차이를 이용하는 Bleichenbacher 계열 오라클 공격 등, 안전하게 구현하기 까다로운 문제가 있었습니다.
TLS 1.3은 RSA 키 운반 방식을 지원하지 않습니다.
RSA는 여전히 서버의 디지털 서명용 인증서로 사용할 수 있지만, 공유 비밀을 운반하는 RSA 키 교환은 사용하지 않습니다.
RSA 인증서 + ECDHE 키 합의
→ 가능
RSA 인증서 + RSA 키 운반
→ TLS 1.3에서는 불가능
2026년 7월 발표된 RFC 10015는 TLS 1.2에서도 RSA 키 교환을 공식적으로 폐기 대상으로 규정했습니다. 정적 DH도 함께 폐기하고, 정적 ECDH 역시 사용을 억제합니다.
RSA라는 이름 때문에 자주 혼동되는 부분입니다.
클라이언트가 서버 공개키로 비밀값 암호화
서버가 개인키로 복호화
목적:
비밀값 전달
서버가 개인키로 핸드셰이크에 서명
클라이언트가 공개키로 서명 검증
목적:
서버 인증
개인키 보유 증명
핸드셰이크 변조 방지
현대 TLS에서 RSA 인증서를 사용한다면 일반적으로 RSA-PSS 서명을 사용하고, 키 합의는 ECDHE로 진행합니다.
둘 다 EC, 즉 타원곡선을 사용하지만 목적이 다릅니다.
Elliptic Curve Digital Signature Algorithm
목적:
디지털 서명
서버 인증
Elliptic Curve Diffie-Hellman Ephemeral
목적:
공유 비밀 합의
세션키 재료 생성
예를 들어 다음 조합이 가능합니다.
ECDHE + RSA 서명
ECDHE + ECDSA 서명
ECDHE + Ed25519 서명
따라서 “ECC를 사용한다”는 말만으로는 키 합의인지 서명인지 알 수 없습니다.
TLS 1.2에서는 암호 스위트 이름에 많은 요소가 결합되어 있었습니다.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
뜻:
ECDHE → 키 합의
RSA → 인증·서명
AES_128_GCM → 데이터 암호화
SHA256 → PRF·핸드셰이크 관련 해시
TLS 1.3에서는 다음처럼 짧아졌습니다.
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS 1.3 암호 스위트는 주로 다음만 지정합니다.
대칭키 암호 방식
HKDF에 사용할 해시
다음 요소는 별도로 협상됩니다.
키 교환 그룹:
X25519
secp256r1
기타 지원 그룹
서명 방식:
RSA-PSS
ECDSA
Ed25519
기타 지원 방식
즉 TLS 1.3에서는 다음이 서로 분리되었습니다.
암호 스위트
키 교환 그룹
서명 알고리즘
TLS 1.3에서 자주 볼 수 있는 그룹은 다음과 같습니다.
Curve25519 기반의 ECDH 방식입니다.
용도: ECDHE 키 합의
특징: 빠르고 구현 실수를 줄이도록 설계
다른 이름으로 P-256이라고도 합니다.
용도: ECDHE 또는 ECDSA
특징: 널리 지원되며 호환성이 좋음
같은 P-256 곡선을 사용하더라도 용도에 따라 다릅니다.
P-256 ECDHE → 키 합의
P-256 ECDSA → 서명
타원곡선 대신 큰 정수 모듈러 연산을 사용하는 전통적인 유한체 Diffie-Hellman입니다.
ffdhe2048
ffdhe3072
등이 있습니다.
다만 현재 IETF 지침은 TLS 1.2의 오래된 유한체 DH 방식들을 더욱 엄격히 제한하는 방향입니다. TLS 1.3에서는 프로토콜상 안전한 명명 그룹을 사용할 수 있지만, 일반적인 웹 환경에서는 ECDHE, 특히 X25519나 P-256이 흔히 사용됩니다.
TLS에서 서버 개인키는 절대 클라이언트에게 보내지 않습니다.
서버가 보내는 것은 다음입니다.
인증서
인증서 안의 공개키
ECDHE 임시 공개키
개인키로 만든 서명값
서버에 남아 있는 것은 다음입니다.
인증서 개인키
ECDHE 임시 개인키
클라이언트는 공개키로 서명을 검증할 수 있지만, 공개키로 개인키를 계산할 수는 없어야 합니다.
디지털 서명을 흔히 다음과 같이 설명합니다.
개인키로 암호화
공개키로 복호화
입문 설명으로는 직관적이지만 정확하지는 않습니다.
특히 ECDSA나 EdDSA는 메시지를 개인키로 암호화했다가 공개키로 복호화하는 구조가 아닙니다.
정확하게는 다음과 같습니다.
서명 생성:
개인키 + 메시지 → 서명값
서명 검증:
공개키 + 메시지 + 서명값 → 유효 / 무효
검증 과정에서 원본 메시지가 서명으로부터 복원되는 것도 아닙니다.
RSA 서명 역시 현대 방식인 RSA-PSS에서는 단순한 “개인키 암호화”로 이해하면 패딩과 해시 구조를 놓치게 됩니다.
서버의 인증서 개인키가 유출되면 공격자는 해당 인증서가 유효한 동안 서버인 것처럼 서명할 수 있습니다.
가능한 위험은 다음과 같습니다.
가짜 서버 구성
중간자 공격 시도
서버 인증 위조
악성 프록시에서 핸드셰이크 서명
하지만 ECDHE를 정상적으로 사용했다면 서버 장기 개인키만으로 과거 TLS 세션을 복호화할 수는 없습니다.
대응은 일반적으로 다음과 같습니다.
1. 기존 인증서 폐기
2. 새 개인키 생성
3. 새 인증서 발급
4. 서버·로드밸런서·CDN에 교체
5. 유출 범위 조사
중요한 것은 기존 키를 재사용하지 않고 완전히 새로운 키 쌍을 만드는 것입니다.
실제 인프라에서는 애플리케이션 서버가 직접 TLS 개인키를 가지지 않을 수도 있습니다.
예를 들어:
브라우저
↓ HTTPS
CloudFront
↓ HTTPS
ALB
↓ HTTP 또는 HTTPS
ECS 애플리케이션
여기서 외부 사용자의 TLS 연결을 CloudFront가 종료한다면:
사용자 ↔ CloudFront
구간의 인증서 개인키는 CloudFront 또는 AWS 인증서 관리 체계에서 사용됩니다.
CloudFront가 다시 ALB와 HTTPS 연결한다면:
CloudFront ↔ ALB
이것은 별도의 TLS 세션입니다.
즉 한 요청에 TLS 연결이 여러 개 있을 수 있습니다.
TLS 세션 1:
브라우저 ↔ CloudFront
TLS 세션 2:
CloudFront ↔ ALB
TLS 세션 3:
ALB ↔ 백엔드
각 세션은 서로 다른 ECDHE 임시 키와 대칭키를 사용합니다.
[1] 클라이언트와 서버가 지원 알고리즘을 협상한다.
[2] 클라이언트와 서버가 ECDHE 임시 공개키를 교환한다.
[3] 양쪽은 각자의 임시 개인키와 상대 공개키를 이용해
동일한 공유 비밀을 계산한다.
[4] 서버가 인증서 체인을 전송한다.
[5] 클라이언트는 CA 체인, 도메인, 유효기간 등을 검증한다.
[6] 서버는 인증서 개인키로 핸드셰이크에 서명한다.
[7] 클라이언트는 인증서 공개키로 서명을 검증한다.
[8] 양쪽은 ECDHE 공유 비밀과 핸드셰이크 해시를
HKDF에 넣어 여러 대칭키와 IV를 만든다.
[9] Finished 메시지로 동일한 키와 핸드셰이크 상태를
공유하는지 최종 확인한다.
[10] 이후 HTTP 데이터는 AES-GCM 또는
ChaCha20-Poly1305 같은 대칭키 방식으로 암호화한다.
한 문장으로 압축하면 다음과 같습니다.
인증서의 장기 비대칭키는 서버의 신원을 증명하고, ECDHE 임시 비대칭키는 세션용 공유 비밀을 합의하며, 실제 데이터는 그 결과로 만든 대칭키로 암호화합니다.
그리고 현재 기준으로는 다음처럼 이해하면 가장 정확합니다.
현대적인 TLS 1.3:
서버 인증
→ RSA-PSS / ECDSA / EdDSA 서명
키 합의
→ ECDHE
데이터 암호화
→ AES-GCM / ChaCha20-Poly1305
과거의 RSA 키 운반
→ 사용하지 않음