HTTP vs HTTPS — TLS 핸드셰이크
평문 HTTP를 도청자가 읽는 장면에서 시작해, TCP 3-way와 TLS 1.3 1-RTT 핸드셰이크를 거쳐 같은 요청이 암호문으로 바뀌는 것까지 시퀀스로 실행한다.
도청자: 읽을 수 있는 것 없음
단계 목록 · 키보드 ←/→ 이동, Space 재생
TLS는 느린 비대칭 암호로 '신원 확인과 키 합의'만 하고, 실제 데이터는 빠른 대칭 세션키로 나른다 — 인증서가 신원을, 디피–헬만이 키를 맡는다.
왜 헷갈리는가
"인증서로 데이터를 암호화한다"가 가장 흔한 오해다. 인증서(비대칭)는 서버가 진짜임을 증명할 뿐이고, 본문을 잠그는 것은 핸드셰이크에서 합의한 대칭 세션키다. 둘의 역할을 섞으면 mTLS, 인증서 핀닝, 세션 재개 같은 주제가 전부 헷갈린다.
애니메이션이 보여주는 것
평문 HTTP에서는 공용 와이파이의 누구든 비밀번호를 그대로 읽는다 — 첫 장면이 그것이다. TCP 연결(3-way) 위에 TLS 1.3 핸드셰이크가 얹힌다.
핵심은 ClientHello와 ServerHello에 실린 '키 셰어'다. 양쪽은 (타원곡선) 디피–헬만 공개값만 주고받고, 같은 세션키를 각자 계산한다 — 키 자체는 선을 타지 않으므로 도청자는 공개값을 봐도 키를 얻지 못한다. 이후 인증서부터는 이미 암호화되어 흐른다. TLS 1.3은 이 전부가 1왕복(1-RTT)이다.
버전이 갈라 놓는 것
TLS 1.2와 1.3의 차이는 실무 성능과 보안 양쪽에 닿는다.
- 왕복 수: 1.2는 핸드셰이크에 2-RTT, 1.3은 1-RTT — 모바일처럼 지연 큰 환경에서 체감된다. 1.3의 0-RTT 재개는 재방문 요청을 핸드셰이크와 함께 싣는다(재전송 공격 고려 필요).
- 전방 비밀성: 1.3은 임시(ephemeral) 디피–헬만만 허용 — 서버 개인키가 나중에 유출돼도 과거 트래픽은 못 푼다. 1.2의 RSA 키 교환은 이것이 없어 퇴출됐다.
- 인증서 검증: 브라우저는 서버 인증서를 중간 CA를 거쳐 신뢰 저장소의 루트 CA까지 잇는다. 이 사슬이 끊기면 그 유명한 경고 화면이다.
- mTLS: 서버뿐 아니라 클라이언트도 인증서를 내는 상호 인증 — 서비스 메시(Istio)가 팟 사이에 자동으로 까는 것이 바로 이것이다.
왜 비대칭+대칭 이중 구조인가
비대칭 연산은 대칭보다 수천 배 느리다. 모든 패킷을 RSA로 잠그면 서버가 견디지 못한다. 그래서 비싼 연산(신원 증명, 키 합의)은 연결당 한 번만 하고, 이후는 AES-GCM 같은 대칭 암호가 하드웨어 가속(AES-NI)으로 나른다 — 'HTTPS는 느리다'가 옛말이 된 이유다.
기억할 것
- 인증서 = 신원 증명(비대칭), 세션키 = 본문 암호화(대칭). 역할이 다르다.
- 세션키는 선을 타지 않는다 — 디피–헬만 공개값으로 양쪽이 각자 계산한다.
- TLS 1.3은 1-RTT, 전방 비밀성 기본 — 특별한 이유 없으면 1.3이다.
- 핸드셰이크 후 도청자가 보는 것은 암호문뿐이다. 단, SNI·IP 같은 메타데이터는 남는다.