(CS/컴퓨터공학) 대칭키 vs 비대칭키 SSL/TLS

14 November 2025 - 3 mins read time
Tags: CS

✨ 개요

HTTPS가 안전한 이유는 대칭키와 비대칭키의 장점을 동시에 쓰기 때문입니다.
요약하면, 비대칭키로 “상대가 진짜인지 확인하고, 안전하게 대칭키를 합의”한 뒤, 대칭키로 “빠르고 안전하게 대용량 데이터를 암호화”합니다.

1. 한 장 요약

👉 TLS는 비대칭키로 “대칭키를 안전하게 만들고”, 그 대칭키로 본문을 암호화합니다.

2 TLS 1.3 핸드셰이크(핵심 흐름)

TLS 1.3은 1-RTT(왕복 1회) 로 연결을 세우고, 앞으로의 통신을 보호할 세션 키를 합의합니다.

|--- ClientHello (지원 암호, ECDHE 공개키) ----->|
|<-- ServerHello (선택 암호, ECDHE 공개키) ------|
|<-- Certificate (서버 인증서/체인) -------------|
|<-- CertificateVerify (서버가 개인키로 서명) ---|
|<-- Finished (서버 쪽 비밀 확인) ---------------|
|--- Finished (클라이언트 쪽 비밀 확인) ------->|
|========== 이후: 대칭키로 암호화된 데이터 =========>

• ECDHE(Ephemeral Diffie-Hellman) : 매 연결마다 새 난수 쌍 → Perfect Forward Secrecy(PFS)
• Certificate / CertificateVerify : 서버가 인증서의 개인키로 자신임을 증명
• HKDF : 양측 ECDHE 비밀로부터 서브 키(서버/클라 송수신 키)를 파생
• 이후 애플리케이션 데이터는 AES-GCM 또는 ChaCha20-Poly1305(둘 다 AEAD) 로 암호화

TLS 1.2도 개념은 유사하지만, 1.3이 더 단순/안전/빠릅니다(취약 스위트 제거, 0-RTT 재개 등).

3 왜 안전한가? (원리별 분해)

1) 기밀성(Confidentiality) - 본문은 대칭키(AES-GCM/ChaCha20-Poly1305) 로 암호화 → 중간자도 내용 해독 불가

2) 무결성/인증(Integrity & Authentication) - AEAD가 인증 태그로 변경 탐지 - 서버는 공개키 인증서 + 개인키 서명으로 진짜 서버임을 증명(클라가 CA 체인으로 검증)

3) 키 합의의 안전성(Key Agreement) - ECDHE로 세션키 합의: 패킷을 훔쳐도 수학적으로 키 추정 불가 - PFS: 나중에 서버 개인키가 유출되어도 과거 트래픽은 해독 불가(세션마다 키가 다름)

4) 재연 공격 방지/신선도(Freshness) - 난수, 시퀀스, nonce, Finished 메시지 검증으로 세션 끼워 넣기/재전송 저항

5) 신뢰 사슬(Trust Chain) - 인증서는 CA → 중간CA → 서버 체인으로 서명됨 - 클라이언트는 OS/브라우저의 신뢰 루트로 이 사슬을 검증

4. TLS 1.3 vs 1.2 핵심 차이(요점)

• 낮은 왕복: 1.3은 1-RTT, 세션 재개 시 0-RTT(주의: 재전송/재연 취약성 고려)
• 안전한 디폴트: ECDHE+AEAD 강제, 취약 스위트와 RSA 키교환 제거
• 성능: 짧은 핸드셰이크 + 현대 암호 최적화

5. 실무 체크리스트 (운영·앱/백엔드)

서버/인프라

• TLS 1.3 활성화 + 강한 스위트만: TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256 등
• ECDHE(ECDH P-256/Curve25519) 필수, RSA 키교환 금지
• HSTS 적용(HTTPS 강제), OCSP Stapling으로 인증서 상태 빠르게 전파
• 인증서는 신뢰 가능한 CA + 자동 갱신(Let’s Encrypt + ACME)

애플리케이션(모바일/웹)

• 인증서 검증 실패 시 연결 거부(예외 삼키지 않기)
• 민감 앱은 Certificate Pinning(공개키/핀) 고려(운영 자동화 계획과 함께)
• API 호출은 HTTP/2/3(QUIC) 우선 → 지연 감소, 멀티플렉싱
• 시간 민감 서비스는 0-RTT 재개 사용 시 재연 공격 영향도 평가

관측/보안

• TLS 버전/스위트/핸드셰이크 실패율 대시보드화
• 취약 설정(예: TLS 1.0/1.1, CBC, RC4) 폐기 정책 수립
• 키/인증서 권한 분리 및 비밀 관리(전용 KMS/HSM)

6. 오해 바로잡기

• “HTTPS면 전부 비대칭으로 암호화한다” → ❌
  • 실제 데이터 암호화는 대칭키가 담당. 비대칭은 인증·키합의 용도.
• “서버 개인키가 털리면 과거 트래픽도 다 해독” → ❌ (1.3 + ECDHE PFS면 과거는 보호)
• “자체 서명 인증서도 괜찮다” → ❌ (테스트용만. 실서비스는 신뢰 사슬 필요)

7. 비대칭키로 신원 확인과 대칭키 합의 →

• 합의된 대칭키(AES-GCM/ChaCha20-Poly1305) 로 빠르고 안전한 본문 암호화 →
• TLS 1.3은 이를 더 짧고 강하게 수행(ECDHE, AEAD, PFS). 결과적으로 HTTPS는 기밀성·무결성·인증을 모두 만족합니다.

Related Posts