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

[Seth David Schoen]

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