학습 목표
TLS 1.3 핸드셰이크의 주요 메시지 흐름을 설명할 수 있다.
Cipher suite가 key exchange·인증·암호화·해시로 구성됨을 설명할 수 있다.
Forward secrecy가 왜 중요한지 설명할 수 있다.
mTLS가 서비스 간 신원 확인에 쓰이는 방식을 설명할 수 있다.
문제 상황
openssl s_client출력에TLS_AES_128_GCM_SHA256만 보이고 의미를 모른다- 인증서는 갱신했는데 구형 클라이언트가 handshake failure
- cipher·TLS 버전 호환 문제인지 모른다
- 내부 gRPC는 "TLS 켜면 된다"는데 서버만 검증하면 피어 스푸핑 위험
- 서버 private key 유출 시 과거 트래픽도 복호화될까?
- PFS 유무에 달려 있다
보안 원칙(least privilege, defense in depth)을 봤다. TLS는 전송 계층에서 기밀성·무결성·서버(때로 클라이언트) 인증을 제공한다. Network 편의 HTTPS 개요를 구현·운영 관점으로 깊게 본다.
1. TLS가 하는 일
| 목표 | 메커니즘 |
|---|---|
| 기밀성 | 대칭키 암호(AES-GCM 등)로 애플리케이션 데이터 암호화 |
| 무결성 | AEAD — 변조 시 복호 실패 |
| 인증 | X.509 인증서 + 공개키 서명으로 서버(mTLS 시 클라이언트) 신원 |
| 협상 | 핸드셰이크로 버전·cipher·키 합의 |
- TLS는 HTTP 위가 아니라 TCP(또는 QUIC) 위에서 동작
- 애플리케이션은 평문을 TLS 레이어에 넘기고, wire에는 암호문만 나간다
2. TLS 1.3 핸드셰이크 (개요)
TLS 1.3은 1.2보다 라운드 수 감소, 취약한 cipher 제거가 핵심이다.
Client Server
| ClientHello (supported groups, ciphers) |
|---------------------------------------->|
| ServerHello + key share |
| Certificate* + CertificateVerify*
| Finished |
|<----------------------------------------|
| Finished |
|---------------------------------------->|
|======== Application Data (encrypted) ===|- ClientHello — 지원 TLS 버전, cipher suites, key share(ECDHE 등)
- ServerHello — 선택된 파라미터, 서버 key share
- Certificate — 서버(및 mTLS 시 클라이언트) 체인
- Finished — 핸드셰이크 MAC, 키 확인
- 1-RTT 핸드셰이크(세션 재개·0-RTT는 별도 주제)
*인증서는 설정에 따라 생략 가능하지만 HTTPS에서는 필수
인증서 검증 (클라이언트 측)
- 체인이 신뢰 CA까지 연결되는가
- 호스트명(SAN)이 접속 도메인과 일치하는가
- 유효 기간·폐기(CRL/OCSP) 확인
- certificate pinning — 모바일·내부 API에서 추가 고정 (운영 부담↑)
3. Cipher suite
TLS 1.3에서는 cipher suite 이름이 대칭 암호 + 해시 중심으로 단순화되었다.
| 구성 요소 | 역할 | 예 |
|---|---|---|
| Key exchange | 세션 키 합의 | ECDHE (ephemeral) |
| Authentication | 인증서 서명 알고리즘 | RSA, ECDSA, Ed25519 |
| AEAD cipher | 암호화+무결성 | AES-128-GCM, ChaCha20-Poly1305 |
| Hash / HKDF | 키 유도 | SHA-256 |
- 예:
TLS_AES_128_GCM_SHA256 - ECDHE — ephemeral Diffie-Hellman → forward secrecy
- TLS 1.3에서 제거·비권장: RSA key transport only, CBC 모드, RC4, SSLv3/TLS1.0/1.1
Forward secrecy (PFS)
- 장기 서버 private key가 나중에 유출돼도, 과거 세션 키로는 복호 불가 (ECDHE 사용 시)
- 세션 키는 ephemeral — 핸드셰이크마다 새로 생성
운영
openssl s_client -connect example.com:443 -tls1_3
nmap --script ssl-enum-ciphers -p 443 example.com- 서버:
ssl_protocols TLSv1.2 TLSv1.3;— 구형 클라이언트와 트레이드오프 - Mozilla SSL Configuration Generator 등으로 안전한 프로파일 적용
4. mTLS (Mutual TLS)
일반 HTTPS는 클라이언트가 서버 인증서를 검증한다. mTLS는 서버도 클라이언트 인증서를 요구한다.
Service A ←—— TLS + client cert ——→ Service B
both verify peer certificate| 사용처 | 이유 |
|---|---|
| 서비스 메시 | Pod/서비스 identity, east-west 트래픽 |
| 내부 API | 공개 인터넷 없이 강한 피어 인증 |
| Zero Trust | "네트워크 안이면 안전" 대체 |
- 인증서 발급: 사내 CA, SPIFFE/SPIRE, 클라우드 workload identity
- Istio/Linkerd 등 메시가 mTLS를 자동 적용하는 경우 많음
- 클라이언트 cert 로테이션·만료 모니터링 필수
5. 흔한 실패와 방어
| 증상 | 원인 | 조치 |
|---|---|---|
certificate has expired |
만료 | 자동 갱신(Let's Encrypt, cert-manager) |
hostname mismatch |
SAN 불일치 | 올바른 도메인·와일드카드 |
handshake failure |
cipher/버전 불일치 | 서버 cipher 목록·클라이언트 업데이트 |
unknown ca |
사설 CA 미신뢰 | trust store 배포 |
- 보안 원칙과 연결: 최소 권한(필요 cipher만), fail secure(검증 실패 시 연결 거부), defense in depth(TLS + 앱 레벨 인증)
6. 정리
- TLS 1.3은 빠르고 안전한 기본값 — 구형 프로토콜·cipher 비활성화
- Cipher suite는 키 교환·AEAD·해시의 조합 — ECDHE로 PFS
- mTLS는 양방향 인증 — 내부 서비스·메시에서 핵심
- 인증서 수명·cipher 정책은 운영 이슈다
다음에 다룰 것
- 인증 기초
- 세션, 쿠키, credential 저장, 해싱
해당 내용은 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 및 OWASP Transport Layer Protection 가이드를 기반으로 합니다.