[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-talk] How evil is TLS cert collection?



I've spent some time working with the EFF recently to build a
distributed version of the SSL Observatory
(https://www.eff.org/observatory) to be included with HTTPS
Everywhere. The draft API and design sketch is here:
https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission

The brief summary is that it will be submitting rare TLS certificates
through Tor to EFF for analysis and storage. We will also leverage the
database of certificates to provide notification in the event of
targeted MITM attacks**.

I am trying to decide if this is a bad thing to enable by default for
users.

On the one hand, we have taken a lot of precautions to ensure that the
EFF is given the minimal amount of useful information, and retains
even less (such as no high-resolution timing information). The EFF is
extremely trustworthy, and has an army of lawyers on-hand to defend
against subpoenas or legal requests for excessive data retention.

Furthermore, the OCSP revocation servers have just as much or more
information, and who knows what they do with this same information.
In all likelihood, they probably sell it to netcraft and whoever else.
It is valuable.

On the other hand, the EFF intends to publish as much of the
information gathered with this system as it can for analysis by the
wider Internet community. This will likely include raw SQL dumps of
the resulting certificate database.


So, the question for the bikeshed discussion then is what should the
default state of this collection be? Our thought is to provide
HTTPS-Everywhere users with this dialog on first-run
https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables

However, I'm not sure that this is going to work for Tor Browser
Bundle users (which ships with HTTPS Everywhere) who may have the TBB
on readonly USB keys or live cds.  They may end up being asked each
time they start.

Is this a decent compromise? The other option is to not even bother to
ask users who have a working tor installed, on the assumption that
since we can submit certs through tor, it is always safe to do so. We
may end up doing this instead of always asking them. Is this wrong? If
so, why?



** Due to a limitation of the Firefox APIs, we cannot actually prevent
the load of any content that is delivered by a MITM attacker. We will
resort to an after-the-fact message that will inform you of compromise
and advise you get to a more secure Internet connection immediately to
change your password.

Perspectives (http://www.networknotary.org/) has this same limitation,
but it uses DOM manipulation to make you believe it has actually
prevented the page load, when in fact your authentication tokens have
also already been transmitted at the time of notification of MITM.

Perspectives also has just enough differences that we decided to work
on a different implementation. The EFF wants to turn every user into a
vantage point, so that we can gather information on the extent of
targeted, CA-authenticated MITM events. They want to find a silver
bullet against the CA model, to conclusively prove that it can't
possibly provide the security properties it claims. The Perspectives
protocol is not set up to do this.


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Attachment: pgpMatAmHRui6.pgp
Description: PGP signature

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk