합법적 TLS 감청은 어떻게 작동할까? 한 보안 연구자의 재현 실험

암호화된 통신도 들여다볼 수 있다는 사실

HTTPS, 그러니까 우리가 매일 쓰는 "자물쇠 마크" 붙은 웹사이트 통신은 TLS라는 암호화 기술로 보호되고 있어요. 은행 거래, 메신저, 이메일까지 거의 모든 인터넷 트래픽이 이 TLS 위에서 움직이죠. 그런데 "이 암호화된 통신도 법적으로 허용된 절차를 거치면 들여다볼 수 있다"는 이야기가 있다면 어떨까요? 보안 연구자 remyhax가 최근 공개한 글이 바로 이 "합법적 TLS 감청(Lawful TLS Wiretapping)"을 직접 재현해본 실험이에요.

여기서 말하는 합법적 감청은 우리가 흔히 생각하는 "해킹"이 아니에요. 통신사나 서비스 제공자가 법원 영장이나 정부 요청에 따라 특정 사용자의 트래픽을 수사기관에 넘겨주는, 제도화된 절차거든요. 미국이나 유럽 같은 곳에서는 CALEA(Communications Assistance for Law Enforcement Act) 같은 법으로 통신사가 이런 기술적 기능을 의무적으로 갖추도록 하고 있고요. 문제는 TLS가 워낙 잘 만들어진 암호화라서, 중간에서 그냥 패킷을 가로채봐야 암호문만 보인다는 점이에요. 그래서 어떻게 "합법적으로" 이걸 풀어내는지가 핵심 질문이 됩니다.

TLS 키를 손에 넣는 두 가지 길

remyhax가 글에서 풀어낸 핵심은 이거예요. TLS 통신을 풀려면 결국 세션 키(session key)가 필요하고, 이 키를 얻는 방법은 크게 두 갈래로 나뉘어요. 첫 번째는 서버의 개인키(private key)를 통째로 받아서 과거 트래픽까지 다 복호화하는 방식이고, 두 번째는 서버가 매 세션마다 만들어내는 임시 키를 실시간으로 빼내는 방식이에요.

그런데 요즘 TLS 1.3은 첫 번째 방식을 사실상 막아놨어요. PFS(Perfect Forward Secrecy, 완전 순방향 비밀성)라는 개념을 강제하거든요. 이게 뭐냐면, 매 통신마다 일회용 키를 새로 만들어서 쓰고 그 키는 통신이 끝나면 버리는 방식이에요. 그러니까 나중에 서버 개인키가 털려도 과거 통신은 못 푸는 거죠. 그래서 합법적 감청을 하려는 쪽은 두 번째 방식, 즉 서버가 키를 만드는 순간 그 키를 어딘가로 빼내는 메커니즘을 심어둬야 해요.

remyhax는 OpenSSL이나 BoringSSL 같은 오픈소스 TLS 라이브러리를 조금만 수정하면 이게 가능하다는 걸 보여줍니다. 세션 키가 생성되는 함수에 후크(hook)를 걸어서, 키 값을 별도 채널로 흘려보내는 거예요. 실제로 NSS(Mozilla의 TLS 라이브러리)는 SSLKEYLOGFILE이라는 환경변수만 설정하면 모든 세션 키를 파일에 기록해주는 기능을 이미 갖고 있어요. 원래는 개발자가 Wireshark로 자기 트래픽을 디버깅하라고 만든 기능인데, 이걸 그대로 감청에 쓸 수 있다는 게 포인트죠.

합법과 불법의 경계는 생각보다 흐릿하다

이 글이 흥미로운 건 단순히 "기술적으로 가능하다"를 보여주는 데 그치지 않는다는 점이에요. 합법적 감청을 위한 백도어를 심어두면, 그 백도어 자체가 공격 표면이 된다는 보안 업계의 오래된 경고를 실증적으로 보여주거든요. 2010년 그리스에서 Vodafone의 합법 감청 시스템이 해킹당해서 총리와 고위 관료들의 통화가 도청된 사건이 있었어요. 정부를 위해 만들어둔 뒷문을 누가 먼저 열고 들어갔는지 모르는 상황이 벌어진 거죠.

비슷한 맥락에서 애플과 FBI가 2016년에 충돌했던 "iPhone 백도어 요구" 사건도 떠올려볼 만해요. 애플이 거부했던 이유 중 하나가 "한 번 만든 백도어는 결국 다른 누군가도 쓰게 된다"였거든요. EU의 Chat Control 법안이나 영국의 Online Safety Act처럼 종단간 암호화(E2EE) 메신저에도 감청 기능을 넣자는 논의가 계속 나오는데, remyhax의 글은 "기술적으로는 이렇게 가능한데, 그래서 위험이 어디서 생기는지" 구체적으로 짚어준다는 점에서 가치가 있어요.

한국 개발자 입장에서는

한국도 통신비밀보호법에 따라 합법적 감청 제도가 있고, 통신사들은 관련 기술 표준을 따라야 해요. 우리가 서비스를 만들 때 TLS만 잘 적용하면 "안전하다"고 끝나는 게 아니라, 키 관리(KMS), 인증서 발급 체계, 라이브러리 선택까지 신경 써야 한다는 걸 다시 생각하게 만드는 글이에요. 특히 사내에서 자체 CA를 운영하거나 TLS 인터셉션(기업 보안 솔루션들이 흔히 하는 일)을 도입하는 경우, 그게 어떻게 동작하는지 원리를 알고 쓰는 것과 모르고 쓰는 것은 보안 사고가 났을 때 대응 속도가 완전히 달라지거든요.

또 한 가지, SSLKEYLOGFILE 같은 기능은 개발 중에 디버깅용으로 무심코 켜뒀다가 프로덕션에 그대로 올라가는 사례가 종종 있어요. 컨테이너 이미지나 환경변수 점검할 때 이런 항목도 체크리스트에 넣어두면 좋겠습니다.

마무리

TLS는 깨지지 않았어요. 다만 "합법"이라는 이름으로 만들어둔 입구가 있다면, 그 입구는 결국 모든 사람에게 열린 문이 될 수 있다는 게 핵심이에요. 여러분이라면 보안과 수사 편의성 사이에서 어느 쪽에 무게를 두시겠어요? 그리고 우리 회사가 쓰는 TLS 인터셉션 솔루션, 정확히 어떻게 키를 다루고 있는지 확인해본 적 있으신가요?