- From: Richard Barnes <rbarnes@mozilla.com>
- Date: Mon, 30 Nov 2015 20:38:04 -0500
- 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>
- Message-ID: <CAOAcki8osF3--kvRA_jMQMjL4EHtcm3HO_oH_kgZL3AYjK8bug@mail.gmail.com>
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