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

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 05:46:05 UTC