Lobsters

Protecting Firefox users following the compromise of eMudhra intermediate certificates

eMudhra 중간 인증서 침해에 대응해 Firefox 사용자를 보호합니다

Mozilla는 eMudhra 중간 인증서 8개의 개인 키가 유출됐다는 신고를 받고 Firefox의 OneCRL에 해당 인증서를 차단 목록으로 배포했습니다. 표준 설정을 사용하는 Firefox에는 신고 후 3시간 안에 배포를 마쳤으며, 일부 사용자와 다른 Mozilla 인증서 저장소 이용자를 위한 추가 업데이트도 내놨습니다.

에디터 노트

Firefox는 OneCRL로 브라우저 사용자를 빠르게 보호했고 NSS 루트 목록도 갱신해 OneCRL을 받지 않는 일부 애플리케이션까지 범위를 넓혔습니다. 다만 자체 인증서 저장소를 쓰거나 폐기 정보를 제때 받지 못하는 클라이언트는 별도로 대응해야 합니다. 댓글의 Android 테스트 실패 사례와 Mozilla 관계자의 설명은 배포가 모든 사용자에게 같은 방식으로 적용되지 않을 수 있음을 보여줍니다. 댓글에서 거론된 한 바이트 개인 키 주장은 Mozilla 공지로 확인되지 않으며, 원문은 침해 사실과 조치만 공개했습니다. CT 로그 차단이 공격 인증서의 기록을 어렵게 한다는 우려도 댓글의 해석입니다. 공개된 정보만으로는 유출 경위와 실제 악용 여부를 판단하기 어렵습니다. 현재 확인된 대응의 범위는 Firefox의 OneCRL 차단과 NSS 루트 제거이며, 다른 TLS 구현의 폐기 처리 방식은 각 소프트웨어가 어떤 신뢰 저장소와 업데이트 경로를 쓰는지에 달려 있습니다.

AI 요약

Mozilla는 10월 17일 20시 6분(UTC)에 eMudhra 중간 인증서 8개에 연결된 개인 키가 유출됐다는 신고를 받았습니다. 해당 키를 가진 공격자는 자신이 관리하지 않는 웹사이트의 HTTPS 인증서를 위조할 수 있습니다. 사용자의 연결을 가로챌 수 있는 공격자는 위조 인증서로 웹사이트를 사칭하고 통신 내용을 읽거나 바꿀 수 있습니다.

Mozilla 엔지니어들은 중앙 폐기 인증서 목록인 OneCRL에 해당 인증서를 추가해 Firefox에서 차단했습니다. 이 보호 조치는 사용자가 Firefox를 업데이트하거나 재시작하지 않아도 전달됩니다. 신고를 받은 지 3시간이 채 지나지 않은 22시 59분까지 표준 설정을 사용하는 모든 Firefox 사용자에게 OneCRL 배포를 마쳤다고 Mozilla는 밝혔습니다.

추가 업데이트와 적용 범위

Mozilla는 사용자 지정 설정 때문에 OneCRL 업데이트를 받지 못한 소수의 사용자를 위해 Firefox 158.0.1(Desktop 및 Android)과 Firefox ESR 115.43.1, 153.5.1을 배포했습니다. NSS 3.131.1에서는 문제가 된 중간 인증서에 서명한 루트 인증서를 신뢰 목록에서 제거했습니다. Firefox는 이미 OneCRL로 보호되지만, 이번 NSS 업데이트는 OneCRL을 받지 않는 Mozilla 인증서 저장소 이용 애플리케이션에도 보호를 확장합니다.

Mozilla는 더 많은 정보를 공개할 수 있게 되면 공유하겠다고 밝혔습니다. 댓글에는 Firefox Android에서 테스트 사이트 접속이 계속된다는 보고가 있었고, Mozilla 관계자는 Android가 OneCRL을 덜 안정적으로 받는 알려진 문제가 있다고 답했습니다. 댓글 참여자들은 Play Store에서 앱을 다시 확인하거나 휴대전화를 재시작한 뒤 문제가 해결된 사례를 전했습니다. 이는 개별 사용자 경험이며 모든 기기에서 같은 원인이나 해결책이 확인됐다는 뜻은 아닙니다.

인증서 폐기와 신뢰 저장소

댓글에서는 브라우저와 앱마다 인증서 폐기 정보를 받는 방식이 다르다는 점도 논의됐습니다. 일부 앱은 운영체제의 인증서 저장소 대신 자체 저장소를 사용합니다. 한 댓글은 이런 소프트웨어를 관리한다면 루트 인증서나 가능하다면 중간 인증서를 제거하라고 권고했습니다. Go의 TLS 처리 계층에서 중간 인증서를 차단하는 방안을 두고도 의견이 엇갈렸습니다. 한쪽은 운영체제의 루트 저장소만으로는 중간 인증 기관을 차단하기 어려워 TLS 계층에 대응 기능이 필요하다고 설명했고, 다른 쪽은 언어별 런타임에 처리가 흩어지면 인증서 관리가 더 분절될 수 있다고 지적했습니다.

한 댓글은 Certificate Transparency 로그 구현 두 곳이 해당 인증 기관의 인증서 기록을 막았다고 주장하며, 이 조치가 위조 인증서 기록을 막는 동시에 실제 공격에 쓰인 인증서를 로그에서 찾기 어렵게 만들 수 있다고 우려했습니다. 또 다른 댓글은 유출된 개인 키 값이 한 바이트 수준이라는 주장을 전했지만, 해당 내용은 댓글에서 나온 주장입니다. Mozilla 공지 본문은 키가 유출됐다고만 밝혔으며 유출 경위나 키 값은 공개하지 않았습니다.

Lobsters 반응

  • @nullenvk — 중간 인증 기관이 유출됐다면 PS5 같은 게임 콘솔을 mitmproxy로 중간자 공격할 수 있다는 뜻입니다. 콘솔 해커들이 신나겠네요. 저도 신나겠습니다. 해킹이 절실한 오래된 중국산 카메라도 몇 대 있습니다.
    • @yorickpeterse — Eufy C10을 클라우드에서 떼어낼 방법을 몇 달째 고민하고 있습니다. Eufy 청소기에는 Valetudo 같은 도구가 사실상 없고, 적어도 C10에는 없습니다. 이번 일로 조금 쉬워질지도 모르겠습니다.
  • @freddyb — 테스트 페이지는 https://emudhra.we-have-a-problem.com/ 입니다.
    • @gavinmorrow — Apple 기기는 어제인 19일에 패치됐다고 나오는데 제 iPhone은 테스트에 실패합니다. Mac은 Firefox와 Safari에서 모두 통과합니다. 이상하네요.
    • @misty — 업데이트가 없다고 나오는 iOS 18.7.8을 쓰는데 제 휴대전화는 테스트를 통과합니다. 운영체제 업데이트와 별도로 작동하는 업데이트 방식이 있는 것 같습니다. 사용자마다 배포 시점이 다를 수도 있겠네요.
    • @ThinkChaos — 네, Background Security Improvements입니다.
    • @trousers — 단계적 배포일 수 있겠네요. xprotect와 softwareupdate는 모두 최신이라고 나오는데 저는 테스트에 실패합니다. macOS GoldenGate를 쓰고 있고 최신 상태라고 나오네요.
    • @ralfj — 제 Android용 Firefox는 테스트에 실패합니다. 사이트에 연결되네요. CRL을 사용하지 않나요?
    • @freddyb — Firefox Android는 CRL을 덜 안정적으로 받는 알려진 문제가 있습니다. Play Store를 강제로 새로고침해 앱 전체 업데이트를 확인하면 해결될 수도 있습니다. 조사하고 있습니다.
    • @strugee — 참고로 빌드 날짜가 2026-10-20T09:59:29인 Firefox Nightly Android도 실패합니다. 즉 사이트에 연결됩니다. 빌드 날짜상 최신이어야 할 것 같은데, 원하시면 버그를 신고하겠습니다.
    • @chc4 — Play Store에서 방금 업데이트한 빌드 날짜 2026-10-19T18:58:56의 Firefox Mobile 158.0.1을 쓰는데도 테스트 사이트에 연결됩니다. 업데이트: 휴대전화를 재시작하니 해결됐습니다.
  • @freddyb — 요약하면 운영체제 인증서 저장소를 쓰지 않는 소프트웨어를 관리한다면 루트 인증서나 가능하면 중간 인증 기관을 제거하세요. 그렇지 않다면 업데이트할 때입니다.
  • @agwa — 차단된 인증 기관이 발급한 Certificate Transparency 인증서 목록을 올립니다. 악성 인증서라기보다는 테스트용으로 보이며, 첫 인증서의 DNS 이름을 보면 누가 문제를 발견했는지 짐작할 수 있습니다. 우려스러운 점은 어제 Certificate Transparency 로그 구현 두 곳이 해당 기관의 인증서 기록을 막았다는 것입니다. 개인 키가 완전히 유출됐을 가능성을 시사하며, 위조 인증서로 로그가 도배되는 일을 막으려는 조치일 수 있습니다. 하지만 실제 공격에 쓰인 위조 인증서를 기록할 곳도 사라집니다. CT를 강제하는 클라이언트는 로그에 없는 인증서를 받아들이지 않겠지만, CT를 강제하지 않는 클라이언트는 공격받을 수 있습니다.
    • @dzwdz — orange 사이트의 @q3k 댓글을 보면 인증서 위조가 꽤 쉬워 보입니다. curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221'을 실행했더니 정말 되네요. 재미있는 CTF 문제입니다. 덧붙이면 개인 키는 4라는 주장입니다.
    • @kevincox — XKCD가 문자 그대로 예언할 줄 누가 알았겠어요. xkcd: Random Number.
  • @fs111 — 이 문제가 프로그래밍 언어의 표준 라이브러리에서 처리된다는 점이 매우 놀랍습니다. 인증서 폐기가 인터넷에서 골칫거리인 건 알지만, 이런 일이 벌어졌다면 정말 큰 문제가 있었던 것 같습니다.
    • @jtdowney — Go 프로그램은 프로그래밍 방식으로 TLS를 쓰는 전형적인 사례입니다. CT 로그나 다른 인터넷 기반 보호를 확인하기 어려운 경우가 많으니, 침해된 중간 인증 기관을 차단할 방법으로는 이게 가장 낫습니다. 보통은 루트 인증 기관을 제거하지만 운영체제는 루트 저장소에서 루트만 신뢰 해제할 수 있습니다. 이 기능은 TLS 스택에 필요합니다. Go에서는 TLS 스택과 언어 런타임이 같은 곳에 있을 뿐입니다.
    • @aae — fs111이 운영체제 업체나 패키지 관리 시스템이 맡을 일이라고 말하는 것 같습니다. 그래도 인증서 저장소는 복잡하네요.
    • @jtdowney — Go 프로그램에서는 운영체제가 중간 인증 기관을 신뢰하지 않게 만들 수 없습니다. 루트 신뢰 저장소에서 루트를 제거하는 것만 가능합니다.
    • @fs111 — 이렇게 하면 더 분절될 것 같습니다. 이제 한 프로그래밍 언어는 런타임에서 처리하고 나머지는 그렇지 않게 됩니다. 제 생각에는 별로 해결이 되지 않습니다.
    • @fanf — 브라우저가 아닌 TLS 클라이언트의 인증서 폐기 확인 문제는 upki가 해결책이어야 합니다. 하지만 아직 새 기술이고 표준 인프라의 일부로 자리 잡지 못했습니다.

원문: Mozilla Security Blog / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗