이 글은 Why you probably should not use a wildcard certificate의 번역글입니다.
최근 Let's Encrypted는 무료 와일드카드 인증서를 제공하기 시작했습니다. 이는 그동안 값비쌌던 상용 인증서를 사용해야 했던 이유 중 하나를 없애줄 좋은 소식이지만, 저는 많은 사람들이 와일드카드 인증서에 대해 위험할 정도로 잘못 이해하고 있다는 것을 확인했습니다.
이에 따라, 이 글에서는 왜 당신이 보안상 위험에 빠질 수도 있는 와일드카드 인증서를 왜 사용하면 안되는지에 대해 설명해보려 합니다.
개요
일반적으로 TLS("SSL")가 어떻게 동작하는지에 대해서는 정말 잘 이해하고 있는 경우는 거의 없습니다. 그 그러니까 먼저 중요한 부분을 간략하게 짚고 넘어갑시다.
일반적인(간단하게 표현한) TLS 동작은 다음과 같습니다:
- 암호 키 쌍을 만듭니다. (비밀키 + 공개키)
- 키 쌍으로 '인증서'를 만듭니다. (공개키와 hostname, 인증서 만료일 등이 들어간 메타데이터를 포함함)
- 인증서를 인증기관(Let's Encrypt와 같은)으로 보냅니다. 인증기관에서는 인증서를 받아 메타데이터를 검증합니다. -- 이 부분이 바로 당신이 인증서에 포함된 호스트네임을 소유하고 있다는 것을 증명합니다.
- 서명된 인증서를 받습니다. -- 원본 인증서와 CA(인증기관)가 이 인증서를 검증했다는 서명(사인)이 포함됩니다.
- 이 서명된 인증서를 클라이언트에게 제공(serve)합니다.
이제 클라이언트는 다음과 같이 동작하게 됩니다:
- 클라이언트가 신뢰하고 있는 인증기관으로부터 인증서가 서명되었는지를 검증합니다. (이는 보통 '신뢰할 수 있는 루트 인증기관(Trusted root certificate authority)'으로 시스템에 이미 포함되어 있습니다.)
- 신뢰할 수 있는 인증서라면, 인증서가 포함된 공개키를 서버의 공개키로 처리합니다. 그리고 이 키를 이용해서 서버와 암호화된 통신을 합니다.
이 설명은 정말 간략합니다만 여기서 왜 이 방식이 많은 공격으로부터 안전한지에 대해 자세하게 다루지는 않겠습니다. 하지만 일반적인 개념으로: 그 누구도 트래픽을 스누핑하거나 서버를 속일 수 없습니다, 적어도 (1) CA 키가 털리거나 (2) 당신의 키 쌍 + 서명된 인증서가 유출되지 않는 한은요.
그럼 와일드카드 인증서는 정확히 뭘까요?
보통 TLS 인증서 메타데이터에는 명확한 호스트네임이 들어가 있습니다. 예로 G메일의 경우에는 mail.google.com이 들어가 있겠죠. 이때 이 인증서는 https://mail.google.com/에 접속할 때에만 유효합니다. https://images.google.com/ 또는 https://my.mail.google.com/에서는 유효하지 않다는 거죠. 다른 말로하면, 호스트네임은 완전히 일치하여야 합니다. 만약 https://www.my.mail.google.com/에 mail.google.com 호스트네임을 가진 인증서를 사용하면 브라우저가 오류를 낼겁니다.
와일드카드 인증서는 좀 다릅니다. 이름이 의미하듯, 와일드카드 인증서는 완전히 일치할 필요 없이 와일드카드 부분만 일치하면 됩니다. 만약 *.google.com에 대한 와일드카드 인증서를 사용한다면 https://mail.google.com/ 및 https://images.google.com/ 모두 유효합니다. 하지만 여전히 https://google.com/ 및 https://my.mail.google.com에서는 유효하지 않습니다. 다른 말로, 별(*) 표시가 있는 곳에서만 유효한거죠.
이 방식은 여러 상황에서 굉장히 유용합니다. 예로 제가 어떤 단일 서버를 만드는데 이를 사용하는 모든 사용자가 그들만을 위한 서브도메인을 할당받는다고 가정해봅시다. 더 구체적으로 제 사이트는 https://joepie91.somesitebuilder.com/이고 당신의 사이트는 https://catdogcat.somesitebuilder.com/일 수도 있습니다.
이 상황에서 사용자가 늘어날 때마다 새로운 인증서를 발급받는 것은 매우 비효율적입니다. 더 쉽게 그저 *.somesitebuilder.com에 대해서만 인증서를 발급받으면 되고, 이 인증서 하나면 모든 사용자에게 유효하게 작용하는 거죠.
지금까진 좋습니다.
그럼 이걸 왜 모든 서브도메인에 사용하면 안되나요?
이제 문제가 발생하게 됩니다. 위 예에서 모든 사이트는 한 서버에서 호스팅된다고 설명했습니다. 만약 당신이 많은 서브도메인을 갖는 엄청 큰 웹 사이트나 조직을 운영한다면 - 구글을 예로 들면 images.google.com, mail.google.com - 이 서브도메인 모두는 아마 여러 서버에서 호스팅되겠죠.
자 이 부분이 와일드카드 인증서에서 보안 문제가 생길 수도 있는 부분입니다.
TLS 보안을 위한 요구사항 중 하나가 "키 쌍 + 서명된 인증서가 유출되지 않음"라고 이야기했습니다. 그런데 인증서는 가끔 유출되기도 합니다. - 예로 서버는 간혹 해킹당하기도 하죠.
만약 진짜로 이러한 일이 일어난다면 당신은 이러한 상황에서 최대한 피해를 줄이고 싶어할 겁니다. - 이상적으로, 인증서를 매우 빠르게 만료시킬 거고, 해킹당한 서버를 제외하고는 아무 영향을 끼치지 않겠죠. 이슈를 해결하고 나서는 유출당한 인증서를 더 이상 사용할 수 없게(revoke) 할거고, 안전한 새 인증서를 발급받고, 다른 서버는 영향을 받지 않을겁니다.
하지만, "여러대의 서버를 운영"하는 경우는 반드시 고려해야 합니다. 만약 images.google.com 서버만 해킹당한다면 mail.google.com은 영향을 받지 않을겁니다. 하지만, images.google.com 서버의 인증서가 *.google.com을 위한 와일드카드 인증서였다면 mail.google.com까지 털어서 이메일 트래픽을 훔쳐본다던가 할 수 있게 되겠죠. mail.google.com 서버는 해킹당하지 않았는데도 말이죠!
오직 한 서버만 해킹당했음에도 이 상황이 닥친다면 우리는 피해를 줄이기가 어렵습니다. 이메일 서버까지 리스크를 감당해야 하는거죠. 만약 우리가 mail.google.com, images.google.com으로 각각 분리된 인증서를 사용했다면 이런 상황은 닥치지 않을겁니다.
이야기에 대한 교훈
각각의 인증서는 한 서버만을 위해 사용되어야만 합니다, 또는 같은 역할을 하는 서버의 클러스터에만요. 서로 다른 서버에 서로 다른 서비스가 올라간다면 이러한 상황에서는 와일드카드가 아닌 각각의 인증서를 사용해야 합니다.
만약 당신이 같은 서버에서 같은 서비스를 가리키는 여러 호스트네임을 갖고 있다면 와일드카드 인증서를 써도 좋습니다. 이 와일드카드 인증서가 다른 서버를 가리키는 호스트네임까지 커버하지 않는다면 말이죠. 그렇지 않다면, 각각의 서비스는 반드시 각각의 서비스를 위한 인증서를 가져야 합니다.
만약 당신이 단일 서버면서 단일 서비스를 가리키는 호스트네임을 갖고 있다면 - 예로 login.mysite.com 및 사용자에게 생성된 사이트 - 사용자에게 생성된 사이트의 경우는 그 서비스를 위한 접두사(prefix)를 두어야 합니다. 예로, 인증서 하나는 login.mysite.com, 나머지(와일드카드)는 *.users.mysite.com 처럼요.
뭐 실제로는, 당신은 아마 절대로 와일드카드 인증서가 필요하지 않습니다. 와일드카드 인증서라는 선택지가 있는 것은 굉장히 좋지만, 위 예처럼 사용자마다 인증서를 자동으로 생성해야 하는 경우를 제외하고는 와일드카드 인증서는 아마 완전히 불필요하고 안전하지 않은 선택지입니다.
HIGHLIGHT:
(명확하게: 이 내용은 Let's Encrypt에만 해당하는 것이 아니라 일반적인 모든 와일드카드 인증서에 해당합니다. 하지만 Let's Encrypt 덕분에 와일드카드 인증서가 더이상 값비싸지지 않은 지금, 이 문제는 조금 더 주의를 기울일 필요가 있다고 봅니다.)
< 후에 댓글까지 번역해서 올려보겠습니다. >
