백엔드 개발자로서 HTTPS가 안전하다는 것은 누구나 안다. 하지만 "HTTPS 통신 중 서버의 개인키(Private Key)가 탈취되면 과거의 데이터는 안전한가?"라는 질문을 받는다면 자신 있게 대답할 수 있을까?
오늘은 단순히 HTTPS의 흐름을 넘어, RSA와 Diffie-Hellman(ECDHE)의 결정적 차이, 완전 순방향 비밀성(PFS)의 원리에 대해 정리해 본다.
1. 키 교환의 두 가지 경우: RSA vs Diffie-Hellman
HTTPS 핸드쉐이크의 핵심은 "데이터를 암호화할 대칭키를 어떻게 안전하게 나눠가질 것인가?"이다. 여기엔 크게 두 가지 방식이 있다.
RSA
RSA는 클라이언트가 직접 키를 만들어 교환한다. 클라이언트가 PMS(Pre-Master Secret)를 생성한 뒤, 서버의 공개키로 암호화해서 전송한다. (참고: PMS는 48바이트로, TLS 버전정보 2바이트와 난수 46바이트로 구성된다.)

Diffie-Hellman(ECDHE)
Diffie-Hellman(특히 Ephemeral 버전인 ECDHE)은 키를 배달하지 않고, 서로 계산하여 유도해낸다. 서로 공개된 파라미터(g, p)를 교환한 뒤, 각자 비밀리에 만든 난수(a, b)를 활용해 결과적으로 동일한 PMS를 생성해낸다.

두 방식 모두 결과적으로 PMS를 만들어내고, 이를 바탕으로 실제 통신에 사용할 PM(Master Secret)을 만들고 이를 해싱해서 사용한다는 점은 같다.
2. 서버 개인키가 털리면 과거 데이터도 털릴까?
RSA
RSA는 과거 데이터까지 전부 털린다. RSA 방식은 치명적인 약점이 있다. 패킷 안에 들어있는 PMS가 서버의 공개키로 암호화되어 전송되기 때문이다. 만약 해커가 패킷을 전부 캡해 둔 상태에서, 나중에라도 서버의 개인키를 탈취하는 데 성공한다면 해커는 개인키로 과거의 패킷을 복호화하여 PMS를 알아낼 수 있고, 이를 통해 모든 대화 내용을 복구할 수 있다.
Diffie-Hellman(ECDHE)
Diffie-Hellman의 경우, 과거 데이터는 안전하다. 이를 완전 순방향 비밀성(PFS)이라고도 한다. 이유는 단순하다. 서버의 개인키는 오직 "이 파라미터 내가 보낸 거 맞아"라고 인증하는 데만 쓰인다. 실제로 암호화 키(PMS)를 만든 파라미터인 난수는 통신이 끝나자마자 메모리에서 삭제된다. 따라서 해커가 나중에 서버 개인키를 훔쳐와도, 이미 사라진 난수를 복구할 수 없어 과거 데이터를 풀 수 없다.
이렇게만 표현하면, "중간에 해커가 파라미터를 다 전달하는데, 이걸 못 복원한다고?"라고 생각할 수도 있고 나 역시 그랬다. 조금 더 자세히 알아보자.
'그림2'의 3번과정에서 b는 매번 다르다. 랜덤한 b를 만들어서 연결하고 연결이 끝나면 즉시 삭제한다. (OTP와 비슷한 개념이다.) 9번과정에서 만든 a도 동일하다. 사전 hello에서 공유한 g에 각자의 랜덤 수를 제곱한 다음 각각 A, B라는 파라미터를 서로에게 전달한다. 그럼 해커는 {g, A, B}라는 값을 갖게 된다.
Diffie-Hellman에선 해커는

다음과 같은 수식을 풀어야 한다. (p 역시 사전 hello에서 서로 공유한다.)
클라이언트와 서버는 받은 파라미터에 a, b를 곱해서 PMS를 만들면 되지만, 해커는 A에서 a를 추출한 다음 g^{ab}를 계산해야 한다. 이 계산이 현대 컴퓨터론 연산이 많아 불가능하다. (양자 컴퓨터가 상용화될 5년 뒤엔 아니라고 한다.....)
여기서 서버의 개인키를 탈취당해도 서명은 5단계, 10단계에서 암호화에 사용되기 때문에 해커가 이를 복호화해서 만들 수 있는 데이터는 A와 B 뿐이다. 따라서 해커는 PM을 만들 수 없기 때문에 기존에 탈취당했던 암호화된 패킷은 안전하다.
결론
TLS 1.3부턴 RSA를 사용하지 않고 Diffie-Hellman 방식을 사용한다고 한다. 하지만 양자 컴퓨터가 상용화된다면 아마 PQC와 같은 기술이 적용된 TLS 1.4가 나오지 않을까 싶다.
'Network' 카테고리의 다른 글
| [Network] POST에서도 멱등성을? (Redis로 멱등성 키 API 구현하기) (0) | 2025.12.14 |
|---|---|
| [Network] 소켓 통신에서 멀티스레드가 필요한 이유 (0) | 2025.06.26 |
| [Network] HTTP와 HTTPS에 관하여 (0) | 2025.04.17 |
| [Network] TCP 3-way handshake와 4-way handshake (0) | 2025.03.21 |