The Internet Engineering Task Force (IETF), the body that sets standards for the Internet, has formally recognized .onion names. We think that this is a small and important landmark in the movement to build privacy into the structure of the Internet. This standardization work for .onion is joint work between Facebook and the Tor Project amongst others in an effort to help secure users everywhere.
Over the last few years, The Tor Project has been working with other members of the Peer to Peer community led by Dr. Christian Grothoff, founder of the GNUnet project to register several Special-Use Domain Names. IETF name reservations are part of a lesser known process that ensures a registered Special-Use Domain Name will not become a Top Level Domain (TLD) to be sold by the Internet Corporation For Assigned Names and Numbers (ICANN). Special-Use Domain Names have special considerations documented as part of their registration. Some of these names may sound familiar, such as .local which is widely deployed by Apple and others for Multicast Domain Name Service (mDNS).
During our long journey which began in the Summer of Snowden, Alec Muffett and I were encouraged to split out .onion from the list of other peer to peer names and to make a separate draft to register .onion as a Special-Use Domain Name. In this draft we listed security and privacy considerations that we believe will help to protect end users from targeted and mass-surveillance. We're happy to say that the first name reservation was just published as RFC7686.
Our internet standard reflects on considerations for handling .onion names on the internet as well as officially reserving .onion as a Special-Use-Domain-Name with the Internet Assigned Numbers Authority (IANA). With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum. We hope that in the future we'll see easy to issue certificates from the Let's Encrypt project for .onion services. We also hope to see more Peer to Peer names such as .gnu registered as Special-Use-Domain-Names by the IETF.
We greatly enjoyed our efforts with the IETF and plan to continue actively participate with the IETF in the future. We'd also like to thank everyone who helped with this process including but not limited to Mark Nottingham, Roger Dingledine, Linus Nordberg, Seth David Schoen, Leif Ryge, Helekin Wolf, Matthias Wachs and Dr. Christian Grothoff.
TorBirdy 0.1.2 is out! All users are encouraged to upgrade as soon as possible, especially if you are using Thunderbird 24.
Notable changes in this release include:
0.1.2, 04 Nov 2013
- New options:
- restore default TorBirdy settings
- toggle checking of new messages automatically for all accounts
- The minimum version of Thunderbird we now support is 10.0 (closes #9569)
- `--throw-keyids' is now disabled by default (closes #9648)
- We are no longer forcing Thunderbird updates (closes #8341)
- Add support for Thunderbird 24 (Gecko 17+) (closes #9673)
- Enhanced support for Thunderbird chat
- We have a new TorBirdy logo. Thanks to Nima Fatemi!
- Improved documentation:
- Add new translations and updated existing ones
- Please see the Transifex page for more information and credits
We offer two ways to install TorBirdy -- either by visiting our website (sig) or by visiting the Mozilla Add-ons page for TorBirdy. Note that there may be a delay -- which can range from a few hours to days -- before the extension is reviewed by Mozilla and updated on the Add-ons page.
As a general anonymity and security note: we are still working on two known anonymity issues with Mozilla. Please make sure that you read the Before Using TorBirdy and Known TorBirdy Issues sections on the wiki before using TorBirdy.
We had love help with translations, programming or anything that you think will improve TorBirdy!
Today we are happy to release our first beta of TorBirdy. It has been in development since April of last year and was released internally on the tor-talk mailing list. We think we've had just over five thousand users testing it in the last year. We have polished it and we've made great progress.
What is TorBirdy?
TorBirdy is a Torbutton like extension for Thunderbird, Icedove and related Mozilla mail clients. It may also work with other non-web browser Mozilla programs such as Sunbird. We've also added support for JonDo, Whonix, Tails; if that means something to you, let us know how it works!
As a general Anonymity and security note: We're still working on two known anonymity issues with Mozilla. When our improvements to Thunderbird are accepted, it will be anonymity ready out of the box and we'll do a proper full release.
We'd love help with translations, programming or anything that you think will improve TorBirdy!
Thanks to all of our TorBirdy users and contributors - Sukhbir and I would especially like to tagnaq and Karsten N!
In the summer of 2011, I spent a few months learning how to effectively reverse engineer Windows software. I'm still learning and while I have a lifetime of learning to do on the topic, I chose to audit Ultrasurf as a challenge. This research was performed as a labor of love and it was funded work. My interest in reverse engineering Ultrasurf comes entirely because I have seen people promoting it without also offering evidence that it is safe. Additionally, a few people had asked me what I thought of the software and in order to form an opinion, I decided to dig deeper.
Ultrasurf is software produced by the UltraReach company for censorship circumvention, privacy, security and anonymity. Unfortunately for them, I found their claims to be overstated and I found a number of serious problems with Ultrasurf.
My report is available for download from the following link: https://media.torproject.org/misc/2012-04-16-ultrasurf-analysis.pdf
Most of my research was done while traveling in Brazil, Canada, Germany, and very small amount of it was performed in the US. Additionally, a number of interesting data points in my research paper came from interception devices in Syria. As of early April 2012, an independent tester confirmed many of my findings from China; the versions of Ultrasurf tested did directly connect to blocked addresses and did not in-fact work at all. Newer versions appear to have different, not yet blocked, addresses baked into the program.
I believe that coordinated disclosure is reasonable in most cases and I ensured that Ultrasurf was notified long before the publication of this blog post. I had a face to face meeting in early December of 2011 to discuss my findings with the lead developer of Ultrasurf and to give them time to fix the problems that I discovered. Ultrasurf updated their website to change a number of their security, privacy and anonymity claims; they did not actually remove all of the bogus claims, merely the most egregious statements. Our meeting was overall quite positive and in fact led me to write notes that may become a second paper.
However, for various reasons, I've had to sit silently on this report for nearly four full months after our December meeting. I believe it is important to ensure that the issues discovered and discussed in my paper are resolved and that users are not kept in harm's way. I have serious concerns about ongoing security issues for the users of Ultrasurf and that is my primary reason for wishing to perform and release this research for all to see.
Here's the abstract of the paper:
Ultrasurf is a proxy-based program promoted for Internet censorship circumvention. This report gives a technical analysis of the Ultrasurf software and network. We present the results of reverse engineering the Ultrasurf client program, give an in-depth study of the known Ultrasurf network, especially those portions that interface in some way with the client or the Internet, and discuss network signatures that would allow an adversary to detect its use on a network. We cover client bootstrapping methods, censorship and censorship resistance, anonymity, user tagging by Ultrasurf and other parties, cryptographic internals and other previously unknown or undiscovered details about the Ultrasurf client and the Ultrasurf network. We find that it is possible to monitor and block the use of Ultrasurf using commercial off-the-shelf software. In particular, BlueCoat sells software and hardware solutions with such capabilities that have been deployed in Syria and other countries.
The vulnerabilities presented in this paper are not merely theoretical in nature; they may present life-threatening danger in hostile situations. We recommend against the use of Ultrasurf for anonymity, security, privacy and Internet censorship circumvention.
The main substance of the paper takes the time to refute nearly all of the claims that UltraReach makes on their website about their software Ultrasurf:
This paper addresses the following claims by UltraReach and other Ultrasurf advocates about the Ultrasurf client and Ultrasurf network:
- “Ultrasurf enables users to browse any website freely” — refuted in Section 3.1
- “employs a decoying mechanism to thwart any tracing effort of its communication with its infrastructure.” — refuted in Section 5.13
- “Protect your privacy online with anonymous surfing and browsing. Ultrasurf hides your IP address, clears
browsing history, cookies, and more.” — refuted in Section 6.2 and Section 6.3.
- “change IP addresses a million times an hour” — refuted in Section 6.1
- “Untraceable” — refuted in Section 6.10
- “Unblockable: Client uses wide array of discovery mechanisms to find an available proxy server and, when necessary, to switch/hop to avoid tracking/blocking” — refuted in Section 6.8
- “Invisible: Leaves no traces on the user’s computer, and its traffic is indistinguishable from normal access to HTTPS sites” — refuted in Section 5.12
- “Anonymous: No registration is requires [sic], and no personally identifying information collected” — refuted in Section 6.10
- “Tamperproof: Using privately-signed SSL certificates which dont depend on external, potentially compromised CAs (thus preempting MITM attacks), Ultrasurf proactively detects attempts by censors to reverse-engineer, sabotage, or otherwise interfere in the secure operation of the tool” — refuted in Section 5.8.
We conclude that each of these claims is false, incorrect, or misleading.
The issues involved in the writing, discussion and publication of this report are the stuff of movies. It has taken ages to publish this report and attempts at coordinated disclosure have been time consuming, largely fruitless and extremely frustrating. While some of the issues I have identified have been fixed, to the best of my knowledge the most important issues, such as a lack of forward secrecy, remain serious outstanding security issues. Ultrasurf often boasts of their decade long fight against censorship and while I respect the spirit of their efforts, I have a hard time respecting the technical implementation. I'm afraid that they've not had forward secrecy in their cryptographic protocol for that entire decade. Ultrasurf also often boasts of being untraceable when in fact they admitted to logging and disclosing user identifying logs to law enforcement when the data was requested. These kinds of security failures, both social and technical, are simply negligent and it means that users have been and are likely still in harm's way.
I firmly believe that Ultrasurf must publish their full technical specifications, peer review their designs of both obfuscation and cryptography, open their source code for the world to review and they must absolutely discontinue all data retention without exception.
I hope you'll enjoy the research presented in the paper and that it will help everyone to move towards building a more secure set of options for users.
UltraReach/Ultrasurf have released a response document and a response page that confirms a number of my claims, side steps a large swath of them and then attacks me, Tor and others for the report. They specifically claim that what is true in my paper is for older versions of Ultrasurf. They do not disclose which versions or when the fixes were released. This is a typical vendor tactic considering that they pressured me not to release the report until they felt they were given enough time to fix the issues involved. They also believe that I claim that Ultrasurf was broken but at no time did I ever claim it was broken; rather, I said it has problems. The claims they made and make do not live up to the implementation of policies or technical capabilities. This I think is quite reasonable because their claims were, frankly, entirely unreasonable.
I put a great deal of time and effort into disclosing these report findings to Ultrasurf - both what would be considered responsible and coordinated - it's too bad that they've decided to ignore most of the findings and to attack me over the undefendable issues.
Another Update: Collin Anderson has written up his view of the disclosure process. He is an independently involved third party that attempted to mediate our disclosure, solutions and a reasonable time frame for all parties involved.
We're having an open hackfest at the University of Washington on Feb 22nd and 23rd; we may hold an additional open hackfest day on Friday, Feb 24th if we feel the demand. This meeting is largely possible due to the support of the UW Security and Privacy Research Lab.
This hackfest coincides with our Winter Developer summit and many Tor developers will be in attendance. As I write Tor developers have already started their travel to Seattle and many will stick around for the following week.
We'd love to welcome everyone interested in attending. We'd especially like people to feel welcome to discuss ideas or proposals, who want to know what's happening in the world of censorship resistance, anonymity, privacy and related topics. Most of all if you're prepared to write software, we're planning to do quite a lot of that next week as well.
The right to read is a fictional story but it warns of a future that has already started to arrive; it paints a picture where information is controlled with a heavy hand and simply reading, let alone speaking is an extremely dangerous activity. In the words of William Gibson, "The future is already here — it's just not very evenly distributed". Restrictions on the right to read though the Internet perfectly match this observation. A lot should be said about perceptions of censorship, and it is often thought that places like Syria or Iran are unique. Generally, people in the West hold that those countries obviously censor as is consistent with facts of life in a supposedly non-free country. This probably holds a lot of truth but it absolutely fails to address the core of the issue — these countries and those networks are not unique.
In fact, we find uncensored networks to almost be an abnormal state. The so-called free countries in the West often shape and tamper with network traffic. They often also log data and even collaborate with governments. Generally, people don't see evidence of this and as a result, they often perceive that their Internet connections aren't monitored or censored. These days are quickly coming to an end and while it sounds like hyperbole, here are examples in the United Kingdom and in the United States of America.
Recently it has come to our attention that our primary website is filtered by Vodafone in the UK, by 3 (three.co.uk) in the UK, by O2 in the UK, and by T-Mobile in the UK and the USA. It used to be the case that we only saw filtering and censorship events in places like Egypt, Syria, or Iran and now we're going to explore what those attacks look like in the context of the UK and the USA.
When a visitor uses a pre-paid account on the T-Mobile USA network and attempts to visit http://www.torproject.org/, they are redirected to a block page. This is enabled by default without user's affirmative consent and only savvy privileged users may even attempt to disable this censorship. There is an informational page about the T-Mobile censorship system and it explains that this censorship may be disabled. We've heard reports that attempts to disable the censorship are not always successful and this certainly doesn't bode well for an easy and censorship-free Internet experience.
The T-Mobile USA network censorship appears to be simple to bypass: it appears to only trigger when a client sends Host: torproject.org on TCP port 80 and visitors that use HTTPS will probably not notice or be obviously impacted by their censorship.
This kind of censorship raises all kinds of interesting questions. I suspect it raises US legal and social questions as well. The Tor Project is a registered 501c3 non-profit corporation in the state of Massachusetts, and the block was experienced in California. Does this count as interfering with interstate commerce? What duty of care does T-Mobile USA have when it relies on systems or infrastructure funded by the public? What duty of care do they have as a common carrier?
Similarly, when a user on the UK Vodafone network visits http://www.torproject.org/ they are greeted by a block page as well. You can visit this block page without directly using their networks. Detecting their filters is straightforward and we see tampering at the sixth hop.
Here is a tcptraceroute to TCP port 80 of torproject.org from an Ubuntu machine connected to the Internet via Vodafone UK:
Tracing the path to www.torproject.org (18.104.22.168) on TCP port 80 (www), 30 hops max
1 192.168.1.1 2.379 ms 1.011 ms 1.313 ms
2 10.252.225.61 90.998 ms 133.672 ms 95.963 ms
3 10.252.224.186 78.865 ms 91.722 ms 91.415 ms
4 * * *
5 10.203.64.130 88.502 ms 73.259 ms 80.765 ms
6 www.torproject.org (22.214.171.124) [open] 77.927 ms 152.599 ms 96.399 ms
Here is a normal traceroute to torproject.org from an Ubuntu machine connected to the internet via Vodafone UK:
traceroute to www.torproject.org (126.96.36.199), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 9.669 ms 9.583 ms 9.460 ms
2 10.252.225.61 (10.252.225.61) 98.084 ms 98.046 ms 98.224 ms
3 10.252.224.219 (10.252.224.219) 98.760 ms 109.326 ms 109.261 ms
4 host203.msm.che.vodafone (10.203.64.154) 109.087 ms 127.554 ms 127.426 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 188.8.131.52 (184.108.40.206) 180.920 ms 180.692 ms 180.652 ms
10 220.127.116.11 (18.104.22.168) 180.659 ms 180.473 ms *
11 22.214.171.124 (126.96.36.199) 260.480 ms * 188.8.131.52 (184.108.40.206) 152.107 ms
12 220.127.116.11 (18.104.22.168) 152.265 ms 152.099 ms 151.808 ms
13 22.214.171.124 (126.96.36.199) 151.453 ms 151.124 ms 188.8.131.52 (184.108.40.206) 151.129 ms
14 vin-145-254-19-130.arcor-ip.net (220.127.116.11) 157.978 ms vin-145-254-19-126.arcor-ip.net (18.104.22.168) 119.699 ms 129.820 ms
15 te3-1-vix-iec-c2.ix.sil.at (22.214.171.124) 129.999 ms 136.314 ms 136.338 ms
16 126.96.36.199 (188.8.131.52) 136.033 ms 135.826 ms 135.666 ms
17 www.torproject.org (184.108.40.206) 151.282 ms 118.185 ms 114.603 ms
We've additionally found that pre-paid T-Mobile UK accounts also experience censorship that is similar to T-Mobile USA. Detection of their filter is possible with some of the techniques that I've demonstrated, and it is quite trivial to see that TCP port 80 and 443 are treated in a special way.
Here is a tcptraceroute to TCP port 80 of torproject.org from an Ubuntu machine connected to the Internet via T-Mobile UK:
Tracing the path to torproject.org (220.127.116.11) on TCP port 80 (www), 30 hops max
1 * * *
2 10.126.241.49 305.721 ms 429.908 ms 449.875 ms
3 10.70.16.221 480.031 ms 339.890 ms 429.951 ms
4 10.70.17.87 480.447 ms 449.365 ms 439.979 ms
5 vescum.torproject.org (18.104.22.168) [open] 459.935 ms 659.964 ms 449.849 ms
Here is a tcptraceroute to TCP port 443 of torproject.org from an Ubuntu machine connected to the Internet via T-Mobile UK:
Tracing the path to torproject.org (22.214.171.124) on TCP port 443 (https), 30 hops max
1 * * *
2 10.126.241.53 357.474 ms 360.016 ms 389.772 ms
3 10.70.16.217 490.136 ms 409.878 ms 359.945 ms
4 10.70.17.87 469.956 ms 489.883 ms 389.868 ms
5 www.torproject.org (126.96.36.199) 410.024 ms 420.494 ms 399.888 ms
6 10.70.17.66 389.470 ms 429.923 ms 339.861 ms
7 10.70.16.50 430.002 ms 349.850 ms 450.012 ms
8 10.70.17.103 339.900 ms 389.836 ms 390.031 ms
9 188.8.131.52 369.851 ms * 924.522 ms
10 10.126.168.218 420.035 ms 379.878 ms 409.968 ms
11 xe-1-3-2-19.lon10.ip4.tinet.net (184.108.40.206) 469.942 ms 480.002 ms 499.940 ms
12 xe-5-3-0.vie20.ip4.tinet.net (220.127.116.11) 399.851 ms 379.892 ms 379.929 ms
13 silver-server-gw.ip4.tinet.net (18.104.22.168) 419.899 ms 479.926 ms 449.923 ms
14 www.torproject.org (22.214.171.124) 389.925 ms 449.789 ms 549.993 ms
15 www.torproject.org (126.96.36.199) [open] 419.869 ms 469.997 ms 479.839 ms
Compare with a normal traceroute to torproject.org from an Ubuntu machine connected to the Internet via T-Mobile UK:
traceroute to torproject.org (188.8.131.52), 30 hops max, 60 byte packets
1 * * *
2 10.126.241.49 (10.126.241.49) 99.671 ms 99.856 ms 159.584 ms
3 10.70.16.221 (10.70.16.221) 179.672 ms 190.046 ms 159.760 ms
4 10.70.16.50 (10.70.16.50) 190.250 ms 179.356 ms 90.611 ms
5 10.70.17.103 (10.70.17.103) 90.565 ms 110.275 ms 90.508 ms
6 184.108.40.206 (220.127.116.11) 110.476 ms 110.449 ms 110.391 ms
7 10.126.168.214 (10.126.168.214) 70.022 ms 70.062 ms 60.303 ms
8 xe-1-3-2-19.lon10.ip4.tinet.net (18.104.22.168) 60.322 ms 69.380 ms 69.383 ms
9 * * *
10 limelight-lon-gw.ip4.tinet.net (22.214.171.124) 59.798 ms 60.535 ms 179.659 ms
11 tge11-1.fr4.lga.llnw.net (126.96.36.199) 240.999 ms 221.715 ms 221.191 ms
12 tge14-4.fr4.ord.llnw.net (188.8.131.52) 230.570 ms 229.966 ms 210.814 ms
13 tge7-1.fr3.ord.llnw.net (184.108.40.206) 210.575 ms 200.446 ms 199.453 ms
14 ve8.fr3.ord4.llnw.net (220.127.116.11) 169.521 ms 148.181 ms 168.037 ms
15 cymru.tge6-3.fr3.ord4.llnw.net (18.104.22.168) 248.264 ms 229.474 ms 249.066 ms
16 vescum.torproject.org (22.214.171.124) 249.289 ms 249.234 ms 259.448 ms
In the examples above we see that T-Mobile UK treats TCP port 80 in a special manner and effectively stops users from reaching our web site. This is an attack against users who attempt to connect to our infrastructure. This attack, while primitive, demonstrates an active and malicious action on the part of the above named Internet providers.
We've additionally seen reports of the UK O2 network blocking connections to http://www.torproject.org/ in exactly the same way that Vodafone UK blocks access. The O2 filter has been covered in the popular media in the recent past and we're sad to hear that they've decided to include Tor's website in their race to the bottom.
In all the above cases we do not see DNS tampering but rather outright Man-In-The-Middle attacks against connections to our web server. These censorship systems do not currently implement a Man-In-The-Middle attack against the SSL services offered by our web server. It is not much of a stretch of the imagination to think that such an action may be a future plan; we've seen it elsewhere.
Current users of the Tor network are not impacted by this filtering, but these networks are attempting to deny new users the ability to start using Tor without extensive efforts. You can view their filter page without using their service; the exact block page is also available externally. It appears that it is possible for users to disable this censorship by providing a credit card as a proof of age. This is not exactly a privacy-friendly tactic. The O2 Twitter account contacted me and said they were willing to review their censorship policy for torproject.org but they did not offer to remove the censorship entirely.
This trend of providing partially censored Internet in what we all think of as free countries is alarming. Are we supposed to look the other way because the mobile Internet isn't the same as the "real" Internet? Should we worry that Vodafone's capabilities and behavior here remind us of what they did in Egypt last year? It would seem that the war over network neutrality is far from won.
(Investigation and research thanks go to Andrew Lewman, Steven Murdoch and Runa Sandvik of the Tor Project, SiNA of RedTeam LLC, Jim Killock, Lee Maguire, Peter Bradwell of the Open Rights Group and their project blocked.org.uk and Richard Clayton from the University of Cambridge.)
About an hour ago I was contacted by the Dutch Government with more details about the DigiNotar Debacle. It seems that they're doing a great job keeping on top of things and doing the job that DigiNotar should've done in July. They sent a spreadsheet with a list of 531 entries on the currently known bad DigiNotar related certificates.
The list isn't pretty and I've decided that in the interest of defenders everywhere without special connections, I'm going to disclose it. The people that I have spoken with in the Dutch Government agree with this course of action.
This disclosure will absolutely not help any attacker as it does not contain the raw certificates; it is merely metadata about the certificates that were issued. It includes who we should not trust in the future going forward and it shows what is missing at the moment. This is an incomplete list because DigiNotar's audit trail is incomplete.
This is the list of CA roots that should probably never be trusted again:
DigiNotar Cyber CA
DigiNotar Extended Validation CA
DigiNotar Public CA 2025
DigiNotar Public CA - G2
Koninklijke Notariele Beroepsorganisatie CA
Stichting TTP Infos CA
The most egregious certs issued were for *.*.com and *.*.org while certificates for Windows Update and certificates for other hosts are of limited harm by comparison. The attackers also issued certificates in the names of other certificate authorities such as "VeriSign Root CA" and "Thawte Root CA" as we witnessed with ComodoGate, although we cannot determine whether they succeeded in creating any intermediate CA certs. That's really saying something about the amount of damage a single compromised CA might inflict with poor security practices and regular internet luck.
Of particular note is this certificate:
CN=*.RamzShekaneBozorg.com,SN=PK000229200006593,OU=Sare Toro Ham Mishkanam,L=Tehran,O=Hameye Ramzaro Mishkanam,C=IR
The text here appears to be be an entry like any other but it is infact a calling card from a Farsi speaker. RamzShekaneBozorg.com is not a valid domain as of this writing.
Thanks to an anonymous Farsi speaker, I now understand that the above certificate is actually a comment to anyone who bothers to read between the lines:
"RamzShekaneBozorg" is "great cracker"
"Hameyeh Ramzaro Mishkanam" translates to "I will crack all encryption"
"Sare Toro Ham Mishkanam" translates to "i hate/break your head"
Without any further delay, I've uploaded the original spreadsheet and a CSV text file for people who don't trust spreadsheets. The information contained in both files should be the same. Hopefully this information will help people to mitigate certain harm from the DigiNotar Debacle.
Recently it has come to the attention of, well, nearly the entire world that the Dutch Certificate Authority DigiNotar incorrectly issued certificates to a malicious party or parties. Even more recently, it's come to light that they were apparently compromised months ago or perhaps even in May of 2009 if not earlier.
This is pretty unfortunate, since correctly issuing certificates is exactly the function that a certificate authority (CA) is supposed to perform. By comparison, ComodoGate looks fairly minor.
This incident doesn't affect the functionality of Tor clients or the Tor Network itself, since Tor doesn't use the flawed CA system. The Tor network uses a much simpler and flatter trust design that protects us from many of these CA issues. Further, Tor's distributed-trust design limits the damage from compromise of any given network component.
But the incident does affect users that are attempting to reach The Tor Project's infrastructure: with one of these bogus certificates, an attacker could convince your browser that you were talking to The Tor Project website, when really you were talking to the attacker.
We have taken direct action in an attempt to stop this kind of attack in the future with two major browser vendors and we hope to integrate a fix with all other willing browsers. Please contact us if you ship a browser and you'd like to help your users to be proactively secure when visiting our sites. TorBrowser users should upgrade to our latest release and verify signatures for all downloaded files. All Tor Browser Bundles have been updated to Firefox 6 with a patch to stop trusting the offending CA, and users are encouraged to upgrade. Below, we describe what we found out, what we're doing about it, and what you should do to keep yourself safe.
In the last seventy-two hours we were working to find positive confirmation that The Tor Project was one of the targeted groups. It was originally disclosed that at least one certificate was issued for '*.google.com' and that it was being used to actively Man-In-The-Middle SSL and TLS connections. Quite quickly we found a similar pattern to the ComodoGate fiasco. It appears likely that the Mozilla Addons site, Yahoo, Facebook, Twitter, and a few other major players were targeted. We do not have an authoritative list but I personally believe those targets to be accurate; time will tell. Additionally, we heard rumors that we had graduated to the big leagues and we had also heard that DigiNotar had reached out to the major browser vendors. We did not receive any proactive contact from DigiNotar as a browser vendor and this worried us greatly when compounded with the rumor of being one of the targets as well.
We ship a rather specific and special browser and it appeared that all of our sites are specifically in the attacker's target list. Having received no contact from DigiNotar, we reached out to DigiNotar by email and by telephone.
I spoke on the telephone with a rather nice but obviously overworked DigiNotar point of contact who will remain anonymous. He was guarded and careful in what he said but was clearly sympathetic to the severity of the matter at hand. It seemed quite clear that he repeated similar information to other impacted callers:
"What I can say is the following " ... "Any fraudulent torproject.org certificate that has been requested has been revoked. Any serial numbers that we know about have been revoked. All serial numbers have been communicated to the major browsers vendors." ... "Any certificate that we know of is revoked by OCSP server."
We emailed quite a bit back and forth after the phone call. A few hours later that same point of contact from DigiNotar sent a list of all of the certificates in a spreadsheet. It appears that the attackers requested twelve certificates, and each certificate was for '*.torproject.org'. The first batch of six certificates was issued on July 18th and the second batch of six certificates was issued on July 20th. According to the spreadsheet, the first six of the certificates expired on August 17th, 2011 and second batch of six certificates expired on August 19th, 2011. According to the information disclosed by DigiNotar the certificates in question should all have expired. The contact at DigiNotar stressed that there was no confirmation about the attacker(s) receiving the certificates. I have no reason to believe that these certificates would have any more trouble reaching the requesting party than the Google certificate used in the wild.
This is the current list of serial numbers for all twelve Tor Project certificates as disclosed to us by DigiNotar:
DigiNotar has not provided us with a copy of any of the certificates that they issued. We are not sure that they have copies nor if they are willing to disclose any copies they may or may not have. This point is extremely disconcerting as the CRL/OCSP revocation process is essentially worthless. Mere serial numbers are simply not enough in some cases — especially when a full list of all likely compromised serial numbers has not been disclosed as happens to currently be the case.
To the best of our knowledge and by analyzing the CRLs for DigiNotar, we do not believe that any of the fraudulently issued '*.torproject.org' certificates have been revoked at the time of this writing. It may be the case that they are simply not in the business of revoking certificates after they have expired. There is no evidence to support revocation during the time that these certificates were perfectly valid.
1 3 ms 14 ms 2 ms 192.168.1.1
2 67 ms 67 ms 65 ms 91.99.***.***.parsonline.net [91.99.***.***]
3 65 ms 67 ms 93 ms 10.220.1.2
4 67 ms 72 ms 66 ms 126.96.36.199
5 66 ms 64 ms 64 ms 188.8.131.52
############### [ MORE Nodes ] #################
6 451 ms 195 ms 154 ms 184.108.40.206
7 626 ms 231 ms 88 ms 220.127.116.11
8 93 ms 91 ms 96 ms 18.104.22.168
9 88 ms 94 ms 120 ms 22.214.171.124
################### [ MORE ] ###################
10 88 ms 88 ms 88 ms 10.10.53.33 ####DIfferent IP (0.0.0.33)
#### [ OUT OF IRAN ] ####
11 340 ms * * pos3-1.palermo5.pal.seabone.net [126.96.36.199]
To quote someone I respect greatly: "That's not dodgy at all!"
Early statements By DigiNotar translated by someone and mentioned by a friendly Dutch man lead us to believe that DigiNotar and their parent company are in damage-control mode. It would be unsurprising to hear that the Dutch Government is similarly in the dark about the scope of the compromise, as it appears DigiNotar does not control a canonical list for all certificates issued. While some Browser vendors have received a list, I do not have confidence that this list actually contains all malicious certificates that have been issued: rather it appears to be a subset that did not even include the Google certificate that was being used in the wild. We hope that DigiNotar will fully disclose whatever information they have and explain what information they honestly lack.
Modern versions of Chrome (13) were able to prevent MITM attacks against most, if not all of the Google sites where they had certificate pinning and where HSTS was enabled. Google has also announced the attacks and updated information about it. Additionally, they have distrusted DigiNotar in Chrome.
We've sent a request to Google that they enable HSTS and pin certificates for some of the critical Tor sites and that patch is pending. Google has been very good about all of this and I can't thank them enough for their help.
As it stands, Chrome appears to have shipped a fix that distrusts DigiNotar and it appears to treat hundreds of certificates as if they are specifically known to be malicious or hostile. Mozilla and others have shipped a fix as well. Sadly, it appears that the Dutch Government asked various browser vendors to create an exemption for certain trust chains as some kind of compromise. However, we were not party to any of the discussions, and we don't understand the core concerns for such a compromise. We're not willing to take a leap of faith for a Certificate Authority that did not contact us when they first noticed this problem. Right now, if we found a DigiNotar-issued certificate certifying that water was wet, we wouldn't believe it without checking for ourselves. Twice.
We have proactively given DigiNotar an "Internet Death Sentence" in the Tor Browser. The direct impact of removing DigiNotar should be on the order of around seven hundred certificates according to some cursory queries run against the EFF's SSL Observatory. I believe that the number of certificates revoked is nearing parity with the number of possibly legitimate still-valid certificates issued by DigiNotar. That's a sad state of affairs.
We do not currently have evidence of any tampering with Tor downloads, but we're looking. If an attacker can successfully perform a MITM attack, there is nothing to prevent them from giving you a bogus package instead of the software you were actually looking for — if you're not checking package signatures, there's no easy way to tell good software from bad.
What you should do
First of all, upgrade your browser(s). See this blog post announcing the new Tor Browser Bundles with Firefox 6.
Note that verifying the signatures on Tor packages prevents attackers like this from causing you to install a possibly backdoored version of Tor. You should always verify the signature of any software you download. We encourage you to learn more about secure signature verification.
If you have downloaded copies of any Tor software in the past few months, and you did it over any network that you don't trust, please help us check to see whether there was any attempt to alter them. We don't expect you'll find anything, but if you do, we really want to know about it. In any case, it will be good practice for checking signatures.
If you have any information about certificates that you believe to be false, please do send us the certificates and we'll take a look.
The Certificate Authority system as it stands today is a house of cards and we're witnessing in public what many have known for years in private. The entire system is soaked in petrol and waiting for a light. There are some new directions for trust in the works such as Convergence and various ways to do DNSSEC authenticated HTTPS as well as other hacks. Still, nothing is set in stone or standardized and this is why we need to remain vigilant. We're hoping to detect these kinds of attacks in the future with our distributed SSL Observatory and we hope that you'll join us.
I'd like to end on a positive note and quote a personal hero and friend, Matt Blaze: "A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much."