인터넷 주소창 왼쪽의 작은 자물쇠, 매일 보시죠? 그 자물쇠는 “이 사이트가 진짜 그 회사가 맞다”는 걸 인증기관(CA)이라는 회사가 도장을 찍어 보증해 준다는 표시예요. 그런데 이번 주, 인도의 인증기관 이머드라(eMudhra)가 쓰던 ‘도장 원판’ 8개가 누구나 1초 만에 복원할 수 있을 만큼 허술했다는 사실이 드러났어요. 그중 하나의 비밀값은 그냥 숫자 4였습니다.
다행히 크롬·파이어폭스·사파리(애플)·마이크로소프트는 이미 막았어요. 그래서 일반 사용자가 할 일은 생각보다 간단합니다. 다만 브라우저 밖(서버, 개발 도구, 오래된 기기)은 따로 챙겨야 해요. 오늘은 무슨 일이 있었는지, 왜 ‘숫자 4’가 그렇게 큰일인지, 그리고 누가 무엇을 하면 되는지를 초보 기준으로 풀어 볼게요.
한 줄 요약부터
| 질문 | 짧은 답 |
|---|---|
| 무슨 일이에요? | 인도 인증기관 eMudhra의 중간 인증서 8개에 딸린 개인키(도장 원판)가 너무 약하게 만들어져, 공개된 인증서만 보고도 누구나 계산해 낼 수 있었어요 |
| 얼마나 약했어요? | 원래는 약 116자리짜리 무작위 숫자여야 하는데, 실제 값은 4, 56, 66, 115, 155, 156, 230, 237 — 모두 1~256 사이였어요 |
| 왜 위험해요? | 그 원판으로 도장을 찍으면 아무 사이트(은행·메일 등)의 가짜 인증서를 만들 수 있어요. 같은 와이파이 등 중간에서 통신을 가로챈 공격자가 ‘자물쇠 달린 가짜 사이트’를 보여 줄 수 있다는 뜻이에요 |
| 실제 피해는요? | 현재까지 공격 보고는 없어요. 이 중간 인증서로 발급된 사이트 인증서도 공개 기록(CT 로그)에 없어서, 크롬·파이어폭스·엣지·사파리 사용자는 공격받을 수 없었다고 봐요 |
| 누가 막았어요? | 크롬·파이어폭스 10월 17일(현지), 애플 19일, 마이크로소프트 20일 차단. eMudhra도 인증서를 폐기했어요 |
| 아직 남은 숙제는? | 폐기 목록을 안 보는 프로그램(curl, 파이썬·Go 프로그램, IoT 기기 등)은 소프트웨어를 업데이트해야 막혀요 |
| 나는 뭘 해요? | 브라우저·OS·폰 업데이트면 충분. 개발자·서버 관리자는 ca-certificates·certifi 등 인증서 묶음을 갱신하세요 |
먼저, 주소창 자물쇠는 어떻게 ‘진짜’를 보증할까
인감증명서를 떠올리면 쉬워요. 은행 사이트가 “내가 진짜 은행이야”라고 말만 하면 아무도 안 믿겠죠. 그래서 믿을 만한 기관이 도장을 찍은 증명서(인증서)를 같이 내밀어요. 브라우저는 그 도장이 진짜인지 확인하고, 맞으면 자물쇠를 띄웁니다.
| 용어 | 생활 속 비유 | 하는 일 |
|---|---|---|
| 인증서 | 인감증명서 | ‘이 주소의 주인은 ○○’이라는 증명. 사이트가 접속할 때마다 보여 줘요 |
| 인증기관(CA) | 증명서를 떼 주는 관청 | 사이트 주인을 확인하고 도장을 찍어 줘요. eMudhra도 그중 하나(6천만 장 이상 발급했다고 밝힘) |
| 개인키 | 도장 원판 | 절대 밖에 나가면 안 되는 비밀값. 이걸로 도장을 찍어요 |
| 공개키 | 도장 자국 견본 | 누구나 볼 수 있어요. 도장이 진짜인지 대조할 때 써요 |
| 루트 인증서 | 본청 도장 | 브라우저·OS에 미리 들어 있는 최상위 도장 |
| 중간 인증서 | 지점 도장 | 본청이 ‘이 지점 도장도 믿어도 된다’고 보증한 도장. 실제 발급은 주로 여기서 해요 |
이번에 문제가 된 건 지점 도장(중간 인증서) 8개의 원판이에요. 본청 도장(루트)의 원판은 무사하다고 eMudhra는 밝혔어요. 하지만 지점 도장도 본청의 보증을 받았기 때문에, 원판만 있으면 브라우저가 믿는 진짜 같은 도장을 찍을 수 있었던 거죠.
‘숫자 4’가 왜 그렇게 큰일일까
이 인증서들은 P-384라는 타원곡선 암호를 써요. 원리는 단순해요. 비밀 숫자 d를 하나 고르고, 정해진 점을 d번 ‘더한’ 결과를 공개키로 내놓아요. 앞으로 계산하긴 쉽지만, 결과만 보고 d를 거꾸로 알아내는 건 사실상 불가능해요 — d가 충분히 클 때만요.
| 구분 | 정상적인 개인키 | 이번 eMudhra 키 |
|---|---|---|
| 크기 | 384비트 무작위 수 (약 116자리 숫자) | 1~256 사이 정수 (8비트 수준) |
| 가능한 경우의 수 | 약 10115개 — 우주의 원자 수보다 훨씬 많음 | 최대 256개 |
| 알아내는 데 걸리는 시간 | 현재 컴퓨터로는 사실상 불가능 | 노트북으로 1초 미만 |
| 비유 | 116자리 금고 비밀번호 | ‘1’부터 ‘256’까지 돌려 보면 열리는 자물쇠 |
보안 연구자 스콧 헬름(Scott Helme)은 모질라가 공개한 인증서 16장(키 8개 × eMudhra 서명본·섹티고 교차서명본)을 받아 1부터 차례로 대입해 봤고, 모두 바로 풀렸다고 밝혔어요. 흥미로운 점은 인증서 겉모양은 완벽하게 정상이었다는 거예요. d=4로 만든 공개키도 ‘올바른 점’이라, 형식 검사로는 잡히지 않아요. 직접 대입해 봐야만 알 수 있었죠.
| 중간 인증서 이름 | 용도 | 드러난 개인키 값 |
|---|---|---|
| EM DV TLS CA – G3B | 웹사이트(TLS) | 156 |
| EM DV TLS CA – G3C | 웹사이트(TLS) | 230 |
| EM EV TLS CA – G3B | 웹사이트(TLS) | 115 |
| EM EV TLS CA – G3C | 웹사이트(TLS) | 56 |
| EM OV TLS CA – G3B | 웹사이트(TLS) | 155 |
| EM OV TLS CA – G3C | 웹사이트(TLS) | 4 |
| EM OV CS CA – G3B | 코드 서명(프로그램) | 66 |
| EM OV CS CA – G3C | 코드 서명(프로그램) | 237 |
6개는 웹사이트용, 2개는 프로그램에 ‘정품 서명’을 하는 코드 서명용이었어요. 원인에 대해 eMudhra는 2025년 4월 키 생성 행사(Key Generation Ceremony)에서 만든 일부 중간 인증서의 문제라고 했고, 모질라 버그 기록에는 키 생성 스크립트 오류로 설명돼 있다고 알려졌어요. 즉 해커가 훔친 게 아니라, 처음부터 약하게 만들어진 거예요. 그래서 2025년 4월부터 이론상 누구나 알아낼 수 있었던 셈이에요.
그럼 나는 이미 위험했던 걸까?
결론부터 말하면 일반적인 브라우저 사용자는 공격받을 수 없었다는 게 크롬·모질라·제보자 측의 설명이에요. 열쇠는 인증서 투명성(CT) 로그예요. 요즘 공인 인증서는 발급되면 공개 장부에 기록돼야 하고, 크롬·사파리·파이어폭스·엣지는 장부에 없는 인증서를 믿지 않아요. 그런데 이 8개 중간 인증서로 발급된 사이트 인증서는 장부에 한 건도 없었어요.
| 어디서 접속하나 | 위험 정도 | 이유 |
|---|---|---|
| 최신 크롬·엣지·사파리·파이어폭스 | 낮음 | CT 장부 확인 + 이미 차단 목록 배포(재시작 없이 자동 적용) |
| 안드로이드 앱 | 대부분 낮음 | 구글 플레이 서비스로 차단 업데이트. 재부팅하면 즉시 반영 |
| 오래된 OS·업데이트 끊긴 폰 | 중간 | 차단 목록·인증서 묶음이 갱신 안 될 수 있어요 |
| curl·파이썬·Go·노드로 만든 프로그램 | 확인 필요 | CT를 안 보고, 폐기 목록도 안 보는 경우가 많아요. 인증서 묶음 업데이트가 필요해요 |
| IoT·공유기·셋톱박스 등 임베디드 | 확인 필요 | 업데이트가 드물어 ‘믿는 도장 목록’이 오래 그대로일 수 있어요 |
그러니까 이번 일의 핵심 숙제는 “브라우저 밖”이에요. 예를 들어 코인 자동매매 봇이나 회사 사내 스크립트가 거래소 API에 접속할 때, 오래된 인증서 묶음을 쓰면 같은 네트워크의 공격자가 가짜 인증서로 끼어들 여지가 생겨요. 아직 이런 공격이 보고되진 않았지만, 업데이트로 미리 문을 닫는 게 정답이에요.
제보부터 차단까지, 날짜로 보기
| 시각(현지 기준) | 한국 시간 | 무슨 일 |
|---|---|---|
| 2025년 4월 | — | 문제의 중간 인증서 8개 생성(이때부터 키가 약했음) |
| 10월 17일 18:05 UTC | 10월 18일 03:05 | 제보자 ‘웨인’이 크롬 루트 프로그램에 신고. 8개 키 모두로 “We have a problem here – Wayne” 문장에 서명해 증명 |
| 10월 17일 19:45 UTC | 10월 18일 04:45 | 크롬, CRLSet 업데이트로 해당 키 차단(업데이트·재시작 불필요) |
| 10월 17일 20:06 → 22:59 UTC | 10월 18일 05:06 → 07:59 | 모질라 신고 접수 후 3시간 안에 OneCRL로 전 파이어폭스 사용자 차단 |
| 10월 19일 | 10월 19~20일 | 애플 기기 차단, 하위 인증서 저장소 운영자들에게 공지 |
| 10월 19일 22:00 UTC 무렵 | 10월 20일 07:00 무렵 | 안드로이드에 구글 플레이 서비스로 차단 배포 |
| 10월 20일 | 10월 20~21일 | 마이크로소프트 차단, 모질라·구글 공식 블로그, Firefox 158.0.1·NSS 3.131.1, 리눅스 배포판 패키지 갱신 시작 |
| 10월 27일 오전(PDT) | 10월 28일 새벽 무렵 | 크롬이 상위 루트 emSign ECC Root CA – G3를 루트 목록에서 제거 예정 |
회사는 뭐라고 했나
| 누가 | 핵심 내용 |
|---|---|
| eMudhra | 문제는 2025년 4월 키 생성 행사에서 만든 특정 중간 인증서들에 한정, 루트 개인키·다른 중간 인증서는 무관. 1개만 실제 운영에 쓰였고, 8개 모두 최종 사이트 인증서는 발급하지 않았다(CT 기록으로 확인)고 설명 |
| 구글 크롬 | 약한 무작위성으로 생성된 키라 누구나 위조 가능했다고 확인. 다른 루트에 같은 결함이 없는지 점검했고, eMudhra의 남은 인증서 신뢰 여부도 정밀 검토 중 |
| 모질라 | OneCRL로 3시간 안에 차단, Firefox·ESR 업데이트와 NSS 인증서 목록에서 상위 루트 제거 |
| 클라우드플레어 | 공격자가 어떤 도메인이든 위조 인증서를 만들어 서버를 사칭하고 통신을 엿보거나 바꿀 수 있었다고 설명 |
| 인도 현지 | 이 회사 인증서나 기술을 쓰는 정부 사이트가 많아 파장이 크고, 업데이트가 어려운 IoT 기기 정리가 오래 걸릴 수 있다는 지적 |
누가, 무엇을 하면 될까
① 일반 사용자: 업데이트 한 번이면 충분해요
| 할 일 | 어떻게 | 체크 |
|---|---|---|
| 브라우저 최신화 | 크롬: 설정 → Chrome 정보 / 파이어폭스: 설정 → 일반 → 업데이트(158.0.1 이상) | 재시작 버튼이 보이면 눌러 주세요 |
| PC·맥 OS 업데이트 | 윈도우 업데이트 / macOS 소프트웨어 업데이트 | ‘나중에’로 미뤄 둔 것부터 |
| 안드로이드 폰 | 한 번 재부팅 + 설정 → 보안 → Google Play 시스템 업데이트 | 재부팅만으로도 차단이 바로 반영돼요 |
| 아이폰 | 설정 → 일반 → 소프트웨어 업데이트 | 자동 업데이트 켜 두기 |
| 인증서 경고 화면 | “연결이 비공개로 설정되어 있지 않습니다” 같은 경고는 절대 ‘계속’ 누르지 않기 | 특히 공용 와이파이에서 |
② 개발자·서버 관리자: ‘인증서 묶음’을 갱신하세요
많은 프로그램은 OS나 언어가 제공하는 인증서 묶음 파일(어떤 도장을 믿을지 적힌 목록)을 그대로 써요. 이 목록을 새로 받아야 문제의 도장을 안 믿게 됩니다. 제보자 측 정리 페이지에 나온 수정 버전은 이래요.
| 환경 | 수정된 버전(이상) | 업데이트 예시 |
|---|---|---|
| 우분투 ca-certificates | 20260816ubuntu0.22.04.1 / 24.04.1 / 26.04.1 / 26.10.1 | sudo apt update && sudo apt install --only-upgrade ca-certificates |
| 데비안 ca-certificates | 20250419~deb12u2, 20250419+deb13u1 | sudo apt update && sudo apt upgrade ca-certificates |
| 페도라 ca-certificates | 2026.2.92_v9.0.319 | sudo dnf upgrade ca-certificates |
| 알파인 | 20261020-r0 | apk upgrade ca-certificates (도커 이미지 재빌드) |
| 파이썬 certifi / pip / uv | certifi 2026.10.19 / pip 26.2.2 / uv 0.13.4 | pip install -U certifi |
| Go | 1.27.3, 1.26.10 | Go 업그레이드 후 다시 빌드 |
| 러스트 webpki-roots / rustls-webpki | 1.0.10 / 0.103.16 | cargo update |
| Electron | 44.9.1, 43.8.1, 42.11.16 | 앱 의존성 갱신 |
| NSS / curl CA 묶음 | NSS 3.131.1 / curl 묶음 2026-10-20 | 배포판 패키지 갱신 |
| Node.js · Bun · FreeBSD | 작성 시점 ‘대기 중(pending)’ | 공지 확인 후 업데이트 |
맥의 기본 /usr/bin/curl은 폐기 여부를 확인하지 않는 별도 인증서 파일(/etc/ssl/cert.pem)을 써서, 애플 차단과 별개로 남아 있을 수 있다는 점도 지적됐어요. 내 도구가 아직 문제의 인증서를 믿는지 궁금하면, 제보자 측이 만든 시험 주소에 접속해 보는 방법이 있어요. 인증서 오류가 나야 정상(안전)입니다.
| 확인 방법 | 정상(안전) 결과 | 주의 결과 |
|---|---|---|
curl https://dv-g3b-emudhra.we-have-a-problem.com/ |
SSL 인증서 오류로 접속 실패 | 아무 오류 없이 페이지가 열림 → 인증서 묶음 갱신 필요 |
| 브라우저로 같은 주소 열기 | 경고 화면 | 자물쇠가 뜨며 열림 → 브라우저·OS 업데이트 |
| 도커 이미지 | 새 베이스 이미지로 재빌드 후 위 curl 시험 통과 | 오래된 이미지 태그 고정 사용 |
③ 사이트 운영자: 내 인증서 ‘뿌리’를 확인하세요
크롬은 이번에 문제의 도장 위에 있는 루트 emSign ECC Root CA – G3 자체를 10월 27일(현지)부터 믿지 않기로 했어요. 그래서 내 사이트 인증서가 이 루트로 이어진다면 멀쩡한 인증서인데도 크롬에서 경고가 뜨게 돼요. 구글은 해당 사이트 운영자에게 다른 인증기관에서 새 인증서를 즉시 받아 설치하라고 권고했어요.
| 점검 항목 | 방법 | 해당되면 |
|---|---|---|
| 인증서 발급자 확인 | 브라우저 자물쇠 → 인증서 보기 → ‘발급자’·인증 경로 | eMudhra·emSign 이름이 보이면 확인 |
| 루트 이름 | 인증 경로 맨 위가 emSign ECC Root CA – G3 인지 | 10월 27일 전에 교체 |
| 교체 방법 | 다른 공인 CA(예: 무료 자동 발급 CA 포함)로 재발급 | 발급 후 서버 재시작·체인 확인 |
| 사내 장비·IoT | 자체 인증서 목록을 쓰는 장비 펌웨어 확인 | 제조사 업데이트 적용 |
오해하기 쉬운 포인트
| 오해 | 사실 |
|---|---|
| “자물쇠가 있으니 무조건 안전” | 자물쇠는 ‘도장이 진짜’라는 뜻일 뿐. 도장 원판이 새면 가짜도 자물쇠를 달 수 있어요. 그래서 이번처럼 원판을 통째로 무효화해요 |
| “해커가 인증기관을 털었다” | 털린 게 아니라 처음부터 약하게 생성된 키였어요. 그래서 공개된 인증서만으로 계산이 가능했죠 |
| “eMudhra 인증서 6천만 장이 전부 위험” | 문제는 중간 인증서 8개. eMudhra는 루트 키와 다른 중간 인증서는 무관하다고 했어요. 다만 크롬은 루트 하나를 제거하고 추가 검토 중이에요 |
| “한국 사용자와는 상관없다” | 가짜 인증서는 어떤 도메인이든 만들 수 있었어요. 그래서 국적과 무관하게 업데이트가 필요해요 |
| “브라우저 업데이트만 하면 다 끝” | 일반 사용자는 거의 끝. 하지만 서버·스크립트·IoT는 인증서 묶음 업데이트가 따로 필요해요 |
정리하면
| 누구 | 오늘 할 일 한 줄 |
|---|---|
| 일반 사용자 | 브라우저·OS 업데이트, 안드로이드는 재부팅. 인증서 경고는 무시하지 않기 |
| 개발자·서버 관리자 | ca-certificates·certifi·Go·Electron 등 갱신, 도커 이미지 재빌드, 시험 주소로 확인 |
| 사이트 운영자 | 인증 경로에 emSign ECC Root CA – G3가 있으면 10월 27일 전에 다른 CA로 교체 |
이번 사건은 ‘인터넷의 믿음’이 결국 숫자 하나를 얼마나 잘 숨기느냐에 달려 있다는 걸 보여 줬어요. 그 숫자가 4였다는 건 당황스럽지만, 제보부터 몇 시간 만에 주요 브라우저가 막아 낸 것도 사실이에요. 우리 몫은 단순합니다. 미뤄 둔 업데이트를 오늘 누르는 것, 그리고 경고 화면이 뜨면 ‘계속’ 대신 ‘뒤로’를 누르는 것이에요.