네트워크 미니랩 5/5 · HTTPS 자물쇠는 어떻게 잠길까?

https의 자물쇠 뒤에는 이상한 문제가 하나 숨어 있습니다.

암호로 잠그려면 열쇠를 나눠 가져야 하는데, 열쇠를 보내는 길 자체가 도청당하고 있다면?

TLS의 답은 기발합니다 — 비밀을 보내지 않고, 양쪽이 같은 열쇠 재료를 각자 계산합니다. 이 데모는 그 과정 하나만 보여줍니다.

열쇠를 보내지 않고 나눠 갖는 방법

양쪽은 비밀 조각(a, b)을 집에 두고, 공개 조각(A, B)만 교환합니다.

내 컴퓨터: 비밀 a + 공개 B → 공유 비밀 계산
서버: 비밀 b + 공개 A → 같은 공유 비밀 계산
도청자: 공개 A + 공개 B → 아무것도 안 나옴 ❌

비밀과 완성된 열쇠는 회선을 지나가지 않습니다. 실제 TLS 1.3은 이 공유 비밀에서 HKDF로 방향과 용도별 여러 트래픽 키를 만듭니다. 데모는 디피-헬만 키 교환과 키 유도 과정을 하나의 "열쇠 재료" 비유로 줄였습니다.

신분증도 확인합니다

가짜 서버와 완벽하게 암호화된 대화를 해봤자 소용없습니다. 그래서 내 컴퓨터는 신뢰할 수 있는 인증서 사슬, 접속한 호스트 이름과 유효 기간을 확인합니다. 서버의 CertificateVerify 서명으로 인증서 개인키의 실제 소유도 검증하고, 양쪽의 Finished 확인값까지 맞아야 핸드셰이크가 끝납니다.

이 과정은 TCP 연결이 만들어진 직후 진행됩니다. 걸리는 시간은 네트워크 왕복 시간과 인증서 검증 환경에 따라 달라집니다.

데모에서 해볼 일

보안 연결 시작을 누르고, 여섯 장면의 제목만 따라갑니다.
각 장면에서 도청자 칸에 무엇이 보이는지 확인합니다.
자세한 숫자가 궁금할 때만 교환한 기술 값 보기를 펼칩니다.
자물쇠가 잠긴 뒤 진짜 데이터가 암호문으로 지나가는 것을 봅니다.

자물쇠가 안 잠길 때 읽는 법

브라우저의 TLS 오류 화면은 무섭게 생겼지만, 실제로 자주 나오는 원인은 몇 가지로 정해져 있습니다. 앞의 두 단계 중 어디서 걸렸는지로 나누면 읽기 쉽습니다.

이름이 안 맞음 — 인증서에 적힌 도메인과 실제 접속한 주소가 다릅니다. www를 붙였는지 여부나, 인증서를 발급받지 않은 하위 도메인에서 흔합니다.
기간이 지남 — 자동 갱신이 조용히 멈춘 경우입니다. 서버는 잘 도는데 어느 날 갑자기 전체 접속이 막히는 전형적인 모습입니다.
중간 인증서 누락 — 사슬의 가운데 고리를 서버가 함께 보내지 않은 경우입니다. 브라우저에서는 되는데 다른 도구나 서버 간 호출에서만 실패하는, 가장 헷갈리는 형태로 나타납니다.

세 번째가 특히 성가신 이유는 어떤 클라이언트는 성공하기 때문입니다. 일부 브라우저는 빠진 고리를 알아서 찾아 보완하지만, 그렇지 않은 도구는 그대로 실패합니다.

직접 확인하기

서버가 실제로 무엇을 보내는지는 명령 하나로 볼 수 있습니다.

# 인증서 사슬과 협상된 TLS 버전 확인
openssl s_client -connect example.com:443 -servername example.com </dev/null

# 유효 기간만 빠르게 확인
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject

출력의 Certificate chain에 서버 인증서만 있고 중간 인증서가 없다면 위의 세 번째 경우입니다. Verify return code: 0 (ok)가 나오면 검증까지 통과한 것입니다. -servername을 빼면 다른 인증서가 돌아올 수 있는데, 한 IP가 여러 도메인을 서비스할 때 어떤 인증서를 줄지 이 이름으로 고르기 때문입니다.

두 번째 접속은 더 빠릅니다

TLS 1.3의 핸드셰이크는 왕복 한 번(1-RTT)으로 끝납니다. 그리고 한 번 연결했던 서버에는 이전 접속에서 받아둔 재개용 정보를 써서, 첫 요청을 핸드셰이크와 함께 보내는 0-RTT가 가능합니다.

다만 0-RTT로 보낸 데이터는 공격자가 가로챘다가 나중에 그대로 다시 보낼 수 있습니다. 그래서 이 방식은 여러 번 실행돼도 결과가 같은 요청에만 쓰는 것이 원칙입니다. "조회는 괜찮지만 결제는 안 된다"고 이해하면 쉽습니다.

요약 세 가지

비밀과 완성된 열쇠는 전송하지 않습니다. 공개 조각으로 같은 공유 비밀을 계산합니다.
인증서와 CertificateVerify 서명으로 서버 신원과 개인키 소유를 확인합니다.
그 후 TLS 안의 대화 내용은 암호문으로 이동합니다.

참고

a·b·A·B는 디피-헬만 원리의 비유적 단순화입니다. 실제 TLS 1.3은 여러 키 교환 방식을 지원하며, 공유 비밀과 HKDF로 용도별 열쇠를 만듭니다. 인증서 사슬, CertificateVerify와 양쪽 Finished도 검증합니다. 이 메시지가 포장되어 이동하는 모습은 네트워크 7계층 랩 에서 볼 수 있습니다.

TLS는 대화 내용을 보호하지만 IP 주소, 통신 시각과 데이터 크기 같은 메타데이터까지 모두 숨기는 것은 아닙니다.

자료: RFC 9846 (TLS 1.3) — Protocol Overview, RFC 9846 — 0-RTT 데이터의 재전송 위험