요약
Let's Encrypt가 도메인 검증용 원격 검증 지점을 4곳에서 6곳으로 늘립니다.
Let's Encrypt가 커뮤니티 포럼에 올린 공지입니다. 원격 검증 지점(도메인 소유 확인을 다른 네트워크 위치에서 한 번 더 해 보는 서버)을 늘리면 BGP 공격(인터넷 경로 정보를 속여 트래픽을 가로채는 공격)에 더 잘 버틸 수 있다고 설명했습니다.
왜 중요한가
- 인증서를 부정 발급받으려는 공격자는 이제 더 많은 독립 네트워크 경로를 한꺼번에 속여야 합니다.
- CA/브라우저 포럼의 기본 요건이 12월 15일부터 원격 지점 5곳 이상을 요구해, 기한 전에 규칙을 맞추는 조치이기도 합니다.
핵심 내용
- 검증 한 번에 주 데이터센터 1곳과 원격 지점 6곳에서 모두 7번 요청을 보냅니다.
- 주 서버와 함께 원격 지점 중 정족수(정해진 최소 개수) 이상이 올바른 응답을 받아야 검증이 통과합니다.
- 시험용 스테이징 환경에는 10월 27일, 문제가 없으면 운영 환경에는 11월 10일에 적용합니다.
- 기본 요건은 원격 지점이 서로 다른 지역 인터넷 레지스트리(대륙별 IP 주소 관리 기관) 2곳 이상에 걸쳐야 한다고 정합니다.
- 이용자에게 미치는 영향은 거의 없을 것으로 내다봤습니다.
HN 반응
- 8월 헤츠너 주소 대역 하이재킹으로 인증서가 부정 발급된 사례를 들어, RPKI(경로 출처 인증)나 CAA 레코드(발급 기관 지정)가 더 급하다는 의견이 나왔습니다.
- 목적지 망의 회선이 하나뿐이면 지점을 늘려도 소용없다는 반론에는, 인증기관 전체가 한꺼번에 뚫릴 위험은 줄어든다는 반박이 이어졌습니다.
개인 기술 용어집에 "원격 관점(remote perspectives)"이 없었던 분들을 위해 설명합니다. 인증서 서명 요청(CSR)의 도메인을 검증할 때 ACME 챌린지/응답 확인을 물리적으로 여러 곳에서, 즉 여러 물리적 네트워크 경로를 거쳐 수행한다는 뜻입니다. 네트워크 수준 공격을 더 어렵게 만들려는 것이죠.
예를 들어 example.com을 검증한다고 해 보겠습니다. 어딘가에 ACME 챌린지에 대한 응답을 마련해 두어야 합니다. DNS 기반 검증(DNS-01, DNS-PERSIST-01)으로 직접 하거나, example.com의 A/AAAA 레코드가 가리키는 IP 주소에서 돌아가는 서버(HTTP-01, TLS-ALPN-01)를 통해 합니다. 어느 쪽이든 CA가 챌린지 응답을 검증하러 갈 때는 DNS에도, CA의 데이터센터와 여러분의 DNS 서버나 앱 서버 사이의 네트워크 무결성에도 의존하게 됩니다. 이 둘은 BGP 공격 같은 방법으로 얼마든지 무너뜨릴 수 있습니다. 그러면 공격자가 DNS 응답을 바꿔치기하거나 목적지 IP 주소를 다른 서버로 우회시킬 수 있고, 거기서 자기 챌린지 응답을 끼워 넣어 (허가받지 않은) 인증서를 직접 발급받게 됩니다.
다중 관점 검증은 CA가 데이터센터 한 곳이 아니라 서로 다른 네트워크에 있는 여러 데이터센터에서 챌린지 응답을 검증한다는 뜻입니다. 그러면 가상의 네트워크 공격자가 무단 인증서를 발급받으려면 서로 독립된 여러 네트워크를 동시에 공격해야 합니다.
더 자세한 정보는 아래를 보세요.
https://letsencrypt.org/2020/02/19/multi-perspective-validation.html
https://community.letsencrypt.org/t/multi-perspective-validation-geoblocking-faq/218158
깐깐하게 따지자면, 원격 관점의 위험 감소 효과와 이점은 이론적인 수준이고, 목적지 네트워크도 독립된 링크를 여러 개 갖추고 있어야 성립합니다. 그렇지 않으면 Let's Encrypt가 뭘 하든 "업링크" ISP는 전부 단일 장애점(SPoF)입니다. 트래픽이 목적지에 닿으려면 반드시 거쳐야 하니까요.
그래도 원격 관점은 해 둘 가치가 있습니다. Let's Encrypt가 일반적인 인증서 요청자의 인프라보다 "덜 다양해서는" 안 되죠.
맞아요, 단일 홈 목적지 네트워크로 가는 연결을 MitM할 수 있다면, Let's Encrypt가 관점을 몇 개를 쓰든 그 네트워크 안의 대상에 대한 인증서를 받아 낼 수 있어요.
하지만 Let's Encrypt의 관점 전부에서 업링크를 MitM할 수 있다면, 사실상 모두를 상대로 CA 전체를 무너뜨릴 수 있잖아요. 관점을 늘리면 그럴 위험이 줄어듭니다.
Let's Encrypt는 DV 인증서만 발급합니다. DV에서는 목적지로 가는 모든 연결을 MitM할 수 있다면 그 도메인을 실제로 소유한 셈입니다. DigiCert의 설명을 보세요.
DV 인증서를 아예 허용하는 것 자체가 결함이라고 볼 여지도 있습니다. 하지만 이미 존재하는 이상, LE가 이렇게 하는 것은 스푸핑의 문턱을 올릴 수 있는 만큼 끝까지 올리는 일입니다.
DV 인증서가 없었다면 웹의 상당 부분은 아예 암호화되지 않았을 겁니다.
독립 사이트 운영자 중에 더 비싸고 복잡한 EV 절차를 밟을 사람은 거의 없을 거라고 봅니다.
맞아요... Let's Encrypt가 나오기 전에는 대부분 그랬죠. 빅테크 바깥의 관행을 혼자 힘으로 바꿔 놓았어요.
좀 과장이네요. 도메인 검증 인증서는 Let's Encrypt 이전에도 이미 있었고 꽤 흔했어요. LE가 달랐던 점은 인증서가 무료였다는 거죠.
독립 사이트 운영자 대부분은 원한다 해도 EV 인증서를 받을 수도 없어요. 절차상 신청자가 사실상 기업이어야 하거든요.
그건 정책이지, DV 인증서에 본질적으로 따라오는 결과가 아닙니다.
DNS 외의 모든 검증 방식을 막아 버려도 여전히 DV이고, 신경 써서 설계하면 MitM에 면역일 수도 있습니다. 제가 그렇게 하자고 주장하는 건 아니고, 그런 선택지도 있다는 얘기입니다.
DNSSEC을 의무화하지 않는 한, DNS 구간의 MitM에는 면역이 될 수 없어요.
지금 방식에 너무 매이지 마세요. 그냥 저와 같이 상상해 보자는 겁니다. 레지스트리에서 곧바로 값이 오고 어떤 안전한 링크가 있다고 치는 거죠. DNSSEC일 수도 있고 아닐 수도 있고요.
국가 간에 큰 법적 변화가 없다면, 공개 웹의 OV/EV 인증서는 잘 봐줘야 무의미하고 최악의 경우 위험할 만큼 오해를 부릅니다. 일반적인 웹 브라우징 밖의 특정 상황에서는 여전히 꽤 쓸모가 있지만, 지금 논점은 그게 아닙니다.
저는 반대로 그 공격과 피해를 직접 봤습니다. 제가 알기로는 CA가 명세상 그렇게 하게 되어 있고, Let's Encrypt도 이미 하고 있습니다.
사용 사례를 말씀드리면, 많은 SaaS 제품이 관리자에게 ACME 방식으로 도메인 소유권을 증명하게 하거나 요구합니다. 그러면 관리자는 그 SaaS 제품에서 같은 도메인의 이메일 주소를 가진 사용자들의 프로필을 관리할 수 있게 됩니다.
아이러니하게도 테스트 환경 자체가 ACME 챌린지를 통과하려고 네트워크 꼼수를 썼습니다.
8월에 공격자가 다중 관점 검증이 있는데도 인증서를 발급받는 데 성공했습니다.
그러니까 경로 중간의 하이재킹을 막으려고(즉 공격자가 여러 경로를 공격해야 하게 하려고) 네트워크 위치를 여러 곳 두는 건 좋은데, 네트워크 전체가 목적지를 다른 곳으로 알고 있으면 그 모든 경로가 똑같은 (가짜) 위치로 이어집니다.
어쩌면 CAB는 같은 단일 장애점(목적지 스푸핑)을 그대로 안고 있는 검증 출처를 여러 개 쌓는 대신, RPKI 검증을 "MUST"로 삼는 쪽을 고려해야 할지도 모르겠습니다.
하이재커는 사실상 그 도메인의 통제권을 확보한 거예요. 제 기준으로는 정상 발급된 인증서입니다. 도메인 통제 인증서를 발급할 때 CA가 도메인 소유자의 신원을 확인하거나 동의를 받아야 한다는 부분은 어디에도 없으니까요.
그런데 예전에는 그렇지 않았어요. 일반적인 비"강화" 인증서조차 훨씬 높은 수준의 소유권을 증명해야 했거든요. 한번은 그 사업체가 주(州)에 법인 정관 갱신을 안 해 놓은 걸 알게 됐는데, 인증서 발급 기관의 검증 절차에서 걸러낸 적도 있었습니다.
저는 지금 모델이 더 좋습니다(제 생각엔 그만한 값어치가 있는 트레이드오프예요). 하지만 늘 이랬던 건 아니에요.
즉 이런 겁니다.
그건 확장 검증이 나오기 전의 일이었습니다. 정확한 연도는 기억나지 않지만 2007년 이전이었던 건 확실합니다(아버지 사업체였는데 2007년에 돌아가셨거든요).
따지고 보면 SSL 초창기에는 정말 그랬습니다. 인증 기관들이 그런 일을 해 본 적이 없으니, 영업 담당 임원이 뉴욕 본사까지 날아가 계약서에 (펜으로) 서명을 받고 5,000달러를 받아 가는 식이었죠. 그 초기 인증서는 요즘 기준으로 쓰레기나 마찬가지입니다. Chat GPT가 위조하는 법을 가르쳐 줄 수도 있겠지만, 아마추어가 집에서 하기엔 비용이 너무 들겠네요. 그래도 거기엔 번지 주소 같은 게 적혀 있긴 했습니다. 읽어 볼 마음이 있다면요. 물론 웹 브라우저는 그 번지 주소를 읽지 않았고, 그 내용이 현실과 맞는지는 여러분보다도 더 모릅니다.
길어야 몇 년 만에 바닥을 향한 경쟁이 한창입니다. "간소화된" 절차에 10달러를 들여 인증서 1,000개를 개당 10달러에 팔면, 1,000달러를 들여 인증서 100개를 개당 100달러에 파는 경쟁사보다 더 많이 벌거든요. 그 결과 세기가 바뀔 즈음에는 "도메인 검증"이 일반적이었습니다. 닷컴 붐 때 여기 없었다면 이런 건 구경도 못 해 봤을 겁니다. 이 분야 책을 아마존에서 샀다면, 아니면 전부 온라인에 있어서 책을 아예 읽어 본 적이 없다면, 여러분은 DV가 어디에나 깔린 뒤에 온 사람입니다.
다른 분이 EV를 언급하셨는데, EV와 OV는 사실 뒤늦게 등장한 겁니다. CA들이 알아챈 거죠. 고객은 "더 좋은" 인증서에 100달러를 내고 싶어 하지 않는다, 차이를 구별하지도 못하니까. 그래서 회의가 시작됐고, 그게 바로 CA/브라우저 포럼, 줄여서 "cab" 또는 "cabf"라고 부르는 곳입니다. 이 회의는 처음에 두 가지 결과를 냈습니다. 그중 하나는 오늘날까지 이어지고 있고 오히려 더 강해졌습니다.
인증 기관은 모든 인증서에 대해 최소한 일정한 기준 요구사항("CA/BF BR")을 충족해야 한다. 이 요구사항을 충족하지 못하는 인증서는 발급할 수 없고, 그래서 검증이 아무리 형편없어도 하한선이 생긴다.
브라우저 벤더는 새로운 "강화" 검증 인증서에 번쩍이는 UI를 추가해, 고객이 더 낫다는 것을 눈으로 볼 수 있게 하고 CA에게는 새로운 판매 기회가 된다.
실제로는 몇 년 지나자 (2)는 말이 안 되게 됐습니다. 번쩍이는 UI는 데스크톱 PC에서는 통하지만 초기 스마트폰에는 들어갈 자리가 없으니 그냥 넣지 않습니다. 그러다 보면 데스크톱 브라우저도 스마트폰 제품과 똑같아 보이게 만들게 되고, 그 사이 내내 UX 전문가는 사용자가 이 UI를 이해하지 못한다고(그냥 판매용 장식이었으니 놀랍지도 않죠) 말하고, 보안 전문가는 사용자 안전에 순손해라고 말합니다. 그렇게 브라우저의 EV UI는 안녕을 고했습니다.
그런데 거래의 다른 쪽은 아주 잘 풀렸습니다. BR은 한 번 조이면 되돌릴 수 없는 톱니바퀴였습니다. 2012년에는 어떤 영업 사원이 점심 먹다 회사 이사를 만난 걸 근거로 10년짜리 인증서를 발급해도 괜찮았습니다. 2016년에는 5년조차 확실히 너무 길고, 실제 공식 기록을 확인하거나 어떤 형식적인 절차를 거쳐야 합니다. 2012년에는 mysql.test.internal 같은 이름으로 발급해도 괜찮았죠. 공개 이름이 아니니까요? 2016년에는, 어, 안 됩니다. 바로 그래서 그 인증서를 발급하면 안 되는 겁니다. 그 이름은 누구도 소유할 수 없으니 가짜 인증서를 발급하지 마세요, 이건 심각한 일입니다. BR 덕분에 우리가 조금씩 지금의 자리까지 온 겁니다.
저는 표준 검증 절차를 여러 번 거쳤는데, 전체가 보안 연극 같았습니다. 예를 들어 신분증 스캔본을 올려야 했는데, 제가 사는 나라에서는 민간 기관이 정부 데이터베이스에 접근해 그게 포토샵으로 만든 이미지가 아닌 진짜 신분증인지 확인할 수 없다는 걸 저는 확실히 압니다. 정부가 제3자가 쓸 수 있는 SSO를 제공하는데도, 주요 인증서 발급 기관 중 어디도 그걸 구현하지 않았어요. EV 인증서도 마찬가지였고요. 그냥 JPEG 한 장을 믿은 겁니다.
공과금 고지서를 요구하는, 미국에 기반을 둔 서비스들의 그 난해한 인증 절차와 비슷합니다. 핀란드 시골의 작은 공공요금 업체가 발행한 청구서를 무슨 수로 확인한다는 건지 모르겠어요.
그 경로 하이재킹이 RPKI 상 유효했던 이유는 공격자가 Hetzner의 AS를 AS_PATH에 위조해 넣었고, Hetzner가 ROA에 최대 길이를 /24로 설정했기 때문입니다( https://bgp.tools/rpki-history?cidr=162.55.0.0%2f16&asn=24940 ).
저는 진짜 해법이 CAA 레코드 사용을 장려하는 것, 가능하면 accounturi 매개변수까지 포함하는 것이라고 생각합니다.
jabber.ru 공격도 있었죠. 공격자가 서버의 네트워크 케이블을 물리적으로 가로채서 그냥 직접 인증서를 발급받았어요.
스노든 폭로 이후 Let's Encrypt가 나오기 전에는 HTTPS를 켜는 일이 어렵고 비쌌다니, 지금 생각하면 놀랍네요.
Firesheep 기억하세요? 열린 와이파이 네트워크에서 평문 HTTP를 쓰는 게 예사였잖아요. 말 그대로 같은 액세스 포인트에 있는 아무나 쿠키까지 포함해서 내 네트워크 세션 전체를 읽을 수 있었어요. https://en.wikipedia.org/wiki/Firesheep
Firesheep과 스노든은 비슷한 시기에 겹쳐 일어난 요인들이고, 그것들이 지금 거의 보편화된 HTTPS 사용으로 이어졌습니다.
유튜브 영상을 전부 다른 영상으로 바꿔치기할 수 있는 재미있는 안드로이드 앱도 있었어요.
CSR을 사람이 처리하고 승인해야 하는 것처럼 보였고, 수수료는 수천 달러였죠. 정말 먼 길을 왔습니다.
제가 상대해야 하는 레거시 시스템과 임베디드 장비만 빼고요. 인증서 자동화 기능이 전혀 없는데 예산상 수명은 아직 남아 있는 것들이 있어요. 그 멍청한 것들은 지금도 수동 등록이 필요합니다(적어도 그 멍청함을 손으로 달래 가며 맞추는 지저분한 일회성 스크립트가 필요하고요). 인증서 수명이 계속 짧아지면서 문제가 그만큼 더 고통스러워지고 있습니다.
용도에 따라서는 여전히 어렵습니다. 셀프 호스팅은 이것 때문에 정말 짜증스러워질 수 있어요.
저는 보통 LetsEncrypt 덕분에 셀프 호스팅이 훨씬 쉬워졌다고 생각합니다. 적어도 HTTPS를 지원하고 싶다면요.
LetsEncrypt는 이전 시스템들이 안고 있던 문제, 곧 완벽함이 좋음의 적이라는 문제를 마침내 해결했습니다. 예전에는 인증서를 받는 사람이 자기가 말한 그 사람이 맞는지 검증하는 데 초점이 많이 맞춰져 있었어요. 그런데 LetsEncrypt가 나타나서 "그 부분은 중요하지 않다, 정말 중요한 건 데이터를 보호하는 것이다"라고 했고, 진짜 문제를 통째로 해결했습니다. 방문하는 웹사이트마다 인증서를 들여다보는 사람은 거의 없으니 그런 보호는 대부분 쓸모가 없었고, HTTPS가 널리 퍼지는 데 걸림돌만 됐습니다. 문제의 범위를 전송 중인 데이터를 아무도 들여다보거나 수정하지 못하게 하는 것으로만 좁히자 자동화는 가능해진 것은 물론이고 쉬워지기까지 했습니다.