[tor-talk] !!! Important please read. !!!

[Mark McCarron]

This particular issue of SSL/TLS has been known since the earliest days.  It is a well understood problem in authentication.  How do we know a machine or user is who they claim to be?

The solution was the use of a 3rd party to act as a verifier of identity or a trusted party.  This little fact is lost on most new-comers but was a big selling point for groups such as Verisign in the early years.  We ended up with a certificate-based chain of trust.  It has always been understood that if the private keys of the issuing CA, or the root CA, were exposed then it would be trivial to mount man-in-the-middle attacks.  In these times of National Security letters, we can be quite confident that the private keys were obtained a long time ago.

Where private keys could not be obtained, then the practice and policy was to support technologies that were weakened in some fashion and push them as the de-facto standard.  We have seen this in particular modifications to random number generators.

What this means is that your average SSL/TLS connection will be secure from criminals but not from government agencies.  In a world were government agencies are the primary source of industrial espionage this is mainly the concern of businesses and corporations that must protect privileged or confidential information.

In regards to identifying Tor users, this is more simple than anyone imagines.  A simple DB at an ISP recording IP addresses of those connecting to Tor nodes is all it takes.  In fact, the EU mandates that this data be held for 2 years:

http://en.wikipedia.org/wiki/Telecommunications_data_retention#European_Union

That data can be correlated with access to hidden services and other websites, so we know for a fact that Tor is extensively compromised at present and provides no anonymity as it fails to deal with traffic analysis.

Regards,

Mark McCarron

> Date: Tue, 7 Jan 2014 18:23:08 -0800
> From: schoen at eff.org
> To: tor-talk at lists.torproject.org
> Subject: Re: [tor-talk] !!! Important please read. !!!
> 
> TheMindwareGroup writes:
> 
> > I don't know the exact details of how SSL/certificates work and I
> > don't know about anyone else's opinion on this subject, this is mine
> > and it doesnt look good. If this document is true, it means that due
> > to a (massive) weakness in the way central certificate authoritys
> > work, putting huge trust in central authoritys, it doesnt take much of
> > a stretch of the imagination of why this system is bad. From what I
> > can gather it appears using fake and forged root certificates and
> > probably intentional collusion with governments, they have total
> > access to enter any ssl stream they like. In short ssl is there
> > playground, so even if ssl is used we still cannot trust it cos they
> > can get into any ssl stream they like. Im not sure if this is true,
> > cos i dont know how the key/shared secret is created, but the document
> > hints that it might be based on the servers ssl certificate.
> 
> Hi Shadowman,
> 
> A lot of people have been talking about this lately, and it's true that
> the current system is problematic for these reasons.  Fortunately, there
> are a number of mechanisms that are trying to address the problems
> and reduce vulnerabilities.  Among others, you might be interested in
> 
> http://www.certificate-transparency.org/
> https://www.eff.org/observatory
> http://www.internetsociety.org/deploy360/resources/dane/
> https://www.imperialviolet.org/2011/05/04/pinning.html
> https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04
> http://tack.io/
> 
> There are also things to try to create more visibility for end-users who
> are willing to scrutinize the certs they're given, like
> 
> https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/
> 
> Many of these things still need some work, so there are a lot of
> opportunities for people to contribute to them.  They each have the
> effect of making certificate authorities more accountable or less
> absolutely trusted in some way, and increase the chance that misissued
> certs will be detected, publicized, revoked, and investigated.
> 
> > Wouldnt it be better to communicate with a "Public browser" running on
> > the exit node and have the public browser do the requests for you?
> > Like this...
> > 
> > [Browser] ->Tor->Entry->Relay-> [Exit browser] ------------>  [Server].
> > 
> > [...]
> > With this setup you communicate with the browser, the browser access's
> > the internet 2 seperate communication channels. The exit browser
> > acting as a air gap or filter, filtering rubbish out of the requests,
> > filtering rubbish out going and rubbish incoming. Cookies are only
> > stored on the exit browser, and all accumilated rubbish on the exit
> > browser can be dumped.
> 
> Unfortunately, we don't know who runs the exit nodes, and some of them
> may be malicious.  If a malicious exit node is running an "exit browser"
> for you, it could design the exit browser to do bad stuff to you instead
> of good stuff to you.  Instead of removing "rubbish", it could actually
> add it, or in any case deliberately fail to protect you from it.  I
> don't think the Tor developers would think it was safe to increase the
> amount of trust that Tor users have to have in the exit node operators.
> If anything, the trend has been to try to reduce it -- which is one of
> the reasons that we and the Tor Project have created HTTPS Everywhere:
> it reduces the scope of exit node operators' ability to see and tamper
> with your browsing sessions.
> 
> -- 
> Seth Schoen  <schoen at eff.org>
> Senior Staff Technologist                       https://www.eff.org/
> Electronic Frontier Foundation                  https://www.eff.org/join
> 815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107
> -- 
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk