4월부터 '증서만 보면 열쇠가 보이는' 상태였던 인증기관 8곳 — 브라우저는 안전했고 사물인터넷은 노출됐다
결론부터. 웹의 '이 사이트는 진짜입니다'를 보증해주는 인증기관 하나와 그 산하 중간 인증서 8개가, 증서를 구하는 사람이라면 누구나 개인키를 되집어낼 수 있는 상태였다. 유출 시점은 남의 서버 해킹이 아니라 기관이 열쇠를 찍어낸 순간 — 2025년 4월로 거꾸로 올라간다.
10월 20일(현지) 'we-have-a-problem.com'이라는 단출한 사건 페이지가 그 증거를 전부 공개했다. 신고자는 스스로를 '웨인'이라 밝힌 인물로, 10월 17일 네 인증서 프로그램팀에 여덟 키로 서명한 메시지를 증거로 보냈다. 문구가 압권이다. "여기에 문제가 있소 - 웨인." 해커뉴스에는 20일 밤 622표·댓글 334개로 1일 상단에 걸렸다.
공급망 사고를 겪은 운영자라면 등줄이 서늘할 조합이다. 코드도 저장소도 의존성도 아니다. 웹 보안의 지반 그 자체 — 누가 어떤 사이트에 대한 서명을 내줄 수 있는가 — 의 이야기다.
30초 요약
| 항목 | 내용 |
|---|---|
| 무슨 일 | 인증기관 eMudhra의 중간 인증서 8개 개인키 유출. 개인키를 '어떻게든' 남에게 준 게 아니라, 찍어낼 때부터 공개증서에 키가 다 드러나는 상태였다 |
| 증거 | 신고자 웨인이 8개 키 각각으로 서명한 메시지 파일(증명 꾸러미) 공개 — 인증서·공개키·서명 3종 세트, OpenSSL 두 줄이면 재검증 가능 |
| 차단 타임라인 | 10/17 프로그램팀 신고 + 파이어폭스·크롬 차단 → 10/19 애플 차단 + 하위 신뢰저장소 정식 통지 → 10/20 마이크로소프트 계열 차단 및 사건 페이지 공개 |
| 왜 브라우저는 괜찮았나 | 투명성 로그에 2025년 4월 이후 이 중간인증서 항목이 전무 — 투명성 강제 고객(파이어폭스·크롬·엣지·사파리)은 애초에 공격 성립 불가 |
| 그럼 누가 위험하나 | 로그를 보지 않는 브라우저 밖의 세계: 임베드 기기·앱·자바·curl과 스크립트 계열. 그리고 갱소 정보를 소비하지 않아 소프트웨어 업데이트를 받아야 하는 모든 클라이언트 |
| 내가 할 일 | 30초 자가 진단(curl 한 줄), 그리고 언어 런타임별 패치 버전 확인 — 고 1.27.3·certifi 2026.10.19·rustls-webpki 0.103.16·일렉트론 44.9.1 등 |
1. 무엇이 터졌나
사건 페이지의 문장부터 옮겨 읽는다. "eMudhra 중간 인증서 8장의 개인키가 유출됐다. 이들은 모질라·마이크로소프트·애플·크롬 루트 프로그램과 다수 하위 신뢰저장소가 신뢰하는 최상위 인증서로 이어진다." 여기서 '유출(compromised)'이 통상 의미하는 해킹 침투가 아니라는 점이 이 사건의 본질이다. 원인은 '중간 인증서 개인키들이 CA에 의해 잘못 생성됐다' — 공개 증서 하나로 되집을 수 있는 키를, 기관이 스스로 만든 것이다.
되집는 난이도는 공개된 증언이 더 소름 끼치게 알려준다. 사건과 무관한 해커뉴스 이용자가 '공개 지수 대비 개인 지수가 기형적으로 작다'며 자기 계산 결과를 남겼는데, 개인 지수 값이 통째로 '4'였다고 한다. 같은 페이지를 본 다른 참여자도 156을 직접 찾아냈다. 키가 아니라 힌트에 가까웠다는 뜻이다. 다만 두 값 모두 사건 페이지가 아닌 개인 계산 증언이라 1차 확인 전 진술로 붙여둔다.
피해를 헤아리는 방식도 남다르다. 도메인 하나, 고객사 하나가 아니라 '누구나 아무 사이트나'가 피해 후보였다. 웹 공개키 구조에서는 어떤 인증기관이든 대부분의 사이트에 대한 서명을 발행할 수 있다 — 이 원칙 하나로 이번 사고의 영향 반지름이 전 세계가 된다. 이번 중간 8장에 세고티크로 표기되는 교차 서명 건들이 엮여 있다는 점도 목록 파일(영향 중간인증서 명부)에 적혀 있다.
기관이 생소한 이름이라면, 인도에 근거지를 둔 서명·인증 서비스 기업이다. 해커뉴스에서는 증권거래소 상장사로 거래 화면 링크까지 공유됐고 '정부 사이트들에 쓰이는 그 기관이냐'는 질문도 달렸다.
2. 왜 대단한가
① '이미 뚫렸다'가 아니라 '예전부터 열려 있었다'라는 결함 형태
이번 사건은 공격자가 어젯밤 침입한 유형이 아니다. 결함 키가 만들어지기 시작한 2025년 4월부터, 자격만 갖춘 누구든 이 8장의 키를 복원해 쓸 수 있었다. 기관이 눈치채지 못한 상태가 반년 넘게 이어진 셈이다. 사고의 시계가 '발생'이 아니라 '생성'에서 돌아간다는 점이 징그럽다.
② 투명성 로그가 사수한 브라우저 — 작동한 안전벨트
그런데 브라우저권은 이번 사고에서 사실상 빗나갔다. 투명성 로그에 2025년 4월 이후 해당 중간 인증서로 발급된 항목이 하나도 없기 때문이다. 투명성 강제가 켜진 파이어폭스·크롬·엣지·사파리는 로그에 없는 증서를 받아주지 않으므로, 공격자가 키를 들고 있어도 게임판에 들어올 수 없었다. 사건 페이지의 표현을 그대로 빌리면 '공격될 수 조차 없었다'. 다만 이 안전벨트를 매지 않은 세계가 두 번째 화자다.
③ 갱소를 안 소비하는 클라이언트 — 진짜 과제가 남은 곳
기관은 8장 전부를 폐기 처리했고, 4대 플랫폼은 자체 차단 목록(OneCRL·CRLite·CRLSets)으로 즉각 막았다. 그런데 사건 페이지가 인정한 대로, 수많은 클라이언트가 폐기 정보를 소비하지 않는다 — 신뢰 목록에서 빠지는 소프트웨어 업데이트를 직접 받아야 비로소 안전해진다. 그래서 이번 사건은 '차단 완료'로도 끝나지 않는다. 임베드 기기가 스스로 업데이트받을 날을 기다리는 조용한 후반전이 남았다.
④ 인증서 없이 살던 언어 런타임들의 동시 릴레이
노드를 포함한 런타임 얘기는 3장의 표로 넘긴다. 시스템 신뢰저장소를 안 쓰고 자기 인증서 묶음을 싣고 다니는 고·루스트·파이썬 계열이 이번 사건에서 총출동했다. 파이썬의 certifi가 10월 19일, curl 번들이 10월 20일, 고는 1.27.3과 1.26.10 두 갈래로 동시에 패치됐고 노드와 번(Bun), 프리BSD는 아직 대기 중이다. 브라우저만 업데이트하면 되던 시절과 달리, 개발 스택 구석구석이 이번 사건의 지뢰밭이 됐다.
3. 바로 써먹기
① 30초 자가 진단 — 내 curl이 아직 물리는지
사건 측이 열두 개 검증 호스트를 열어뒀다. 증서 오류가 뜨면 그 클라이언트는 이미 안전한 쪽, 그냥 열리면 아직 신뢰하는 쪽이다.
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
# 오류(불신) = 이미 차단 반영됨 / 열림 = 아직 물림
# 기준: https://emudhra.we-have-a-problem.com/
② 내 스택 대조표 — 사건 페이지의 패치 버전 명부에서 핵심만 옮긴다
| 내 환경 | 안전해진 버전 | 상태 |
|---|---|---|
| Ubuntu (ca-certificates) | 20260816ubuntu0.22.04.1 외 3종 | 릴리스 완료 |
| Debian (ca-certificates) | 20250419~deb12u2 · +deb13u1 · 20260816+nmu1 | 릴리스 완료 |
| Fedora / Arch / Gentoo | 2026.2.92 / 3.131.1-1 / 20260816.3.125 | 릴리스 완료 |
| Go | 1.27.3 · 1.26.10 | 중간인증서 직접 차단(갱소 목록 미소비 대응) |
| Python | certifi 2026.10.19 · pip 26.2.2 · uv 0.13.4 | 릴리스 완료 |
| Rust | rustls-webpki 0.103.16 · webpki-roots 1.0.10 | 릴리스 완료 |
| 일렉트론 / 노드 / 번 | 44.9.1·43.8.1·42.11.16 / 대기 / 대기 | 일렉트론만 선제 대응 |
| macOS 기본 curl | — (/etc/ssl/cert.pem 미갱신) | 수동 제거 필요(아래 ③) |
③ macOS 명령줄 사용자용 임시 방편
macOS는 이번 사건을 반영했지만 OS 기본 내장 curl만 유독 예외다. 이 curl은 시스템 창구가 아니라 /etc/ssl/cert.pem이라는 파일을 보고, 폐기 확인도 생략한다. 사건 페이지에는 해당 묶음에서 영향 루트를 걸러내는 각색 명령이 그대로 실려 있다 — 백업 후awk로 두 루트 항목을 잘라내는 방식이다. 서버나 CI의 macOS 러너를 돌린다면 이 한 수를 챙겨둔다.
④ 운영자 체크리스트
브라우저 사용자 보호는 끝났다. 남은 건 남의 브라우저다. 내 API를 먹는 앱이 어떤 TLS 스택을 쓰는지(HTTP 스택이 시스템 저장소인지 자체 번들인지), 펌웨어 업데이트 없이 5년째 같은 기기에 박혀 있는 IoT 단말은 없는지 — 이번 사건은 그 목록을 다시 꺼내보게 하는 구실로 값어치가 있다.
4. 해외 반응 쟁점
쟁점 하나 — '웹 지반은 왜 이렇게 미쳤나'의 재탕. 해커뉴스 스레드 최대 다수는 매번 같은 결말을 반복하는 구조 자체를 문제 삼았다. '개인키를 잃어버린 기관을 걸러내는 심사 과정은 무엇인가', '차단 정보를 중앙 목록 몇 개에 의존하는 이 설계는 대체 언제까지'. 한 참여자는 도메인 소유권을 계층적으로 위임하는 잘 작동하는 시스템(전자우편의 그것)이 이미 있다며 구조 대체 주장을 폈고, 또 다른 참여자는 '바꾸기 쉬운 것처럼 말하지만 실제로는 안 바뀔 뿐'이라는 반론을 받았다.
쟁점 둘 — 기관의 퇴출과 시장 반응. 이번 규모면 루트 프로그램에서 퇴출당할 가능성이 높다는 전망이 여러 댓글에서 나왔고, 과거 한 기관의 파산까지 거론됐다. 인도 상장사 주가에 반영될 거라는 짤막한 관찰도 있었다.
쟁점 셋 — 사후 약발의 형평성. 차단 도구 쪽을 직접 만들어 온 한 참여자가 '처리가 극단적으로 불균등하다'고 짚었다. 파이어폭스 사용자는 두 시간 만에, 업데이트 없이, 자동으로 보호받았다. 반면 갱소를 소비하지 않는 스택 사용자는 배포판 릴리스를 기다려야 한다. 한 참여자는 아예 '피해가 아니라 대응이 불균등한 것 — 잠재적 피해 자체는 전 세계 전부'라고 정정했다.
5. 마시기 전 주의
· '브라우저는 안전했다'의 범위를 잘못 읽지 말 것. 안전하다기보다 '로그에 남아야 성립하는 공격이라 게임에 못 끼었다'에 가깝다. 투명성 강제 이전에 이미 발급돼 살아남은 증서가 있는지는 이번 사건 페이지가 따로 다루지 않는다.
· '실제 공격 징후'는 아직 없다. 사건 페이지가 직접 '공격자가 결함 키를 악용했는지는 모른다'고 밝힌다. 조용한 반년 동안 아무도 안 건드렸으리라 낙관할 근거는 아니다.
· 개인 지수 4·156 이야기는 해커뉴스 댓글 증언이다. 기관이 어떤 생성기를 썼는지는 모질라 버그 트래커의 초기 사고 보고에 담겼다고만 적혀 있고, 그 상세까지 이 글로 옮기지는 않았다. 사건 페이지의 이름 놀이 'we have a problem'은 기관명을 비튼 말장난이니 번역체 진지함으로 오해하지 말 것.
바로 가기
같이 읽기
한 잔 더 필요하면 오늘의 목록으로.