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