- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Fri, 12 Jan 2018 19:17:31 +0100
- To: Peter Thatcher <pthatcher@google.com>
- Cc: T H Panton <thp@westhawk.co.uk>, Cullen Jennings <fluffy@iii.ca>, Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <8cd944f4-46ae-724c-4c00-1a97024c7763@gmail.com>
Yes, I meant the same, "ice:" for remote candidates (either domain-name
or ip based)
Let me sum up an initial proposal:
When CSP is enabled (either via defautl-src or the connect-src header),
we create three white lists:
* stun servers: any stun server passed into the PC constructor on the
iceServers not matched by one entry on the list will be discarded
* turn servers: any turn server passed to the PC constructor on the
iceServers not matched by one entry on the list will be discarded
* remote candidates: any remote candidate passed to an PC (either on
the setRemoteDescription or addIceCandidate) not maching an entry on
the whitelist will be discarded
By default, all this three list are empty. That is, any service with CSP
turned on and no specific configuration for webrtc, will be protected as
no webrtc connections will be enabled.
To add entries to each list, we can use stun and turn urls and a new
"ice:" url schema for the remote ice candidates. A wildcard url would be
allowed to restrict the constrains for those willing to use it.
Examples:
Content-Security-Policy: connect-src https://example.com; -> No webrtc
connection enabled at all
Content-Security-Policy: connect-src https://example.com
stun:example.com turn:example.com ice:1.1.1.1; -> Stun and turn allowed
to example.con, but remote candidates not from 1.1.1.1 are disabled
Content-Security-Policy: connect-src https://example.com
stun:example.com turn:example.com ice:*; -> Stun and turn allowed to
example.con, any remote candidate is allowed (this is unsafe, but allowed)
Content-Security-Policy: connect-src https://example.com
stun:example.com turn:example.com; -> Stun and turn allowed to
example.con, but no remote ice candidates allowed (doesn't make much
sense, but allowed)
Content-Security-Policy: connect-src https://example.com
turn:example.com ice:turn.example.com; -> Only turn allowed to
example.con and remote candidates from example.com only
Best regards
Sergio
On 12/01/2018 18:14, Peter Thatcher wrote:
>
> I didn't mean "ice:" for ICE servers, I meant domain-name ICE
> candidates. But maybe "ice:" could work too. Either way would require
> IETF work.
>
>
> On Fri, Jan 12, 2018, 9:09 AM Sergio Garcia Murillo
> <sergio.garcia.murillo@gmail.com
> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
> So, a combination of stun, turn urls and a new "ice:" url?
>
> That may work, depending on the combination it may be insecure,
> but as long as the defaults are restrictive (i.e. whitelisting) we
> would be safe. We could even include an unsafe option "ice:*" for
> the ones willing to take the risk.
>
> Regards
> Sergio
>
> El 12/1/2018 17:44, "Peter Thatcher" <pthatcher@google.com
> <mailto:pthatcher@google.com>> escribió:
>
> Actually, as I pointed out on the other threads (why are there
> so many?), maybe domain-name-only remote ICE candidates and
> TURN servers and STUN servers with whitelisted domains might
> work. And that, while heavily disabled, would at least allow
> PCs to whitelisted servers.
>
>
> On Fri, Jan 12, 2018, 8:30 AM Sergio Garcia Murillo
> <sergio.garcia.murillo@gmail.com
> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
> I agree.
>
> That is why my original proposal was to disable webrtc if
> CSP it's in use.
>
> We could add an "webrtc" token for connect-src to enable
> it back knowing the risks.
>
> For what it seems, anything more fine grained would be
> difficult to get it working.
>
>
> Best regards
> Sergio
>
>
>
> El 12/1/2018 17:16, "Peter Thatcher" <pthatcher@google.com
> <mailto:pthatcher@google.com>> escribió:
>
> Why is this ICE-lite specific? A controlling ICE
> agent will begin sending data as soon as it had
> received a check response, regardless of whether or
> not it has received a check yet. And that happens
> for full clients as well.
>
> I think you need to go further and say something like
> "don't send data until you get a check", which is like
> a reverse consent check.
>
>
> But even that might not be good enough. You could,
> for example, convey information to the server simply
> by controlling the ports to which you send checks,
> which is driven by the adding of remote candidates,
> which is controlled by JS.
>
> Even if we could prevent that, there is probably a way
> to convey information by controlling the IP or port
> used for gathering server reflexive or relay addresses
> via STUN or TURN.
>
> How far down the rabbit hole of disabling things you
> want to go?
>
>
>
>
> On Fri, Jan 12, 2018, 3:04 AM T H Panton
> <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> wrote:
>
> In the call yesterday, I said I'd try and
> summarize the concerns that have been raised about
> 'Drive-by webRTC CSP' attacks.
>
> Content Security Policy on web pages allows a site
> developer to proscribe what their page can do.
> This is intended to mitigate the risks of XSS and
> other injection attacks.
>
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src
>
> This reduces exposure to included 3rd party
> scripts being tampered with at source
> e.g. if someone hacks
> https://webrtc.github.io/adapter/adapter-latest.js
> - the page may not function correctly, but it
> should not be able to send sensitive
> data to domains that aren't whitelisted in the CSP
> connect-src header.
>
> This prevents a web-font supplier from capturing
> the credit card data from your
> e-commerce site shopping forms.
>
> The connect-src explicitly covers websockets. It
> does not mention DataChannels or webRTC.
>
> In principle you might not think that matters,
> since in order to set up a data-channel
> you need to perform an SDP exchange, and that SDP
> exchange would have to go through
> a whitelisted server.
>
> It turns out in the case of ice-lite the browser
> does not verify that the remote party has
> ever seen it's SDP - ICE responses do not require
> the requester's ufrag or pass.
> This means that the malicious javascript does not
> need to send an answer to a
> cooperating server.
>
> So it would be possible to bury static SDP for an
> ice-lite offer in malicious javascript.
> The offer would point to a malicious server that
> implemented ice-lite on a fixed port
> (for example) and accepted data channels without
> checking the DTLS fingerprint.
>
> The javascript would apply this to a
> peerconnection and drop the generated answer in the
> bit-bucket.
>
> The malicious javascript can now inspect the page
> DOM and send all the form values it
> finds over a datachannel to the malicious server.
> Despite the fact that the conscientious developer
> had configured connect-src to mitigate this risk.
>
> At the heart of this is that ice-lite breaks the
> conceptual linkage between the 5 tuple and the
> page origin.
>
> Proposal:
> a) Ban ice-lite on pages with any CSP set
> c) add a allow-ice-lite CSP
> b) add a CSP turn-servers whitelist (to prevent
> leakage via the credentials)
> c) test plain ICE to make sure it fails if the far
> side sends no valid requests.
> d) ensure that any new ICE api's don't make this
> mistake (worse)
>
> Thanks to ibc@aliax.net <mailto:ibc@aliax.net> for
> starting the discussion and
> sergio.garcia.murillo@gmail.com
> <mailto:sergio.garcia.murillo@gmail.com> for
> pointing me at CSP connect-src:
> https://twitter.com/ibc_tw/status/949993145978245120
>
> P.S.
> As you will see in the twitter thread, this isn't
> specific to the datachannel - one can exfiltrate
> data over DTMF or G711 perfectly easily.
>
> Tim.
>
Received on Friday, 12 January 2018 18:17:54 UTC