mitmproxy adds --emudhra option
mitmproxy에 --emudhra 옵션 추가
mitmproxy가 유출된 eMudhra 인증기관(CA) 중간 인증서의 개인 키로 TLS 인증서를 서명하는 --emudhra 옵션을 추가했습니다. 취약한 인증서를 아직 신뢰하는 기기와 앱의 통신을 테스트할 때 쓰며, 인증서 고정이나 폐기 확인 여부에 따라 동작 범위가 달라집니다.
- 주제
에디터 노트
이 옵션의 효용은 취약한 인증서 체인을 여전히 신뢰하는 기기와 앱을 시험하는 데 있습니다. CA 키를 넣었다고 모든 TLS 트래픽이 보이는 것은 아닙니다. 댓글에서도 인증서 고정, 폐기 확인, 기기의 신뢰 저장소가 작동을 가를 조건으로 나왔고, 한 사용자는 d=4 키 하나로는 실패한 뒤 TLS용 키 여섯 개를 넣어 일부 기기에서만 가로채기에 성공했다고 전했습니다. 이 경험은 옵션이 실제 시험에 쓰였다는 사례지만 보편적인 성공을 입증하지는 않습니다. 댓글에서 iOS 기기의 폐기 상태가 서로 다르게 보였다는 보고도 나왔습니다. 원문 커밋은 특정 인증서 체인을 코드에 추가하고 EC 키 처리를 확장한 내용이며, 폐기 확인이나 신뢰 저장소의 상태를 보장하지 않습니다. 따라서 --emudhra는 영향받는 기기의 동작을 확인하는 도구로 보는 편이 정확합니다. emSign 외 AAA 경로도 필요하다는 댓글과 후속 변경 요청이 있었지만, 이 커밋에 포함된 기능과는 구분해야 합니다.
AI 요약
mitmproxy에 eMudhra 인증기관의 취약한 개인 키를 활용하는 --emudhra 옵션이 추가됐습니다. 커밋은 침해된 중간 CA 인증서와 교차 서명된 루트 인증서를 PEM 형식으로 포함하고, mitmproxy가 RSA뿐 아니라 타원곡선(EC) 개인 키도 처리하도록 인증서 관련 타입을 확장합니다. Hacker News의 mitmproxy 유지관리자는 옵션에 --emudhra를 전달하면 쓸 수 있다고 설명했으며, 기능은 12.3 릴리스에도 포함됐다고 밝혔습니다.
작동 방식과 범위
mitmproxy는 이 CA 키로 대상 호스트 이름에 맞춘 TLS 인증서를 서명해 프록시 연결에 사용합니다. 기기나 앱이 해당 인증서 체인을 신뢰하면 TLS 연결을 중간에서 살펴볼 수 있습니다. 댓글에서는 eMudhra의 취약한 키 여덟 개 가운데 두 개는 코드 서명용이고, 여섯 개가 TLS용이라는 설명이 나왔습니다. 한 사용자는 d=4 키만으로는 동작하지 않았고, TLS용 키 여섯 개를 넣은 자체 프록시로 일부 기기의 통신을 가로챘다고 보고했습니다. 이는 댓글 작성자의 시험 결과이며 모든 기기에서 동작한다는 뜻은 아닙니다.
인증서 고정(certificate pinning)을 쓰는 앱은 일반적인 신뢰 저장소에 CA를 추가해도 프록시 인증서를 거부할 수 있습니다. 기기가 인증서 폐기 목록(CRL)이나 온라인 인증서 상태 확인(OCSP)을 확인하는지, 해당 루트와 중간 인증서를 신뢰하는지도 결과에 영향을 줍니다. Hacker News의 한 댓글은 mitmproxy가 현재 emSign 루트 경로를 사용하며 AAA 루트 경로를 추가하는 별도 변경 요청도 있다고 전했습니다.
Hacker News 반응
- @tecleandor — 주변에 있는 구형 안드로이드 폰 앱의 통신을 살펴보는 데 유용하겠습니다. 인증서 고정을 쓰지 않기를 바랍니다.
- @selcuka — 안드로이드 폰에 직접 만든 CA를 설치하면 안 되나요?
- @j027 — 가능합니다. 다만 제가 기억하기로 Android 7부터 앱은 기본적으로 사용자 저장소를 신뢰하지 않습니다. 루트 권한으로 시스템 저장소에 넣거나 앱이 사용자 저장소를 신뢰하도록 패치해야 합니다.
- @cedws — 흥미로운 앱은 대부분 인증서를 고정합니다.
- @gkbrk — Frida로 고정을 해제하는 방법은 대개 꽤 쉽습니다.
- @cedws — 제가 관심을 둔 앱은 증명(attestation)과 리버스 엔지니어링 방지책으로 Frida를 막습니다.
- @DrammBA — 누군가의 보안 참사가 다른 사람의 기능이 되는 게 좋네요.
- @xp84 — 동의합니다. 이런 재난에서 그나마 쓸모를 찾아야죠. 암호 기술이 성공한 대가로 기업이 하드웨어와 소프트웨어를 사용자에게서 닫아버리는 건 안타깝습니다. 기능이라고 할 일은 아닙니다.
- @shrubble — 이 방법으로 스마트 TV와 제조사 사이의 통신을 엿볼 수 있다는 뜻인가요?
- @quotemstr — TV가 몇 년 이내에 나온 제품이 아니고, CRL을 확인하지 않으며, 아직 업데이트를 적용하지 않았다면요.
- @kevin_nisbet — 가능성은 있습니다. 제조사가 전체 루트 인증서를 갖추지 않았거나 자체 인증기관을 쓰거나 인증서 고정을 할 수도 있습니다.
- @sippingabonedry — 테스트 사이트에서 iOS가 위조 인증서 두 개를 아직 신뢰하는 것을 알아차린 사람이 또 있나요? 무슨 일이 있는지 정중히 묻고 싶습니다. 이 문제는 전혀 해결되지 않았습니다.
- @xuki — iOS 버전이 뭔가요? 제 27.0.1에서는 전부 폐기됐습니다.
- @sippingabonedry — 26.7.1에서는 인증서 체인 12개 중 두 개를 여전히, 그것도 일관성 없이 신뢰합니다. 모든 브라우저에서 같습니다. OCSP 조회가 실패하면 무시하는 방식(soft-fail) 때문일 수 있다고 추측합니다.
- @closetheloopdev — 침해된 eMudhra CA 키 여섯 개로 프록시를 만들었습니다. 커밋처럼 d=4 키 하나만 썼을 때는 작동하지 않는 듯했습니다. 여섯 개를 모두 추가하자 일부 기기에서 통신을 가로챌 수 있었습니다. 영향을 받는 IoT 기기를 시험하고 보호하려는 목적이었고, 프록시는 침해된 키가 아닌 새 TLS 연결로 트래픽을 전달했습니다.
- @CGamesPlay — 현재 커밋은 emSign 루트 경로를 쓰는 것 같습니다. AAA 루트 경로도 다른 상황에서 유용합니다. AAA 경로를 추가하는 변경 요청이 열려 있습니다.
- @mhils — 이 커밋이 Hacker News에 올라올 줄 알았다면 전체 통합을 한 번에 했을 텐데요. AAA 루트 경로를 추가하는 변경 요청은 https://github.com/mitmproxy/mitmproxy/pull/8503 입니다.
- @lambda — 프록시를 직접 설정하려고 했는데 바로 쓸 수 있게 돼서 좋네요.
원문: mitmproxy 커밋 / 번역·요약: Trawling