- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 01 Dec 2015 04:31:32 +0000
- 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>
- Message-ID: <CAEeYn8htKAjVC0JD5=OfkDSKwG38bV1Mz6xALHqAcFm=Pg0nVg@mail.gmail.com>
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:14 UTC