Opened 17 months ago

Last modified 16 months ago

#19026 new enhancement

Remove local LAN address ICE candidates

Reported by: dcf Owned by:
Priority: Medium Milestone:
Component: Obfuscation/Snowflake Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

ICE candidates can contain local LAN addresses as well as external addresses. For example, here's a redacted transcript from the Snowflake JS proxy:

a=candidate:4077567720 1 udp 2122260223 192.168.1.5 51282 typ host generation 0
a=candidate:8564102000 1 udp 1686052607 X.X.X.X 51282 typ srflx raddr 192.168.1.5 rport 51282 generation 0
a=candidate:3179889176 1 tcp 1518280447 192.168.1.5 52256 typ host tcptype passive generation 0

If it's possible, we should filter them out to prevent revealing more information than necessary. Serene and I guessed that they are only there for the case when both peers are in the same local network, but we're not sure about that.

Child Tickets

Change History (1)

comment:1 Changed 16 months ago by dcf

The WebRTC working draft touches on this issue:
https://www.w3.org/TR/2016/WD-webrtc-20160128/#revealing-ip-addresses

Even without WebRTC, the Web server providing a Web application will know the public IP address to which the application is delivered. Setting up communications exposes additional information about the browser’s network context to the web application, and may include the set of (possibly private) IP addresses available to the browser for WebRTC use. Some of this information has to be passed to the corresponding party to enable the establishment of a communication session.

Revealing IP addresses can leak location and means of connection; this can be sensitive. Depending on the network environment, it can also increase the fingerprinting surface and create persistent cross-origin state that cannot easily be cleared by the user.

A connection will always reveal the IP addresses proposed for communication to the corresponding party. The application can limit this exposure by choosing not to use certain addresses using the settings exposed by the RTCIceTransportPolicy dictionary, and by using relays (for instance TURN servers) rather than direct connections between participants. One will normally assume that the IP address of TURN servers is not sensitive information. These choices can for instance be made by the application based on whether the user has indicated consent to start a media connection with the other party.

Mitigating the exposure of IP addresses to the application itself requires limiting the IP addresses that can be used, which will impact the ability to communicate on the most direct path between endpoints. Browsers are encouraged to provide appropriate controls for deciding which IP addresses are made available to applications, based on the security posture desired by the user. The choice of which addresses to expose is controlled by local policy (see RTCWEB-IP-HANDLING for details).

The latter link is all about handling IP addresses with respect to privacy:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/?include_text=1

Note: See TracTickets for help on using tickets.