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

On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
>

HTTPS gives you the following essential properties:
1. Authentication: You know that you're talking to who you think you're
talking to.
2. Confidentiality: Nobody else can see what you're saying
3. Integrity: Nobody else can interfere with your communications

Show me another protocol that achieves those properties, and maybe we'll
have something to talk about.  Tor doesn't.

--Richard


Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
>
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
>
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > 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
> >
>
> --
> 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
>
>