1. 개요
https:// 를 쓸 때마다 TLS 핸드셰이크가 일어난다는 건 알지만, 그 안에서 “인증서” 랑 “암호화” 가 정확히 어떤 역할을 나눠 맡는지는 뭉뚱그려 아는 경우가 많다. 이번 편은 TLS 가 왜 대칭키와 비대칭키를 둘 다 쓰는지, 인증서는 정확히 뭘 보장하는지를 정리한다.
2. 핵심 내용
2-1. 대칭키만 쓰면 되는 거 아닌가
대칭키 암호화(AES 등)는 빠르다. 문제는 양쪽이 같은 키를 써야 하는데, 그 키를 어떻게 안전하게 처음 주고받을지다. 인터넷으로 그냥 평문으로 보내면 중간에서 누구나 가로챌 수 있다. 이걸 키 교환 문제라고 부른다.
2-2. 비대칭키로 키 교환 문제를 푼다
비대칭키(RSA, ECDHE 등)는 공개키로 암호화한 걸 대응하는 개인키로만 풀 수 있는 한 쌍의 키를 쓴다. 공개키는 이름 그대로 아무나 알아도 안전하다. 그래서 클라이언트가 서버의 공개키로 “이제부터 쓸 대칭키” 를 암호화해서 보내면, 서버만 자기 개인키로 그걸 풀어서 같은 대칭키를 얻는다. 이 과정을 도청해도 개인키가 없으면 대칭키를 복원할 수 없다.
문제는 비대칭키 연산이 대칭키보다 훨씬 느리다는 것이다. 그래서 TLS 는 딱 이 “키를 안전하게 주고받는” 순간에만 비대칭키를 쓰고, 그 뒤 실제 데이터를 주고받는 구간은 전부 대칭키로 암호화한다. 느린 연산은 한 번만, 빠른 연산은 계속. 이게 둘을 섞어 쓰는 이유다.
2-3. 그런데 공개키가 진짜 그 서버 것인지 어떻게 아나
여기서 인증서가 필요해진다. 공개키 교환 자체는 문제를 안 푼다. 중간자가 자기 공개키를 서버 것인 척 보내면(중간자 공격) 클라이언트는 속아서 중간자와 키를 교환하게 된다. 인증서는 “이 공개키는 진짜 example.com 것이다” 라는 걸 제3자가 서명해서 보증해주는 문서다. 이 제3자가 인증 기관(CA) 이고, 브라우저와 OS 는 신뢰할 수 있는 CA 목록을 미리 갖고 있다.
클라이언트는 서버가 보낸 인증서의 서명을 그 CA 의 공개키로 검증한다. 서명이 CA 의 개인키로 만들어진 게 맞다면, CA 가 “이 공개키는 이 도메인 것이 맞다” 고 확인했다는 뜻이니 신뢰한다. Let’s Encrypt 같은 무료 CA 는 이 과정을 자동화해서, 도메인 소유권만 확인하면(DNS 레코드나 HTTP 파일로) 인증서를 자동 발급해준다.
2-4. 핸드셰이크 순서로 정리
- ClientHello: 클라이언트가 지원하는 TLS 버전, 암호 스위트 목록을 보낸다.
- ServerHello + 인증서: 서버가 쓸 암호 스위트를 정하고, 자신의 공개키가 담긴 인증서를 보낸다.
- 인증서 검증: 클라이언트가 CA 서명을 확인하고, 도메인이 일치하는지 확인한다.
- 키 교환: 클라이언트와 서버가 (요즘은 ECDHE 방식으로) 대칭키 재료를 교환해서 양쪽이 각자 같은 세션 키를 계산해낸다.
- 이후 통신: 계산해낸 대칭키로 실제 데이터를 암호화해서 주고받는다.
TLS 1.3 은 이 왕복을 줄여서 1-RTT 로 핸드셰이크를 끝내고, 이전에 접속한 적 있는 서버라면 0-RTT 로도 재개할 수 있게 했다. 4편에서 다룬 QUIC 이 TLS 핸드셰이크와 전송 계층 핸드셰이크를 합친 것도 같은 맥락이다.
3. 마무리
요약
- 비대칭키는 느리지만 키 교환에 안전하고, 대칭키는 빠르지만 사전 공유가 필요하다. TLS 는 키 교환에만 비대칭키를, 실제 데이터 전송에는 대칭키를 쓴다.
- 인증서는 “이 공개키가 이 도메인 것이 맞다” 는 걸 CA 서명으로 보증하는 문서다. 이게 없으면 중간자가 자기 공개키를 서버 것인 척 속일 수 있다.
- TLS 1.3 은 핸드셰이크 왕복을 줄여 1-RTT, 재접속은 0-RTT 까지 단축했다.
다음은 6편: 로드밸런싱과 헬스체크 다.