W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: Websockets and connections to private IPs and localhost

From: Bob Lund <B.Lund@CableLabs.com>
Date: Thu, 19 Mar 2015 15:13:53 +0000
To: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <D1303F6C.4E618%b.lund@cablelabs.com>
We have an application where a LAN ws server address is passed to page 1
from internet site A. Page 2 from site A is loaded by a second device on
the same LAN. The two pages rendezvous at an internet ws server.  Page 2
is passed the LAN ws server address where page 1 and 2 rendezvous for
future communication. Sounds like this wouldn't work anymore, which is too
bad as it's a useful design pattern for in-home multi-screen apps.

Bob 

On 3/19/15, 2:46 AM, "Devdatta Akhawe" <dev.akhawe@gmail.com> wrote:

>Hi
>
>In https://code.google.com/p/chromium/issues/detail?id=378566, the
>blink team is planning on blocking all connections to private networks
>and localhost. This is unfortunate, because (as discussed in the bug)
>this breaks a bunch of applications. I was wondering: instead of
>cutting down all accesses outright, can we make a compromise in
>allowing websockets to connect?
>
>The websocket handshake is designed to not mistakenly allow access:
>instead, there are specific steps the servers have to take to agree to
>connect over websockets and so I don't see much security hardening
>achieved by blocking websockets. What do others think? (I am not sure
>this is even under the purview of w3c since I don't believe "block
>private networks" is a standard).
>
>Additionally, I think browsers should also allow websocket connections
>to localhost in a secure context because the browser can ensure that
>this never left the computer to get on the (untrusted) network. This
>part 2 definitely seems like part of MIX.
>
>cheers
>Dev
>
>full disclosure for those who didn't read the bug: Dropbox (my current
>employer) is also affected by this issue. That said, these opinions
>are mine and do not represent my employer's.
>
Received on Thursday, 19 March 2015 15:14:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC