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

성능과 보안을 동시에 확보하기 위해 HTTPS가 두 가지 암호화 방식을 어떻게 조합하는지 정리한다.

2024년 4월 22일

HTTPS를 단순히 "보안 연결"이라고 알고 있어도 개발하는 데 지장은 없다. 하지만 왜 안전한지, 어떤 원리로 동작하는지 이해하면 보안 이슈를 마주쳤을 때 훨씬 빠르게 판단할 수 있다.

핵심은 두 가지 암호화 방식을 적재적소에 조합해서 쓴다는 것이다.

1. 대칭키: 빠르지만 키 전달이 문제다

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

연산이 단순하고 빠르다는 점에서 대용량 데이터를 실시간으로 주고받는 상황에 적합하다. 문제는 키를 상대방에게 전달해야 하는 순간이 반드시 온다는 것이다. 인터넷처럼 열린 네트워크에서 이 전달 과정은 곧 취약점이 된다. 키가 중간에 탈취되면 암호화 자체가 의미를 잃는다.

대칭키의 딜레마를 한 문장으로 요약하면, 안전하게 키를 나눠가질 방법이 없다는 것이다.

2. 비대칭키: 안전하지만 느리다

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

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

다만 소인수 분해나 타원 곡선 같은 복잡한 수학 연산에 기반하기 때문에 대칭키보다 수십 배 느리고 CPU를 많이 소모한다. 모든 통신을 이 방식으로 처리하면 서버가 감당하기 어렵다.

3. HTTPS: 두 방식의 장점만 취한다

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

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

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

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

4. 인증서는 왜 필요한가

한 가지 허점이 남는다. 서버가 공개키를 보내줄 때, 클라이언트는 그것이 진짜 서버의 공개키인지 어떻게 확인할 수 있을까?

공격자가 중간에서 자신의 공개키를 대신 전달하면(중간자 공격, MITM), 클라이언트는 속고 있는지조차 알 수 없다.

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

마무리

HTTPS가 느리다는 편견이 있지만, 실제로 무거운 비대칭키 연산은 연결 초반 핸드셰이크 한 번에 집중된다. 이후 데이터를 주고받는 구간은 가벼운 대칭키를 사용하기 때문에 성능 부담은 크지 않다.

결국 HTTPS의 설계는 비대칭키로 안전하게 열쇠를 나눠갖고, 이후엔 그 열쇠로 빠르게 통신한다는 원칙 하나로 요약된다. 두 방식 모두 단독으로는 한계가 있지만, 각자의 강점이 필요한 순간에만 투입함으로써 성능과 보안을 동시에 확보하는 구조다.