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

“Secure against which threats?” is the question. TLS, with its stronger crypto, is more secure against an adversary that wants to read the content of your messages. ToR is more secure against an adversary that wants to detect that you visit a particular site, are associated with particular social media content, and get your real IP address to hunt you down. They are dramatically different adversaries, and different victim profiles, so comparing which is “more secure” is meaningless.

From: Brad Hill [mailto:hillbrad@gmail.com]
Sent: Monday, November 30, 2015 12:01 PM
To: Aymeric Vitte <vitteaymeric@gmail.com>; Web Applications Working Group WG (public-webapps@w3.org) <public-webapps@w3.org>
Cc: public-webappsec@w3.org
Subject: Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

I don't think there is universal agreement among browser engineers (if anyone agrees at all) with your assertion that the Tor protocol or even Tor hidden services are "more secure than TLS".  TLS in modern browsers requires RSA 2048-bit or equivalent authentication, 128-bit symmetric key confidentiality and SHA-256 or better integrity.    If .onion identifiers and the Tor protocol crypto were at this level of strength, it would be reasonable to argue that a .onion connection represented a "secure context", and proceed from there.  In the meantime, with .onion site security (without TLS) at 80-bits of truncation of a SHA-1 hash of a 1024 bit key, I don't think you'll get much traction in insisting it is equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte <vitteaymeric@gmail.com<mailto:vitteaymeric@gmail.com>> wrote:
Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web site is the app), or for more wide distribution from different sites
than the original app site via an iframe (very ugly way) or extracted as
a component (cool way, does not seem to be foreseen by anybody) with
user prompt/validation ("do you want to install application X?")
possibly running in background when needed in a sandboxed context with
service workers.

Le 25/11/2015 17:43, Aymeric Vitte a écrit :
>
>
> Le 20/11/2015 12:35, Richard Barnes a écrit :
>> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck <hanno@hboeck.de<mailto:hanno@hboeck.de>> wrote:
>>
>>>> It's amazing how the same wrong arguments get repeated again and
>>>> again...
>>>>
>> +1000
>>
>> All of these points have been raised and rebutted several times.  My
>> favorite reference is:
>>
>> https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay

>>
>>
>>
>
> You might not break the current internet but its future.
>
> Example: https://bugzilla.mozilla.org/show_bug.cgi?id=917829

>
> How do you intend to solve this? ie the case of an entity that just
> cannot have valid certificates and/or implements a secure protocol on
> top of an insecure one (ws here for Peersm project, the other party can
> be by design a "MITM" but we completely don't care per the secure
> protocol used, the MITM will not know what happens next)?
>
> Like WebRTC too, but there is an exception for that one, self-signed
> certificates are (by some luck) accepted.
>
> It's obvious that browsers will be used for new services involving those
> mechanisms in the future, like P2P systems as sketched here:
> https://mailman.stanford.edu/pipermail/liberationtech/2015-November/015680.html

>

--
Get the torrent dynamic blocklist: http://peersm.com/getblocklist

Check the 10 M passwords list: http://peersm.com/findmyass

Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org

Peersm : http://www.peersm.com

torrent-live: https://github.com/Ayms/torrent-live

node-Tor : https://www.github.com/Ayms/node-Tor

GitHub : https://www.github.com/Ayms