WebRTC 누출: 프록시 뒤에서도 실제 주소가 보일 수 있는 이유
WebRTC는 브라우저끼리 통화와 화면 공유를 위해 직접 통신할 수 있도록 존재합니다. 그러려면 자신에게 도달할 수 있는 주소를 알아내야 하는데, "WebRTC 누출"이 가리키는 것이 바로 이 탐색 과정입니다.
ICE 후보를 한 단락으로
페이지가 RTCPeerConnection을 만들고 오퍼를 시작하면 브라우저는 후보, 즉 다른 피어가 자신에게 닿을 수 있는 방법을 수집합니다. host 후보는 로컬 인터페이스 주소입니다. server-reflexive(srflx) 후보는 STUN 서버가 요청이 도착한 것으로 본 공인 주소입니다. relay 후보는 TURN 서버의 주소입니다. 각 후보는 주소가 담긴 텍스트 한 줄로 페이지에 전달되며, 그래서 통화가 한 번도 이루어지지 않아도 스크립트가 주소를 읽을 수 있습니다.
누출이 일어나는 곳
중요한 것은 srflx 후보입니다. 이를 얻기 위해 브라우저는 STUN 서버에 작은 UDP 패킷을 보내고, 서버는 자신이 본 주소를 회신합니다. HTTP 트래픽은 프록시를 거치는데 UDP 트래픽은 거치지 않는다면 STUN 서버는 실제 연결을 보게 되고, 페이지는 웹 서버가 본 주소와 다른 주소를 갖게 됩니다. 이 불일치가 전형적인 누출입니다. 진단 페이지는 두 주소를 비교해 이를 보여 줄 수 있습니다.
무엇이 일어나고 무엇이 일어나지 않는지 짚어 두겠습니다. 미디어는 캡처되지 않습니다. 마이크나 카메라 권한도 관여하지 않습니다. 패킷은 페이지가 지정한 STUN 서버로 가므로, 접속하는 다른 모든 서버와 마찬가지로 그 서버는 여러분의 주소를 봅니다.
브라우저가 바꾼 것
host 후보는 예전에는 192.168.1.23 같은 사설 LAN 주소를 노출했고, 이는 가정 네트워크를 핑거프린팅하는 데 쓸모가 있었습니다. 최신 브라우저는 이를 .local로 끝나는 무작위 생성 mDNS 이름으로 대체하므로, 페이지는 주소가 아니라 의미 없는 이름을 보게 됩니다. 진단 도구가 "브라우저에 의해 가려짐"이라고 보고하는 것은 이 후보들을 가리킵니다. Firefox와 Brave는 프록시 밖에서의 후보 수집을 막는 설정도 제공하며, 일부 확장 프로그램은 WebRTC를 완전히 차단합니다.
프록시에 안전한 구성
세 가지 접근법이 있으며 비용이 다릅니다. WebRTC를 비활성화하면 누출은 막히지만 WebRTC가 필요한 모든 사이트가 동작하지 않습니다. WebRTC가 프록시의 경로만 사용하도록 강제하면(일부 브라우저의 "프록시 안전" 모드) 프록시가 UDP나 TURN을 지원할 때 통화가 계속 동작하고, 그렇지 않으면 공인 후보가 아예 없습니다. WebRTC가 평소처럼 동작하게 두는 것은 시스템 수준 VPN처럼 프록시가 모든 트래픽을 운반할 때만 올바릅니다.
어느 쪽이 맞는지는 작업에 따라 다릅니다. 한 장소에 있는 것처럼 보여야 하는 격리된 브라우저 프로필이라면 규칙은 간단합니다. WebRTC가 노출하는 주소는 웹 서버가 보는 주소와 같아야 하고, 아니면 아예 없어야 합니다. 그 밖의 것은 특별한 도구 없이도 사이트가 알아챌 수 있는 모순입니다.
결과 읽는 법
진단은 몇 초 안에 관측한 후보를 보여 주고, 공인 후보가 있다면 페이지에 접속한 주소와 비교합니다. 일부 후보가 가려진 채 "노출 없음"이라면, WebRTC를 프록시 안에 가두는 브라우저에서는 정상적이고 건강한 결과입니다. 페이지의 주소와 다른 공인 주소가 보이면 그것이 고쳐야 할 대상입니다.
