HTTPS가 대칭키와 비대칭키를 혼합해서 사용하는 이유

2024년 4월 22일

HTTPS의 TLS Handshake가 왜 안전한지, 어떤 원리로 동작하는지 이해하기 위해선 대칭키, 비대칭키에 대한 정리가 필요하다. 그리고 왜 https를 사용하려면 인증서가 필요할까? lets encrypt같은걸 쓰는 이유도 정리한다.

대칭키

대칭키는 암호화와 복호화에 동일한 키를 사용하는 방식이다. 자물쇠와 열쇠가 하나인 것처럼, 송신자와 수신자가 같은 키를 공유하고 있어야 한다.

문제는 키를 상대방에게 전달해야 하는 순간이 반드시 온다는 것이다. 인터넷처럼 열린 네트워크에서 이 전달 과정은 곧 취약점이 된다. 키가 중간에 탈취되면 암호화 자체가 의미를 잃는다.

비대칭키

비대칭키는 수학적으로 연결된 공개키(Public Key)와 개인키(Private Key) 한 쌍을 사용한다. 공개키로 암호화한 데이터는 반드시 대응하는 개인키로만 복호화할 수 있다.

공개키를 누구에게나 공개해도 무방하다. 개인키는 서버만 보관하기 때문에 키 전달 과정 자체가 발생하지 않는다. 중간에 공개키를 가로채도, 그것으로는 암호를 풀 수 없다.

HTTPS는 두 방식의 장점만 취한다

HTTPS(정확히는 TLS)가 취한 해답은 명확하다. 비대칭키는 키를 나눠가질 때만 사용하고, 실제 데이터 통신은 대칭키로 처리한다.

연결이 수립되는 TLS Handshake 과정을 따라가면 이 조합이 어떻게 동작하는지 이해할 수 있다.

  1. 서버가 공개키를 클라이언트에 전달한다. 서버는 인증서(Certificate)와 함께 공개키를 내려준다.
  2. 클라이언트가 대칭키 재료를 공개키로 암호화해 서버에 전송한다. 서버의 개인키 없이는 누구도 이 내용을 열 수 없다.
  3. 서버가 개인키로 복호화해 대칭키 재료를 꺼낸다. 이 시점에서 클라이언트와 서버 양쪽 모두 동일한 재료를 갖게 된다.
  4. 양쪽이 그 재료로 동일한 대칭키를 생성하고, 이후 모든 통신을 이 키로 암호화한다.

비대칭키는 딱 한 번, 대칭키를 안전하게 나눠갖는 순간에만 쓰인다. 무거운 연산은 핸드셰이크 단계에 한 번만 집중되고, 이후 실제 데이터를 주고받는 구간은 빠른 대칭키가 담당한다.

인증서가 필요하다

서버가 공개키를 보내줄 때, 클라이언트는 그것이 진짜 서버의 공개키인지 어떻게 확인할 수 있을까? 이를 막는 것이 인증서(Certificate) 다. 신뢰할 수 있는 제3자인 CA(Certificate Authority) 가 "이 공개키는 이 도메인의 것이 맞다"라고 서명해준 문서다. 브라우저는 OS에 내장된 신뢰 CA 목록을 보유하고 있어, 서명의 유효성을 스스로 검증할 수 있다. 공격자가 가짜 인증서를 만들어도 CA의 유효한 서명이 없으면 브라우저가 경고를 표시한다.