Android 17, 인증서 투명성 기본 적용으로 사용자 정의 CA 차단

AI 요약

Android 17은 API 37을 대상으로 하는 앱에서 시스템 신뢰 인증서에 Certificate Transparency(CT)를 기본 요구합니다. CT 정보가 없는 인증서는 시스템 저장소의 CA가 서명했더라도 앱이 신뢰하지 않습니다. 자체 인증 기관(CA)을 이용해 HTTPS 트래픽을 가로채는 프록시, 보안·개인정보 연구, 앱 디버깅과 리버스 엔지니어링 도구가 영향을 받습니다.

Android의 CA 설정 제한

Android 7(API 24)은 사용자가 설치한 CA를 앱이 기본적으로 신뢰하지 않도록 바꿨습니다. 앱이 명시적으로 허용하지 않으면 사용자 저장소의 CA를 무시합니다. Android 11(API 30)은 사용자에게 CA 설치를 요청하는 기능도 막았습니다. Android 14(API 34)는 시스템 CA 저장소를 Conscrypt APEX 모듈로 옮겼습니다. 루팅 기기에서도 단순한 설정 변경으로 CA를 바꾸기 어려워졌고, 실행 중인 프로세스마다 인증서를 다시 마운트하는 우회 방법이 필요해졌습니다.

글쓴이는 CA 신뢰가 온라인 연결의 보안을 좌우하므로 일반 사용자의 설정을 제한하는 취지는 이해할 수 있다고 설명합니다. 다만 사용자가 자신의 기기에서 명시적으로 허용하고 알림을 받는 방식까지 막으면 보안 연구와 앱 동작 감사가 어려워진다고 지적합니다. 사용자 저장소의 CA는 앱 대부분이 신뢰하지 않아 실용성이 낮고, 결국 시스템 저장소를 수정하려면 루팅과 복잡한 스크립트에 의존하게 됩니다.

Android 17에서 요구하는 CT

CT는 도메인 인증서가 발급된 사실을 공개 로그에 기록해 부정 발급을 발견하도록 돕는 체계입니다. 인증 기관(CA)이 인증서를 로그에 제출하면 로그는 서명된 타임스탬프인 SCT(Signed Certificate Timestamp)를 돌려줍니다. 서버 인증서에 SCT를 넣으면 클라이언트는 신뢰하는 로그가 발급 사실을 기록했다는 점을 확인합니다. DigiNotar 침해 사건처럼 공격자가 악성 인증서를 발급받는 일을 감시하려는 목적입니다.

문제는 개인이나 조직이 자체 CA로 발급한 인증서는 공용 로그에 기록되지 않는다는 점입니다. 로컬 네트워크 디버깅, 자체 서명 서버, MitM 프록시에서 생성한 인증서에는 SCT가 없으므로 CT를 요구하는 앱이 연결을 거부합니다. 글에 따르면 이 정책은 Android 17에서 실행되며 API 37을 대상으로 하는 앱에 적용됩니다. API 37 대상 지정은 2027년 8월부터 Play Store 게시 조건이 될 예정이라, 시간이 지나며 영향을 받는 앱이 늘어날 것으로 설명합니다.

HTTP Toolkit의 자체 CT 로그 우회

글쓴이는 HTTP Toolkit에 자체 CT 로그를 만드는 방식을 적용했습니다. 로컬 CA가 발급한 인증서를 공개 로그에 올리면 사용자가 방문한 도메인이 개인 식별자와 연결돼 공개될 수 있으므로, 인증서 내용을 실제로 공개하지 않고 SCT만 발급하는 로그를 구성합니다. CT 명세에는 로그가 인증서를 실제로 포함했는지 확인하는 절차가 있지만, 글쓴이는 클라이언트가 일반적으로 이를 확인하지 않는다고 설명합니다. 로그 운영자가 발급한 SCT를 인증서에 붙이고, 로그 설정을 기기에 신뢰하도록 등록하는 방식입니다.

절차는 세 단계입니다. 먼저 CA 인증서에서 두 CT 로그 운영자 ID와 키 쌍을 파생합니다. 다음으로 인증서 템플릿을 만들고 SCT를 생성해 인증서에 삽입한 뒤, 평소처럼 CA로 서명합니다. 마지막으로 기기의 기존 CT 로그 설정을 읽고 CA에 맞는 Android 설정을 만든 다음, 세 가지 로그 설정 위치에 추가합니다. HTTP Toolkit은 CA 인증서 주입에 쓰는 임시 마운트 방식을 사용하므로 재부팅하면 설정이 사라집니다. 로그 수는 인증서 유효기간에 따라 달라집니다.

이 구현에는 X.509 인증서 생성과 로그 운영자 설정이 필요하며, 각 도구가 같은 작업을 구현해야 합니다. 글쓴이는 이번 변경이 개인 CA를 의도적으로 차단하려는 조치는 아니라고 봅니다. CT는 부정 발급을 막기 위한 기능이지만, 로컬 CA 사용자를 지원하는 절차 없이 배포돼 디버깅과 연구가 영향을 받는다는 설명입니다. 사용자 CA를 앱이 기본 신뢰하도록 개선해 달라는 Android 버그 트래커 요청은 500표가 넘었지만, 6년 동안 진전이 없었다고 덧붙입니다. 글은 2028년 무렵 Merkle Tree Certificates가 도입되면 인증서 인프라가 다시 바뀌고 사용자 정의 CA도 추가로 영향을 받을 수 있다고 전망합니다.

Reddit 반응

• @u/DDFoster96 — 로컬 사용자 정의 CA를 쓰는 기업은 어떻게 관리하나요? Android와 Chrome을 쓰지 않나요, 아니면 20년 전보다 이런 방식이 덜 흔해졌나요?
  • @u/Pantsman0 — Chrome Enterprise를 쓰고 CA 인증서를 함께 배포합니다. MDM으로 Android 기기에 CA 인증서를 푸시하는 방식도 과거에는 잘 작동했습니다.

원문: HTTP Toolkit / 번역·요약: Trawling