Security

[SSL/HTTPS] StartSSL/StartCom 사태와 Let's Encrypt로의 이전

Posted 2017. 06. 11 Updated 2021. 12. 28 Views 11973 Replies 1
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄

StartSSL 사태

제가 이곳 사이트에 SSL(TLS)을 처음 도입할 때 무료 SSL 인증서 발급 사이트인 StartSSL을 썼습니다. 유료 인증서를 써볼까도 아주잠깐 고민하긴 했지만, 상업용 사이트도 아닌데 HTTPS좀 써보자고 매년 인증서 갱신료를 지불하기에는 좀 그런것 같아서 구글링으로 여기저기 뒤지다가 찾아낸 곳이었습니다.

StartSSL.jpg

StartSSL에서는 DV(Domain Validation) 인증서를 무료로 발급해줬고, 갱신 주기도 1년으로 긴 편이어서 한동안 잘 써왔습니다. (인증서 갱신일이 임박해도 귀찮아서 번번이 미루다가 만료되서 거의 매번 신규 발급을 받았다는건 안비밀입니다.^^)

그러다가 올해 초인 1월경에 문제가 발생했습니다. 여느 때와 같이 인증서를 갱신했는데, 사이트에 접속을 시도하면 '신뢰할 수 없는 인증서'경고가 뜨는 것이었습니다. 처음에는 제가 감을 상실해서 뭔가 설정을 잘못했겠거니 하고 디버깅을 시도했는데, 얼마 안 가서 StartSSL 자체가 문제였다는 사실을 알게 되었습니다.

다음은 이 사태의 내막을 알 수 있는 기사들입니다.

  • https://threatpost.com/google-to-distrust-wosign-startcom-certs-in-2017/121709/
  • https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html

그 이유를 요약하면, StartSSL측에서 인증서를 발급할 때 도메인 소유자 검증을 소홀히 하였고, 심지어 의도적으로 위조된 인증서를 발행한 정황이 포착되었기 때문입니다. 여러 브라우저 제작사들은 이런 만행을 귀신같이 포착하고 바로 조치를 취하기 시작했습니다.

Google, Mozilla를 비롯한 여러 브라우저 제작사들이 2017년부터 StartSSL에서 발급하는 인증서를 신뢰하지 않기로 결정하고, 브라우저를 업데이트하여 Root CA 목록에서 StartSSL을 삭제했습니다. (정확히는 2016년 10월 21일 이후 발행된 인증서들에 적용됩니다.)

사실, StartSSL이 중국 IT 기업인 WoSign에 인수되었다는 기사를 접하고 심히 불안했었는데, 결국 얼마 못가서 이런 일이 터진 것이었죠. 인증서 갱신하러 StartSSL 홈페이지 들어갔다가 무료 인증서의 유효기간이 3년으로 늘어났다는 안내를 보고 좋아했었는데, 좋다 말았습니다. [...]

 

Let's Encrypt로의 이전

여튼, 뭐 StartSSL을 사용하지 못하게 되었으니 대체제를 찾아 나서야 했습니다. 사실, 그 이전에도 StartSSL이 중국쪽으로 넘어간 시점에서 (이것들이 뭔가 다른꿍꿍이가 있는게 아닌가 싶어) 다른 인증 기관을 찾아봐야겠다는 생각을 하긴 했었습니다. (하지만 그넘의 귀차니즘이..ㅎㅎ)

구글에 대충 'Free SSL Certificate'라고 검색해보니, CloudFlare와 Let's Encrypt가 뙇!하고 튀어나왔습니다. 이 두개를 여러 방면에서 검토해 본 결과, 제가 쓰기에는 Let's Encrypt가 더 적절하다는 결론을 내리게 되었습니다.

letsencrypt-logo-horizontal.png

CloudFlare의 경우 SSL뿐만 아니라 사실상의 Proxy로 동작해서 DDoS 방어 기능 등 여러 부가기능을 제공해주고 있긴 하나, 여러 리뷰를 검토해 본 결과 속도가 심각하게 느린 치명적인 문제가 있었습니다. 국내에 서버를 두고 CloudFlare 서비스를 쓰는 웹사이트에 접속해서 테스트해 본 결과, 이건 좀 아니라는 생각이 들었기 때문이죠. (느린 속도는 모든 트래픽이 태평양을 건너 LA까지 왕복을 하기 때문이라고 합니다.)

Let's Encrypt에서도 역시 DV(Domain Validation)급의 TLS 인증서를 무료로 발급해 줍니다. 다만, 한 가지 문제가 있다면 인증서 유효기간이 3개월(90일)로 매우 짧다는 점인데, 이 문제는 자동화된 갱신 스크립트로 충분히 커버 가능하므로 사실상 문제가 되지 않습니다. 오히려 1년짜리 수동 갱신형 인증서에 비해 귀찮은 인증서 갱신 작업이 자동으로 이루어져 아예 신경을 꺼도 되므로 더욱 편리하다고 할 수 있습니다.

사실, 보안 관점에서 바라볼 때 TLS 인증서의 유효기간은 짧을 수록 좋습니다. 만에 하나 비밀키가 유출되거나 하는 보안사고로 인해 인증서를 폐기해야 할 경우 위험에 노출되는 기간이 그만큼 짧아지기 때문입니다.

(참조) SSL/TLS 인증서의 동작 원리상 한 번 발행된 인증서를 인증 취소하는 것은 원천적으로 불가능합니다. 이러한 문제점을 보완하기 위해 발급 기관에서 '(의사)인증 취소'한 인증서의 일련번호를 모아놓은 별도의 Revoke 목록을 관리합니다. 브라우저에서 서버측으로부터 인증서를 수신한 뒤, 인증서 발급 기관의 서버로부터 최신 Revoke 목록을 받아서 유효한 인증서인지 여부를 판단하는 식이죠.. 인증서의 유효기간이 지나서 실질적으로 폐기되기 전까지는 이 방식으로 유효성을 검증해야 하므로 해당 기간동안은 다소 보안이 취약해집니다.

 

TLS 인증서 발급시의 도메인 인증

위에서 Let's Encrypt에서 발행하는 인증서는 유효 기간이 짧은 대신 자동화 스크립트로 커버가 가능하므로 문제가 되지 않는다고 했습니다. 여기서, 기존에 여타 TLS 인증서 발급 기관에서 한번이라도 인증서를 받아보신 분은 다음과 같은 한 가지 의문이 들 것입니다.

"정말 서버 관리자의 일절 개입 없이 갱신을 자동으로 할 수 있는 것인가?"

저도 사실 처음에 이 점이 의문이었긴 합니다. '3개월짜리'라는 안내를 보고 이전에 국내 모 기관에서 유료 인증서를 발급/갱신할 때 밟았던 절차가 생각나면서, '이제 3개월마다 귀찮아지는건가'라는 생각이 들었기 때문이죠..

통상적인 도메인 소유자 인증 방법

TLS 인증서를 발급받기 위해 가장 먼저 거쳐야 하는 절차가 바로 회원 가입 빼고 "인증서를 발급받으려는 이 잉간(?)이 도메인의 실소유주인지 여부를 검증"하는 과정입니다. TLS를 사용하는 목적중 하나가 클라이언트측에서 통신하는 상대 서버가 '진짜'인지 여부를 검증할 수 있도록 하기 위함이기 때문이죠. 실제 소유하지도 않은 도메인(ex. google.com)에 대한 인증서를 공신력 있는 발급 기관으로부터 발급받았다는 말은 곧, 해당 도메인으로 연결되는 가짜 서버를 만들 수 있다는 것과 같습니다.(DNS 스푸핑은 너무하다 싶을 정도로 매우매우매우 쉽습니다.) 이렇게 만들어진 서버는 피싱이나 각종 범죄에 활용될 수 있으므로 심각한 문제가 됩니다. 위의 StartSSL 사례에서 브라우저 제작사들이 민감&민첩하게 반응한 이유가 바로 이것입니다.

따라서, 공인된 TLS 인증서 발급 기관에서는 도메인 소유자 검증을 철저하게 수행합니다. 사용자가 입력하는 도메인 그대로 아무런 검증도 없이 인증서를 마구마구 발급하다가는 StartSSL꼴이 날 테니까요..

도메인 소유자 검증에서 전통적으로 가장 많이 사용되는 방법은 이메일을 통한 검증입니다. 도메인을 구입할 때 소유자의 이메일 주소를 입력하게 되어 있고, 이 정보는 Whois 서버에 저장되어 외부에서 접속해서 확인할 수 있습니다.

인증 기관에서는 도메인 소유자의 이메일 주소를 Whois 서버로부터 확인해서 인증 메일을 발송하고, 소유자가 수신한 메일을 통해 도메인의 실소유주가 맞음을 인증합니다. (메일 내의 링크를 클릭한다거나, 보안 코드를 복붙한다거나..등등)

이 소유가 검증 절차는 인증서의 최초 발급은 물론, 인증서를 갱신할때도 매번 수행해 줘야 합니다.(그 사이에 도메인 소유자가 바뀌었을수도 있으므로)

Let's Encrypt의 도메인 소유자 인증 방법

Let's Encrypt에서 발행하는 인증서는 유효기간이 3개월(90일)이므로 3개월마다 인증서를 갱신해야 하고, 또한 그 때마다 도메인 소유자 인증을 해야 합니다.

3개월마다 이메일로 인증하는 이 짓(?)을 해야 한다면, 귀차니즘으로 가득찬 저는 차라리 유료 서비스를 선택했을 것입니다. 하지만, 다행이도 Let's Encrypt에서는 다소 신박한(!) 도메인 소유자 인증 방법을 사용하고 있었습니다. 그 방법은 대략...

  1. 도메인이 연결된 서버에서 일련의 랜덤 문자열인 Challenge Seed를 생성하고, 이를 외부에서 HTTP(S)로 접근하여 확인할 수 있도록 약속된 URI에 위치시킵니다.
  2. Let's Encrypt 서버로 인증받으려는 도메인과 Challenge Seed를 함께 전송합니다.
  3. Let's Encrypt 서버에서 인증받으려는 도메인으로 접속하여 사전에 약속된 URI에 위치한 Challenge Seed값을 확보합니다.
  4. 두 개의 경로로 확보한 Challenge Seed가 일치하면 인증서 발급 절차를 계속 진행합니다.
  5. ????
  6. PROFIT!

인증 과정에서 Whois에 등록된 이메일 주소는 사용되지 않습니다. 또한, 관리자의 개입 없이 100% 자동으로 진행될 수 있으므로 스크립트로 만들어서 Crontab에 등록해 두면 귀찮은 인증서 갱신을 자동으로 수행되도록 할 수 있습니다.

이런식으로 도메인 소유자 인증이 가능한 이유는 도메인 소유자는 자신이 소유한 도메인이 소유자의 통제 하에 있는 서버 주소(IP)를 가리키도록 설정할 권한이 있다는, 지극히 당연한 사실에 기인합니다.

하지만, 웹 호스팅 서비스를 이용하는 등의 이유로 인해 서버 관리자(sudoer)권한이 없는 경우 위와 같은 자동 인증 방법은 사용할 수 없습니다. 이 경우, Challenge Seed를 생성한 뒤 직접 웹 디렉토리에 위치시켜 인증받는 수동 인증 방법을 사용해야 합니다.

 

▶ 바로 다음 글에서는 Let's Encrypt의 인증서 관리 유틸리티인 CertBot을 활용하여 TLS 인증서를 발급받아 설치하는 방법과, 자동 갱신 설정을 하는 방법에 대해 다루도록 하겠습니다.

 


Articles

1 2 3 4 5 6 7