- From: Jim Manico <jim.manico@owasp.org>
- Date: Tue, 1 Dec 2015 01:15:22 +0200
- To: Richard Barnes <rbarnes@mozilla.com>, 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: <565CD88A.3060401@owasp.org>
How about the many of the Tor endpoints being compromised? Does that
show a complete failure of Tor? I would say no.
http://www.ibtimes.co.uk/tor-anonymity-network-compromised-following-potential-raid-by-law-enforcement-agencies-1480620
Most folks who really care about this stuff use Tor and use TLS for all
services. And perhaps write services with secure code. And keep your
machines free of malware, etc, etc, etc. Depending on any one of these
technologies is not so helpful in 2015.
Aloha,
Jim
On 12/1/15 1:08 AM, Richard Barnes wrote:
> 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
>
>
--
--
Jim Manico
Global Board Member
OWASP Foundation
https://www.owasp.org
Join me in Rome for AppSecEU 2016
Received on Monday, 30 November 2015 23:16:21 UTC