Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
오늘은 안전한데, 왜 문제라는 걸까요? HTTPS로 접속하면 브라우저에 자물쇠 아이콘이 뜹니다. 데이터는 AES로 암호화되고, RSA로 키를 주고받고, SHA로 위변조를 검증합니다. 언뜻 보면 완벽한 구조입니다.
그런데 보안 전문가들은 오랫동안 TLS 1.2의 한 가지 구조적 약점을 지적해왔습니다. 이 약점은 평소에는 절대 드러나지 않습니다. 통신은 멀쩡히 암호화되고, 로그인도 결제도 문제없이 이루어집니다.
문제는 "지금"이 아니라 "나중에" 터진다.
TLS 1.2가 키를 주고받는 방식
TLS 1.2에서 실제 데이터는 AES로 암호화된다. 그런데 AES는 대칭키 방식이라 클라이언트와 서버가 반드시 같은 키를 가지고 있어야 합니다..
이 키를 어떻게 나눠 가질까? TLS 1.2의 답은 다음과 같습니다.
- 클라이언트가 Premaster Secret이라는 비밀값을 혼자 만듭니다.
- 이 값을 서버 인증서 안에 들어 있는 RSA 공개키로 암호화합니다.
- 암호화된 값을 서버에 전송합니다.
- 서버는 자신의 RSA 개인키로 복호화해서 Premaster Secret을 확보합니다.
이후 양쪽은 Premaster Secret + Client Random + Server Random을 이용해 Master Secret, 그리고 최종 AES 세션 카를 계산합니다.
[그림 1] TLS 1.2 Handshake ─ RSA 공개키로 Premaster Secret을 암호화해 전달합니다.
TLS 1.2는 "비밀값을 안전하게 전달하는" 방식으로 키를 공유합니다.
그리고 이 "전달"이라는 행위 자체가 나중에 문제의 씨앗이 됩니다.
만약 몇 년 뒤 RSA 개인키가 유출된다면?
여기서 가정을 하나 해보겠습니다.
- 공격자가 몇 년간 특정 서버로 오가는 TLS 패킷을 전부 저장해 두었습니다. 실제로 국가 단위 감청 인프라나 대규모 트래픽 미러링으로 충분히 가능한 시나리오입니다.
- 이 패킷들은 당시 기준으로 전혀 해독할 수 없었습니다. AES-256도, RSA-2048도 무차별 대입으로 뚫을 수 없기 때문입니다.
- 그런데 몇 년 뒤, 서버 운영 실수나 해킹, 혹은 내부자 유출 등의 이유로 그 서버의 RSA 개인키가 공격자 손에 들어갑니다.
이 순간 무슨 일이 벌어질까요?
[그림 2] RSA 개인키 유출 시 과거 통신이 소급 복호화되는 흐름
공격자는 저장해 둔 Encrypted Premaster Secret을 유출된 개인키로 복호화하기만 하면 됩니다. 그러면 Premaster Secret이 나오고, 여기서 Master Secret과 세선 키까지 그대로 재현할 수 있습니다.
결과적으로 몇 년 전 주고받았던 로그인 정보, 결제 정보, 개인 정보, 내부 통신 내용까지 전부 평문으로 복원됩니다.
이게 왜 특히 무서운가
일반적인 보안 사고는 “지금 뚫리면 지금부터 위험”입니다. 그런데 이 구조는 다릅니다.
- 공격자는 오늘 서버를 뚫을 필요가 없습니다. 몇 년 뒤에 뚫어도 지금까지의 모든 과거 통신이 한꺼번에 노출됩니다.
- 방어자 입장에서는 “우리 서버가 지금 안전한가”만 신경 써서는 부족합니다. “우리 개인키가 미래의 어느 시점에도 절대 유출되지 않을 것”이라는, 사실상 불가능한 조건을 만족해야 안전이 보장됩니다.
- 개인키 하나가 서버의 전체 수명 동안 주고받은 모든 세션의 키가 되는 것이나 다름없다. 개인키 = 만능키인 셈입니다.
이런 성질을 Forward Secrecy(전방향 기밀성)의 부재라고 부릅니다. Forward Secrecy란 “지금 키가 유출되더라도 과거의 통신 내용은 안전해야 합니다.”는 원칙인데, TLS 1.2의 RSA Key Exchange 방식은 이 원칙을 근본적으로 만족시키지 못합니다.
문제의 뿌리는 알고리즘이 아니라 구조
여기서 중요한 오해를 짚고 넘어가야 합니다. 이 문제는 AES가 약해서도, RSA 키 길이가 짧아서도 아닙니다. AES-256과 RSA-2048은 지금도 여전히 강력한 알고리즘입니다.
문제는 "하나의 장기 키(RSA 개인키)가 모든 과거 세션 키의 뿌리 역할을 합니다."는 설계 그 자체에 있습니다.
[그림 3] 장기 키 하나가 모든 과거 세션의 뿌리가 되는 구조
개인키 하나가 유출되는 순간, 그 키로 보호되어 왔던 모든 시점의 통신이 도미노처럼 무너집니다.
TLS 1.2 자체에도 (EC)DHE 기반 키 교환 옵션이 있어 이 문제를 피할 수는 있었지만, 이는 어디까지나 “선택 사항”이었을 뿐 강제되지 않았습니다. 실제로는 여전히 많은 서버가 RSA Key Exchange를 쓰거나, 취약한 Cipher Suite를 함께 지원하고 있었습니다.
정리
TLS 1.2의 근본적인 문제는 다음 한 문장으로 요약됩니다.
" 현재는 안전해 보여도, 미래에 서버의 RSA 개인키가 유출되면 과거의 모든 통신이 소급해서 해독될 수 있습니다."
이 문제는 단순한 버그가 아니라 “키를 어떻게 만들고 나눠 가지는가”에 대한 설계상의 한계였습니다. 그리고 바로 이 지점에서, TLS 1.3의 개발자들은 완전히 다른 질문을 던지게 됩니다.
애초에 키를 네트워크로 전달하지 않으면 어떨까?
다음 편에서는 이 질문에서 출발한 TLS 1.3이 어떤 철학으로 설계되었는지, 그리고 인증서의 역할이 어떻게 근본적으로 달라졌는지 살펴보겠습니다.
