W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2015

RE: CSP/CORS (Re: ICE exposes 'real' local IP to javascript)

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Wed, 4 Feb 2015 11:53:52 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <532A6DC6F9C115439C41705FF73D13871D1B6878@ESESSMB209.ericsson.se>


> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: den 4 februari 2015 07:21
> To: Harald Alvestrand
> Cc: public-webrtc@w3.org
> Subject: Re: CSP/CORS (Re: ICE exposes 'real' local IP to javascript)
> 
> I can't think of any application of CSP or CORS in this context.  We already
> have consent mechanisms equivalent to CORS in the form of ICE.
> And CSP serves only as a voluntary reduction in capabilities on the part of a
> site.
[GAPE:]
Just to make it clear- this is not [intended] as a discussion about the ICE/consent mechanism. This is as far as I understand it, another matter; which tools do the well-behaved web site owners have available to have a defense-in-depth in case the web app is compromised, e.g. by content injection or simply poorly written?

This is separate from the VPN-case, also of concern.

Regards
Göran

> 
> On 4 February 2015 at 16:45, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> > Limiting to Webrtc and changing subject....
> >
> > On 02/03/2015 09:41 PM, Göran Eriksson AP wrote:
> >> Inline
> >>
> >>>
> >>> 2) Speaking with my WebRTC hat on: IP addresses have to be surfaced
> >>> at the API as long as the other side needs to try to send packets to these
> interfaces.
> >>> We can't obfuscate them or encrypt them because they have to be
> >>> communicated to the other party, through channels that aren't in the
> >>> WebRTC spec.
> >> [GAPE:] OK, sure, that would fit in IETF. But CSP/CORS are within the W3C
> scope, right? For instance, consider using Web platform mechanisms such as
> CSP; that should be in the scope of the W3C draft, right? Something along the
> lines Web site admin using CSP/CORS to have the UA 'check' the
> 'find&connect' proxy origin (especially when it is not in the same 'origin' as
> that of the parent document)?
> >
> > Can you explain in more detail what you mean here - what exactly are
> > you suggesting be checked with CSP/CORS?
> >
> > As far as I understand, if the "attack" is like the "you have this IP
> > address" Web pages we've seen, all the resources that the page needs
> > access to are either wide open or under the control of the "attacker"
> > - and the user has already performed the "engagement gesture" - he
> > clicked on the link to the page.
> >
> > CSP/CORS is, I believe, intended to make sure a page doesn't reach out
> > to resources outside what it is supposed to have access to - but in
> > the "you have this IP address" page, all the resources it needs access
> > to are (potentially) controlled by the page's author - so even if we
> > had protocol details to verify access, what is it that we would be
> > using CSP/CORS to check against?
> >
> > If there are mechanisms that are relevant, I think I need some more
> > explanation before I get what they are.
> >
> >
> >
> >
> >

Received on Wednesday, 4 February 2015 11:54:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC