Let's Encrypt가 '일부러 망가진 웹사이트'를 만드는 이유 — TLS 테스트의 어려움

인증서가 잘못됐을 때, 당신의 코드는 제대로 실패하나요?

HTTPS를 쓰는 웹사이트에 접속하면 브라우저가 자물쇠 아이콘을 보여주죠. 이건 TLS(Transport Layer Security)라는 프로토콜로 통신이 암호화되어 있다는 뜻인데요, 이 TLS가 제대로 동작하려면 "인증서"라는 게 필요해요. 쉽게 말해서, "이 웹사이트가 진짜 그 웹사이트가 맞다"는 걸 증명해주는 디지털 신분증 같은 거예요.

그런데 이 인증서가 만료되었거나, 도메인이 일치하지 않거나, 위조된 경우에 우리가 만든 소프트웨어가 정확히 어떻게 반응하는지 테스트해본 적 있으세요? Let's Encrypt(무료 TLS 인증서를 발급해주는 비영리 인증기관)가 바로 이 문제에 대해 이야기하면서, 의도적으로 "망가진" 테스트 사이트를 운영하는 것이 왜 그렇게 어려운지 설명하는 글을 공개했어요.

도대체 뭐가 그렇게 어렵다는 걸까

TLS 인증서 검증을 테스트하려면, 일부러 잘못된 인증서를 가진 웹사이트가 필요해요. 예를 들어 이런 시나리오들이 있어요. 인증서가 어제 만료된 사이트, 인증서의 도메인이 실제 도메인과 다른 사이트, 자체 서명(self-signed) 인증서를 쓰는 사이트, 인증서 체인이 불완전한 사이트 등등.

문제는 이런 "의도적으로 망가진" 상태를 안정적으로 유지하는 게 생각보다 훨씬 까다롭다는 거예요. 가장 대표적인 예가 만료된 인증서 테스트인데요. "만료된 인증서"를 테스트하려면 실제로 과거에 발급되어서 이미 유효기간이 지난 인증서가 필요해요. 그런데 이걸 자동화하려면 인증서를 발급하고, 유효기간이 지날 때까지 기다리고, 그 상태를 유지해야 하거든요. 단순해 보이지만 인프라 관점에서는 꽤 복잡한 작업이에요.

더 골치 아픈 건, 이런 테스트 사이트가 "진짜 망가진 사이트"와 구분이 안 된다는 점이에요. 이게 무슨 말이냐면, 모니터링 시스템이나 자동화된 보안 도구가 이 테스트 사이트를 보고 "여기 인증서가 잘못됐다!"고 경고를 보내거든요. 의도적으로 망가뜨린 건데 모니터링은 그걸 모르니까요. 그래서 이런 테스트 환경을 운영하려면 모니터링과 알림 시스템에서 예외 처리를 해줘야 하는데, 이것 자체가 또 다른 복잡성을 만들어요.

왜 이게 중요한가 — 실제 사고 사례들

TLS 인증서 검증을 제대로 하지 않아서 생긴 보안 사고는 역사적으로 꽤 많아요. 가장 유명한 건 2014년 Apple의 "goto fail" 버그인데요, iOS와 macOS의 SSL 검증 코드에서 중괄호 하나가 빠져서 인증서 검증이 통째로 무시되는 어이없는 버그였어요. 이 버그 때문에 중간자 공격(Man-in-the-Middle, 이게 뭐냐면 통신 중간에 끼어들어서 데이터를 엿보는 공격)에 완전히 노출됐었거든요.

이런 사고가 반복되는 근본 원인 중 하나가 바로 테스트의 부재예요. "인증서가 잘못됐을 때 우리 앱이 연결을 거부하는지" 테스트하는 팀이 생각보다 드물거든요. 이유는 간단해요. 테스트 환경을 만들기가 귀찮으니까. Let's Encrypt가 이 테스트 인프라의 어려움을 공론화하는 건, 결국 더 많은 개발자가 이런 테스트를 할 수 있게 장벽을 낮추자는 취지예요.

기존에는 어떻게 테스트했나

이 분야에서 가장 유명한 테스트 사이트는 badssl.com이에요. 다양한 종류의 잘못된 인증서 상황을 제공하는 웹사이트인데요, expired.badssl.com에 접속하면 만료된 인증서를, wrong.host.badssl.com에 접속하면 호스트명이 불일치하는 인증서를 만나볼 수 있어요. 브라우저가 경고 페이지를 제대로 보여주는지 테스트할 때 많이 쓰이죠.

하지만 badssl.com도 운영 비용과 인증서 관리의 복잡성 때문에 관리가 쉽지 않다는 문제가 있었어요. Let's Encrypt는 이런 경험을 바탕으로, 테스트 사이트를 안정적으로 운영하기 위해 어떤 기술적 결정들을 했는지, 어떤 함정에 빠졌는지를 공유하고 있는 거예요.

또 하나 있는 게, 로컬에서 mkcert 같은 도구를 써서 테스트용 인증서를 직접 만드는 방법이에요. mkcert는 로컬 개발 환경에서 신뢰할 수 있는 인증서를 쉽게 생성해주는 도구인데요, 하지만 이건 "정상적인" 인증서를 만들어주는 거라서, 일부러 잘못된 상황을 테스트하는 데는 한계가 있어요.

한국 개발자에게 주는 시사점

한국에서 HTTPS 적용률이 높아지면서, 대부분의 서비스가 TLS를 기본으로 쓰고 있죠. 그런데 "TLS를 적용했다"와 "TLS 검증을 올바르게 구현했다"는 전혀 다른 이야기거든요.

특히 백엔드에서 외부 API를 호출할 때 주의가 필요해요. Python의 requests 라이브러리나 Node.js의 axios 같은 HTTP 클라이언트에서 SSL 검증 에러가 나면, 가끔 verify=False나 rejectUnauthorized: false 같은 옵션으로 검증을 그냥 꺼버리는 경우가 있거든요. 개발 중에 임시로 한 건데 프로덕션까지 그대로 가는 거예요. 이건 매우 위험한 패턴이에요.

Let's Encrypt의 이 글은 우리에게 이런 질문을 던져요. "우리 서비스는 인증서에 문제가 있을 때 정확히 어떻게 동작하지?" 이걸 답하려면 테스트가 필요하고, 테스트를 하려면 의도적으로 망가진 환경이 필요해요. 이런 테스트를 CI/CD에 포함시키는 것만으로도 보안 수준이 한 단계 올라갈 수 있어요.

당장 할 수 있는 것은, badssl.com의 다양한 엔드포인트에 HTTP 요청을 보내는 테스트를 작성하고, 모든 경우에서 연결이 정상적으로 거부되는지 확인하는 거예요. 간단하지만 대부분의 프로젝트에 이런 테스트가 없다는 게 현실이에요.

정리하자면

"의도적으로 망가진 웹사이트를 안정적으로 운영한다"는 게 이렇게 어려운 일이라니, 아이러니하죠. 하지만 이런 테스트 인프라가 있어야 우리가 만드는 소프트웨어의 보안을 제대로 검증할 수 있어요. TLS는 "설정하면 끝"이 아니라, 실패 상황까지 테스트해야 비로소 완성되는 거예요.

혹시 여러분의 프로젝트에서 TLS 인증서 검증을 별도로 테스트하고 있나요? 아니면 verify=False가 어딘가에 숨어있을 수도 있을까요?