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: Richard Barnes <rbarnes@mozilla.com>
Date: Mon, 30 Nov 2015 20:38:04 -0500
Message-ID: <CAOAcki8osF3--kvRA_jMQMjL4EHtcm3HO_oH_kgZL3AYjK8bug@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: Brad Hill <hillbrad@gmail.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Nov 30, 2015 at 8:35 PM, Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> What are you talking about?
>
> The logjam attack just shows that you (spec security experts of major
> internet companies) are incompetent, or just knew about it.
>
> You don't know Tor "plenty well", I am not referring at all to hidden
> services, the fb case, or the ridiculous related case of a https cert
> over a .onion
>
> And for WebRTC which "requires the website to specify the key
> fingerprint of the remote party, so you're secure against any attacker
> besides the website", this is a really funny (not to say completely
> stupid) solution involving a "website"
> (https://github.com/Ayms/node-Tor#security), which shows again that you
> are completely missing my point, a "website" is not the future and web
> apps must be able to work without a "website", so with entities that
> cannot have valid certificates.
>
> Maybe some projects like letsencrypt should study the case.
>
> Let's stop talking about Tor, please just explain why ws cannot be used
> with https.
>

Because ws doesn't meet the security criteria laid out in the Mixed Content
spec.

https://w3c.github.io/webappsec-mixed-content/#intro





>
> Le 01/12/2015 00:08, Richard Barnes a écrit :
> > On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte <vitteaymeric@gmail.com
> > <mailto:vitteaymeric@gmail.com>> wrote:
> >
> >     You must be kidding, the logjam attack showed the complete failure of
> >     TLS
> >
> >
> > Sure, protocols have bugs, and bugs get fixed.  The things we require
> > for HTTPS aren't even design goals of Tor.
> >
> >
> >
> >     and your 1/2/3 (notwithstanding the useless discussions about CAs &
> >     co), which does not apply to the Tor protocol that you don't know
> >     apparently but that fulfills 1/2/3
> >
> >
> > I know Tor plenty well.  It's good for what it's designed for (e.g.,
> > anonymity), but it's not designed to meet the requirements of HTTPS.
> >
> > You may be interested in this Tor blog post that points out some
> > advantages of doing HTTPS over Tor:
> >
> >
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs
> >
> >
> >
> >     I am not a Tor advocate, this is just an example illustrating why
> there
> >     are no reasons to forbid ws with https, and ws with https with
> service
> >     workers, and ws with https with future things, do you think that
> >     browsers will continue to discuss in the future with good old
> entities
> >     tied to a good old domain with a good old certificate?
> >
> >     Then what about WebRTC and DTLS self-signed certificates that the
> web is
> >     trying to secure by some strange ways?
> >
> >
> > You seem to be missing the fact that WebRTC has additional security
> > layers on top of the certificates.  The WebRTC connection process
> > requires the website to specify the key fingerprint of the remote party,
> > so you're secure against any attacker besides the website.  And if you
> > don't trust that site, there's an identity layer that can provide
> > additional authentication.
> >
> > https://w3c.github.io/webrtc-pc/#sec.identity-proxy
> >
> > --Richard
> >
> >
> >
> >
> >
> >     Le 30/11/2015 22:45, Richard Barnes a écrit :
> >     >
> >     >
> >     > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <
> vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>
> >     > <mailto:vitteaymeric@gmail.com <mailto: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>
> >     <mailto:vitteaymeric@gmail.com <mailto:vitteaymeric@gmail.com>>
> >     >     > <mailto:vitteaymeric@gmail.com
> >     <mailto:vitteaymeric@gmail.com> <mailto: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>
> >     <mailto:hanno@hboeck.de <mailto:hanno@hboeck.de>>
> >     >     >     <mailto:hanno@hboeck.de <mailto:hanno@hboeck.de>
> >     <mailto: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://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://github.com/Ayms/torrent-livenode-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
>
Received on Tuesday, 1 December 2015 01:38:48 UTC

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