HTTPS 키 교환 이야기 — RSA vs ECDHE

작성일: 2026-07-02 주제: HTTPS 보안 점검에서 “취약한 키 교환 방식(RSA) 사용”이라는 지적을 받고, 대체 이게 무슨 말인지 파고들며 정리한 노트.

HTTPS 취약점 점검을 하다 보면 “취약한 키 교환 방식(RSA) 사용”, “전방향 안전성(Forward Secrecy) 미지원” 같은 지적을 만난다. 조치는 보통 “서버 TLS 설정에서 TLS_RSA_WITH_* cipher를 제거하라”인데, 처음 보면 “RSA를 없애라고? 그럼 인증서를 지우라는 건가? 서비스 죽는 거 아냐?” 하고 겁이 난다.

결론부터 말하면 그게 아니다. 이 글은 그 오해를 풀기 위해 키 교환의 원리를 바닥부터 정리한 것이다.

1. HTTPS의 진짜 어려운 숙제: “열쇠를 어떻게 나눠 갖지?”

HTTPS는 통신 내용을 자물쇠 상자에 넣어 주고받는 것이다. 그런데 상자를 잠그고 여는 데는 열쇠가 필요하고, 나(클라이언트)와 서버가 똑같은 열쇠를 가져야 한다.

여기서 근본 문제가 생긴다.

인터넷은 누구나 지나다니며 엿볼 수 있는 공용 도로다. 그 위에서 어떻게 둘만 아는 똑같은 비밀 열쇠를 정할 수 있을까? 열쇠를 그냥 보내면 도청자가 주워버릴 텐데.

이 “열쇠를 안전하게 합의하는 과정”이 바로 키 교환(Key Exchange) 이고, TLS 핸드셰이크의 핵심이다. 방법은 크게 두 가지 — 낡은 RSA 방식과 요즘의 ECDHE 방식.

두 방식은 서로 다른 부품이 아니라 같은 임무(열쇠 합의)를 수행하는 두 가지 방법이라는 점이 중요하다. 하나가 반쪽이고 다른 하나가 나머지가 아니다. 각자 완결적으로 임무를 해낸다.

2. 낡은 방법 — RSA 키 교환

RSA는 발명자 세 명(Rivest, Shamir, Adleman)의 이름 첫 글자다.

“열려 있는 자물쇠” 비유로 보면:

서버가 열린 자물쇠(공개 키) 를 도로에 뿌린다. 누구나 가져도 된다.
클라이언트가 비밀 열쇠를 만들어 그 자물쇠로 잠가서 서버로 보낸다.
이 상자는 서버만 가진 특별한 키(개인 키) 로만 열린다.
서버가 열어서 → 이제 둘이 같은 비밀 열쇠를 공유. 임무 완료.

중간에 도청자가 잠긴 상자를 훔쳐도 서버 개인 키가 없어 못 연다. 여기까진 괜찮아 보인다.

RSA의 치명적 약점 — 마스터키 하나에 의존

문제는 서버가 그 개인 키 하나를 계속(정적으로) 쓴다는 점이다. 매번 똑같은 마스터키.

도청자가 지금 당장은 못 열어도, 오가는 암호문을 몰래 다 저장해뒀다가 몇 년 뒤 어떻게든 서버 개인 키를 손에 넣으면 → 저장해둔 과거 통신을 전부 복호화할 수 있다.

즉 “지금은 안전해도, 미래에 키가 털리면 과거까지 소급해 뚫린다”. 이것이 RSA 정적 키 교환에 전방향 안전성이 없다는 말의 정체다.

3. 요즘 방법 — ECDHE 키 교환

ECDHE도 풀어보면 겁먹을 게 없다.

DH (Diffie-Hellman): 두 사람이 각자 비밀 재료를 섞어, 도청자는 못 만드는 공용 비밀을 만들어내는 수학
E (Ephemeral): “일회용, 매번 새로”
EC (Elliptic Curve, 타원곡선): 그 수학을 빠르고 가볍게 하는 방법

핵심은 이것이다.

접속할 때마다 즉석에서 일회용 비밀 열쇠를 새로 만들고, 끝나면 버린다.

ECDHE의 장점 = 전방향 안전성 (Forward Secrecy)

매번 열쇠가 다르고 끝나면 버리므로:

나중에 서버 개인 키가 털려도, 과거에 쓴 일회용 열쇠는 이미 세상에 없다. → 과거 통신은 소급 복호화 불가.

RSA엔 없고 ECDHE엔 있는 이 성질이 둘의 결정적 차이다.

4. ⭐ 헷갈리기 쉬운 지점 — “RSA”는 두 군데 쓰인다

“RSA를 없애라”가 무섭게 들리는 이유가 여기 있다. RSA가 두 가지 다른 곳에 등장한다.

	뜻	조치
① RSA 인증서(개인 키)	서버의 신분증 — “내가 진짜 그 서버 맞다” 증명	✅ 그대로 둔다
② RSA 키 교환 방식	2장의 낡은 열쇠 합의 방법	❌ 이것만 끈다

게다가 요즘 방식 ECDHE도 서버 신분증은 ①번 RSA 인증서를 그대로 사용한다. 정식 이름이 ECDHE-RSA인 이유다 — “열쇠 합의는 ECDHE로, 신분 증명은 RSA 인증서로”.

그래서 “취약한 RSA cipher 제거”는 ②(낡은 열쇠 합의 방식)만 끄는 것이지, ①(인증서)은 손대지 않는다. 인증서 삭제·재발급이 아니다.

5. 디피-헬만은 어떻게 도청자 몰래 열쇠를 만들까? 🎨

ECDHE의 심장인 디피-헬만. “공용 도로에서 다 보이는데 어떻게 둘만의 비밀을 만들지?”의 답을 물감 섞기로 보면 직관적이다.

핵심 트릭 한 줄:

물감은 섞기는 쉬운데, 섞인 걸 도로 분리하는 건 사실상 불가능하다.

공개 물감 합의 — 둘이 “기본은 노랑” 하고 공개로 정한다. (도청자도 앎)
각자 비밀 물감 — 서버는 몰래 빨강, 클라이언트는 몰래 파랑을 고른다. (절대 안 보냄)
섞어서 전송 —
- 서버: 노랑+빨강 = 주황 → 전송
- 클라이언트: 노랑+파랑 = 초록 → 전송
- 도청자는 주황·초록을 보지만 빨강·파랑을 도로 뽑아낼 수 없다.
받은 것에 자기 비밀을 한 번 더 —
- 서버: (받은) 초록 + 자기 빨강 = 노랑+파랑+빨강 = 갈색
- 클라이언트: (받은) 주황 + 자기 파랑 = 노랑+빨강+파랑 = 갈색
- 둘 다 똑같은 갈색! 이게 공유 비밀 열쇠다.
도청자는? — 노랑·주황·초록만 가졌다. 갈색을 만들려면 섞인 물감에서 비밀 색을 분리해야 하는데 불가능. 다 봤는데도 열쇠를 못 만든다.

진짜로는 물감이 아니라 숫자로 한다. “섞기”는 거듭제곱 후 나머지 구하기(modular exponentiation)라 계산이 쉽고, “분리”는 이산 로그 문제라 슈퍼컴퓨터로도 사실상 못 푼다. ECDHE의 타원곡선은 이 계산을 더 효율적으로 만든 것뿐, 원리는 물감과 같다.

그리고 Ephemeral(일회용) 덕분에 접속마다 비밀 색을 새로 고르니, 한 세션 열쇠가 훗날 털려도 다른 세션은 안전하다. → 이게 전방향 안전성이다.

6. 그래서 “정적 RSA cipher 제거”가 왜 안전한가

정리하면 조치는 이렇다.

서버 TLS 설정에서 낡은 방식(TLS_RSA_WITH_*) cipher만 비활성화, ECDHE 계열만 남긴다.
인증서는 그대로, 애플리케이션 코드도 무관 — 순수 서버 설정 변경.

“낡은 방식을 없애면 그걸로만 접속하던 기기는 못 들어오지 않나?” — 맞다. 하지만:

요즘 기기는 이미 ECDHE로 접속 중이다. 서버가 ECDHE를 우선 제공하므로, 클라이언트가 둘 다 지원하면 ECDHE가 선택된다. 정적 RSA는 사실상 안 쓰이는 예비 경로다.
정적 RSA로만 접속하는 기기 = ECDHE 자체를 모르는 유물(대략 2011년 이전, iOS 4·Android 4.0 미만 급). 요즘 앱/브라우저 환경에는 거의 존재하지 않는다.
게다가 서버가 이미 TLS 1.2 이상만 받는다면, TLS 1.2를 하는 기기는 거의 전부 ECDHE도 지원한다.
되돌리기도 쉽다. 문제가 생기면 cipher 목록을 원복하고 재기동하면 된다. (인증서를 안 건드리니 재발급도 없다)

즉 “낡고 위험한 방법을 치우고, 더 안전한 방법만 남기는 것” 이다. 보안은 올라가고, 실사용 영향은 사실상 없다. 확실히 하려면 접속 로그에서 TLS_RSA_WITH_* 실제 사용 건수를 확인하면 된다 — 0에 가까우면 안심하고 제거.

마무리 요약

HTTPS의 어려운 숙제 = 공용 도로에서 둘만의 비밀 열쇠 합의하기 (키 교환)
RSA 키 교환: 서버 마스터키 하나에 의존 → 미래에 그 키가 털리면 과거 통신까지 뚫림 (Forward Secrecy 없음)
ECDHE 키 교환: 매번 일회용 열쇠 (디피-헬만) → 털려도 과거는 안전 (Forward Secrecy 있음)
디피-헬만의 마법 = “섞기는 쉽고 분리는 불가능” (물감 비유 / 실제론 이산 로그)
“RSA cipher 제거”는 낡은 키 교환 방식만 끄는 것이지 인증서 삭제가 아니다 — 오히려 보안 강화
ECDHE는 임무를 혼자 완결적으로 해내고 더 안전하므로, 그것만 있어도 충분하다