8월 4일 보안 연구팀 Mysk는 iOS·macOS의 WebKit 기반 프록시 브라우저에서, 설정한 프록시를 거치지 않는 네트워크 경로 세 가지를 발견했다고 공개했다. 대상은 일반적인 페이지 요청만이 아니다. DNS 사전 조회, 패스키의 관련 출처 검증, 저지연 통신용 WebTransport가 각각 다른 실행 경로를 만들며, 이때 사이트는 프록시 주소 대신 기기의 실제 DNS 서버 또는 실제 IP 주소를 관찰할 수 있다는 설명이다.
이 이슈가 중요한 이유는 프록시 설정의 약속이 “브라우저가 만드는 모든 연결”처럼 들리기 쉽기 때문이다. WebKit의 WKWebsiteDataStore.proxyConfigurations는 iOS 17·macOS 14부터 앱 단위로 웹 트래픽을 프록시로 보내는 기반 API다. 하지만 연결을 여는 주체가 페이지 로더가 아니라 운영체제 자격증명 서비스이거나, 별도 네트워크 경로를 만드는 기능이면 그 설정의 경계 밖으로 나갈 수 있다. iOS의 모든 브라우저가 WebKit을 사용해야 하는 구조에서, 이 경계는 특정 앱 하나의 구현 문제가 아니라 프록시 브라우저라는 제품 유형의 설계 문제다.
프록시를 켰는데 DNS 서버가 왜 보일 수 있나
DNS 사전 조회는 페이지가 나중에 쓸 도메인을 미리 해석해 연결을 빠르게 시작하려는 기능이다. 웹 페이지가 <link rel="dns-prefetch">를 넣으면 WebKit은 해당 호스트 이름을 기기의 일반 DNS 경로로 질의한다고 Mysk는 설명한다. 방문자마다 다른 하위 도메인을 넣어 둔 서버는 자신의 권한 DNS 서버에서 그 질의를 볼 수 있으므로, 프록시가 아니라 방문자의 실제 네트워크에서 온 요청임을 구별할 수 있다.
이 경로는 페이지마다 태그가 있을 때만 실행된다. 그래서 일부 사이트에서만 DNS 누출처럼 보였다는 최초 제보도 설명된다. 데스크톱 Safari에는 오래전부터 있던 기능이지만 iOS에서는 iOS 26.0부터 dns-prefetch가 활성화됐다고 연구팀은 정리했다. 속도를 위한 미리 조회가 프록시의 관점에서는 식별 가능한 별도 요청이 된 셈이다.
패스키 검증과 WebTransport는 실제 IP를 어떻게 드러내나
WebAuthn의 Related Origin Requests는 한 조직이 소유한 여러 도메인에서 하나의 패스키를 쓰게 하는 절차다. 페이지의 출처와 rpId가 다르면 클라이언트는 https://<rpId>/.well-known/webauthn 파일을 가져와 허용된 출처인지 확인한다. Mysk의 분석에 따르면 WebKit은 이 의식을 운영체제 자격증명 서비스에 맡기고, 이 서비스가 앱의 프록시 구성을 모른 채 기기에서 HTTPS 요청을 낸다. 조건부 중재를 사용하면 사용자 인터페이스가 뜨지 않아도 이 검증 요청이 발생할 수 있다. 이 기능은 iOS 18.0부터 제공됐다.
WebTransport는 HTTP/3와 QUIC 위에서 여러 독립 스트림과 데이터그램을 제공하는 저지연 통신 API다. new WebTransport(url) 호출은 WebKit이 세션 프록시를 전달하지 않는 별도 QUIC 연결을 만들며, 목적지 서버에는 기기의 실제 IP가 보인다는 것이 이번 보고의 요지다. WebTransport는 iOS 26.4에서 공개됐다. 즉 패스키와 실시간 통신처럼 사용자가 편의 기능으로 인식하는 API가, 프록시 제품에는 네트워크 경계 검사 대상이 된다.
iCloud Private Relay에도 같은 선이 그어진 이유
iCloud+의 Private Relay는 Safari 웹 트래픽과 DNS 질의를 두 개의 릴레이로 나눠, 어느 한 사업자가 사용자와 방문 사이트를 함께 알지 못하게 설계한 기능이다. 그러나 이번 세 연결은 WebKit의 표준 페이지 로딩 경로 밖에서 만들어진다. Mysk는 그래서 DNS 사전 조회, 운영체제 자격증명 서비스의 검증 요청, WebTransport 연결이 Private Relay의 프록시 경로에도 들어가지 않는다고 밝혔다.
여기서 구분해야 할 것은 보호 기능의 이름보다 트래픽을 실제로 터널링하는 범위다. 보고서는 VPN이 기기 전체 네트워크 트래픽을 시스템 수준에서 터널링하므로 이 세 문제의 대상이 아니라고 설명한다. 반대로 앱 안의 프록시나 Safari 전용 릴레이를 선택했다면, 페이지를 여는 과정 밖에서 새 연결을 만들 수 있는 기능까지 제품이 어떻게 다루는지 봐야 한다.
브라우저 제품은 기능을 끄는 대신 선택권을 남겼다
Mysk의 Psylo 1.3.1은 dns-prefetch 힌트를 차단하고 WebTransport와 WebAuthn을 기본 비활성화했다. 패스키와 WebTransport가 필요한 사이트에서는 사일로별 토글로 다시 켤 수 있게 했다. 이 대응은 프록시 브라우저가 단지 프록시 주소를 넣는 제품이 아니라, 페이지·운영체제·전송 계층이 만드는 연결을 모두 목록화하고 기능별로 정책을 적용해야 한다는 사실을 보여 준다.
사용자에게 남는 질문도 단순하다. “이 브라우저가 프록시를 쓰는가”보다 “내가 여는 사이트가 어떤 API로 추가 연결을 만들 수 있고, 그 연결까지 같은 경로에 묶이는가”를 물어야 한다. IP를 감추는 기능의 신뢰도는 주소 하나를 바꾸는 데서 끝나지 않고, 예외 경로를 얼마나 적게 남겼는지에서 결정된다.
출처: Mysk Blog, “IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay”; Apple Support, “About iCloud Private Relay”