HTTPS는 무엇을 지키는가 — TLS 핸드셰이크와 공개키 암호

면접에서 "말로 설명한다"는 가정으로 작성. 답을 외우기보다 "왜"와 "트레이드오프"를 설명할 수 있는 것이 목표입니다.

5-1. 대칭키 vs 비대칭키

구분	대칭키	비대칭키
키 구성	잠금·해제가 같은 하나	공개키 + 개인키 한 쌍
대표 알고리즘	AES	RSA, ECC, (DH는 키교환 전용)
속도	빠름	느림(연산 무거움)
문제점	키를 어떻게 안전하게 전달?(키 분배 문제)	연산 비용

비대칭키의 핵심 성질

공개키로 암호화한 것은 오직 짝이 되는 개인키로만 복호화 (→ 비밀 전달)
개인키로 서명한 것은 오직 짝이 되는 공개키로만 검증 (→ 신원 증명)
공개키로는 개인키를 역산 불가 (소인수분해·이산로그의 어려움)

그래서 공개키는 온 세상에 공개해도 안전합니다. 암호화 방향(공개키 잠금 → 개인키 해제)과 서명 방향(개인키 잠금 → 공개키 해제)을 구별하는 것이 핵심.

왜 둘을 섞나 (하이브리드)

비대칭은 키 분배 문제를 풀지만 느리고, 대칭은 빠르지만 키 전달이 문제. 그래서 키 교환은 비대칭으로, 대량 데이터는 대칭으로 처리해 양쪽 장점만 취합니다.

5-2. TLS 핸드셰이크 흐름

클라이언트                                서버
  │ ── ClientHello ───────────────────▶ │  지원 암호 스위트 · 랜덤값
  │ ◀── ServerHello + 인증서 ─────────── │  선택 암호 스위트 · 공개키
  │ (인증서 검증: CA 체인 확인)            │
  │ ── 키 교환 ───────────────────────▶ │
  │ (양쪽 동일한 대칭 세션 키 확립)         │
  │ ◀═══ 이후 데이터는 대칭키로 암호화 ═══▶ │

5-3. 인증서 검증 — "이 공개키가 진짜 그 서버 것인가?"

서버가 보낸 공개키가 사칭이 아닌지를 **CA(인증 기관)**의 디지털 서명으로 확인합니다.

발급 시 (CA가 서명)

인증서 내용(도메인·서버 공개키·만료일)을 해시 → 지문
그 해시를 CA 개인키로 암호화 → 디지털 서명. 인증서에 첨부

검증 시 (브라우저가 확인)

받은 인증서 내용을 직접 해시 → 해시A
첨부된 서명을 CA 공개키로 복호화 → 해시B
해시A == 해시B이면: ① 서명이 CA 개인키로 만들어졌고(공개키로 풀렸으니) ② 내용이 위조되지 않음(해시 일치) 동시 증명

CA 공개키는 어떻게 믿나?

브라우저·OS에 루트 CA 공개키가 미리 내장(trust anchor). 실제로는 루트 CA → 중간 CA → 서버 인증서로 이어지는 체인을 순서대로 검증해 루트에 닿으면 신뢰.

검증 실패 시나리오

만료된 인증서, 도메인 불일치, 자체 서명(self-signed), 신뢰할 수 없는 CA → 브라우저 경고. 중간자 공격(MITM)을 막는 것이 이 검증의 목적.

5-4. 키 교환 — 대칭키 확립

방식 A — RSA 키 교환 (옛 방식)

클라이언트가 pre-master secret(랜덤 비밀) 생성
이를 서버 공개키로 암호화해 전송
서버가 개인키로 복호화해 같은 값 획득 (공개키로 잠근 건 개인키로만 풀림 → 도청자는 못 품)
양쪽이 pre-master secret + 두 랜덤값을 동일 함수에 넣어 master secret → 세션 키 유도

약점: 서버 개인키가 나중에 유출되면, 녹화해둔 과거 트래픽을 전부 복호화 가능 → forward secrecy 없음.

방식 B — Diffie-Hellman 키 교환 (현대, ECDHE)

키를 주고받지 않고, 양쪽이 각자 비밀을 갖고 공개값만 교환해 같은 값을 따로 계산.

공개 파라미터: g(생성자), p(큰 소수)
클라이언트: 비밀 a → 공개값 A = g^a mod p 전송
서버:       비밀 b → 공개값 B = g^b mod p 전송
클라이언트: B^a = g^(ab) mod p
서버:       A^b = g^(ab) mod p   → 양쪽 동일!

g는 생성자(generator): 공개된 약속 값. g^1, g^2, ...를 mod p로 돌리면 1~(p-1)을 골고루 생성 → 결과가 예측 불가능하게 흩어짐
키 g^(ab)는 네트워크를 한 번도 건너가지 않음. 도청자는 g, A, B를 봐도 a·b를 모르면 계산 불가(이산 로그 문제)
a, b는 세션이 끝나면 버려지는 임시값(ECDHE의 E = ephemeral) → 장기 개인키가 털려도 과거 세션 복원 불가 = forward secrecy

인증서 공개키는 어디 쓰나 (DH 방식)

대칭키 암호화에 직접 쓰이지 않고, 서버가 보내는 DH 공개값에 서명하는 데 사용. DH 자체는 MITM에 취약하므로 "이 공개값이 진짜 서버 것"임을 인증서로 보증.

인증서 + 서명 → 신원 증명
디피-헬만 교환 → 대칭키 합의

5-5. 공개키 암호의 수학적 토대

두 방식 모두 "정방향은 쉽고 역방향은 사실상 불가능한" 일방향 함수에 기반.

구분	디피-헬만	RSA
어려움의 출처	이산 로그(`g^a mod p`에서 a 역산)	소인수분해(n을 p×q로 분해)
용도	키 교환 전용	암호화 + 서명

RSA 키 생성 (작은 예시)

두 소수 p=61, q=53 선택
n = p×q = 3233 (공개)
φ(n) = (p-1)(q-1) = 60×52 = 3120 (비밀 — p,q를 알아야 계산 가능)
φ(n)과 서로소인 공개 지수 e=17 선택
e×d ≡ 1 (mod φ(n))인 개인 지수 d=2753 계산
공개키 (e,n) / 개인키 (d,n)

암호화 C = M^e mod n, 복호화 M = C^d mod n. (M^e)^d ≡ M (mod n)이 성립하게 e·d를 짝지었기에 e로 잠근 건 d로만 풀림. d를 구하려면 φ(n)이, φ(n)을 구하려면 n의 소인수분해가 필요한데 그게 불가능 → 공개키만으로 개인키 도출 불가.

면접 멘트: "HTTPS는 비대칭으로 대칭키를 안전하게 교환한 뒤 본 통신은 빠른 대칭키로 합니다. 서버 인증서는 CA가 개인키로 서명해주고, 브라우저는 내장된 CA 공개키로 서명을 검증해 그 안의 서버 공개키를 신뢰합니다. 현대 TLS는 ECDHE로 키를 교환해, 임시 키를 쓰므로 장기 개인키가 유출돼도 과거 트래픽이 안전한 forward secrecy를 제공합니다."