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

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 01 Dec 2015 04:31:32 +0000
Message-ID: <CAEeYn8htKAjVC0JD5=OfkDSKwG38bV1Mz6xALHqAcFm=Pg0nVg@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>, Richard Barnes <rbarnes@mozilla.com>
Cc: Aymeric Vitte <vitteaymeric@gmail.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Let's keep this discussion civil, please.

The reasons behind blocking of non-secure WebSocket connections from secure
contexts are laid out in the following document:

http://www.w3.org/TR/mixed-content/

A plaintext ws:// connection does not meet the requirements of
authentication, encryption and integrity, so far as the user agent is able
to tell, so it cannot allow it.

If there is a plausible mechanism by which browsers could distinguish
external communications which meet the necessary security criteria using
protocols other than TLS or authentication other than from the Web PKI,
there is a reasonable case to be made that such could be considered as
potentially secure origins and URLs.  (as has been done to some extent for
WebRTC, as you have already noted)

If you want to continue this discussion here, please:

1) State your use cases clearly for those on this list who do not already
know them.  You want to "use the Tor protocol" over websockets?  To connect
to what?  Why?  Why is it important to bootstrap an application like this
over regular http(s) instead of, for example, as an extension or modified
user-agent like TBB?

2) Describe clearly why and how the protocol you propose to use meets the
necessary guarantees a user expects from an https page.

3) Describe clearly how the user agent can determine, before any
degradation in the security state of the context is possible, that only a
protocol meeting these requirements will be used.

Ad-hominem and security nihilism of the forms "TLS / PKI is worthless so
why bother trying to enforce any security guarantees" or "other insecure
configurations like starting with http are allowed, so why not allow this
insecure configuration, too" are not appropriate or a good use of anyone's
time on this list.  Please refrain from continuing down these paths.

thank you,

Brad Hill, as co-chair

On Mon, Nov 30, 2015 at 6:25 PM Florian Bösch <pyalot@gmail.com> wrote:

> On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes <rbarnes@mozilla.com>
> wrote:
>
>> 1. Authentication: You know that you're talking to who you think you're
>> talking to.
>>
>
> And then Dell installs a their own root authority on machines they ship,
> or your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor
> in the EC they managed to smuggle into the constants, or somebody combines
> a DNS poison/grab with a non verified (because piss poor CA) double
> certificate, or you hit one of the myriad of bugs that've plaqued TLS
> implementations (particularly certain large and complex ones that're
> basically one big ball of gnud which shall remain unnamed).
>
Received on Tuesday, 1 December 2015 04:32:12 UTC

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