The problem with Tor is that it still uses these 1024 bit keys for much of its crypto, particularly because most people are still using older versions of the software. The older 2.3 versions of Tor uses keys the NSA can crack, but few have upgraded to the newer 2.4 version with better keys.
You can see this for yourself by going to a live listing of Tor servers, like http://torstatus.blutmagie.de/. Only 10% of the servers have upgraded to version 2.4.
Recently, I ran a "hostile" exit node and recorded the encryption negotiated by incoming connections (the external link encryption, not the internal circuits). This tells me whether they are using the newer or older software. Only about 24% of incoming connections were using the newer software. Here's a list of the counts:
14134 -- 0x0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
5566 -- 0xc013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
2314 -- 0x0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
905 -- 0x0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
1 -- 0xc012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
The older software negotiates "DHE", which are 1024 bit Diffie-Hellman keys. The newer software chooses ECDHE, which are Elliptical-Curve keys. I show the raw data because I'm confused by the last entry, I'm not sure how the software might negotiate ECDHE+3DES, it seems like a lulz-worthy combination (not that it's insecure -- just odd). Those selecting DHE+3DES are also really old I think. I don't know enough about Tor, but I suspect anything using DHE+3DES is likely more than 5 years old.
(By the way, I used my Ferret tool to generate this, typing "ferret suites -r
The reason software is out of date is because it takes a long time for repositories to be updated. If you type "apt-get install tor" on a Debian/Ubuntu computer, you get the 2.3 version. And this is what pops up as the suggestion of what you should do when you go to the Tor website. Sure, it warns you that the software might be out-of-date, but it doesn't do a good job pointing out that it's almost a year out of date, and the crypto the older version is using is believed to be crackable by the NSA.
Of course, this is still just guessing about the NSA's capabilities. As it turns out, the newer Elliptical keys may turn out to be relatively easier to crack than people thought, meaning that the older software may in fact be more secure. But since 1024 bit RSA/DH has been the most popular SSL encryption for the past decade, I'd assume that it's that, rather than curves, that the NSA is best at cracking.
Therefore, I'd suggest that the Tor community do a better job getting people to upgrade to 2.4. Old servers with crackable crypto, combined with the likelyhood the NSA runs hostile Tor nodes, means that it's of much greater importance.
Update: The above list are the incoming connections from other Tor servers. The following is a list of outgoing connections (since this is an exit node). This has nothing to do with the above discussion, I just include it here for completeness.
count suite - description
39611 0x0005 - TLS_RSA_WITH_RC4_128_SHA
30138 0x0035 - TLS_RSA_WITH_AES_256_CBC_SHA
14569 0xc011 - TLS_ECDHE_RSA_WITH_RC4_128_SHA
10043 0x0004 - TLS_RSA_WITH_RC4_128_MD5
8576 0xc007 - TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
7100 0x0039 - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
4081 0x002f - TLS_RSA_WITH_AES_128_CBC_SHA
2077 0xc014 - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
1900 0x0088 - TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
1090 0x0084 - TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
481 0xc013 - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
337 0x000a - TLS_RSA_WITH_3DES_EDE_CBC_SHA
102 0xc009 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
101 0x0016 - TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
83 0x009f -
78 0xc030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
35 0xc02f - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
16 0x0033 - TLS_DHE_RSA_WITH_AES_128_CBC_SHA
6 0x003d - TLS_RSA_WITH_AES_256_CBC_SHA256
6 0xc028 - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
10 comments:
Fascinating! Thank you for the analysis and data. Do you know where the 1024-bit limit on DHE comes from? Is that a Tor-specific limitation? Is it that the older versions generated a 1024-bit DH key by default? I don't see anything in the specification of TLS that limits DH to 1024-bit keys.
In principle, the shared secret can have any size. A cursory Google search shows NSS had a 1024-bit limit that was lifted in 2004. Have you checked 1024-bit is always the size chosen by the encryption software?
Also, I know 1024-bit factorization is likely "broken in practice", but I couldn't find much info on Diffie-Hellman key exchange sizes. Could you link to it?
This is a helpful post that highlights an important security issue. However, the paragraph on Tor software being out of date--and the reasons it might be so--isn't quite right. The current recommended stable version of Tor is 0.2.3.25-12. The current alpha release is Tor 0.2.4.17-rc, and people running relays are being encouraged to use this version on the mailing lists. So the repositories, by recommending Tor 0.2.3.x, aren't necessarily out of date. However, the Tor website does advise against using the Ubuntu repositories because they aren't "reliably updated" (https://www.torproject.org/docs/debian#ubuntu). Also, the most up to date version of Tor can be found at the following repository: deb http://deb.torproject.org/torproject.org/ tor-nightly-0.2.4.x-wheezy main. None of this, of course, is to say that 2048 bit keys shouldn't be adopted as quickly as possible, but I think it's important to be clear about which version of Tor is which.
If you weren't so clearly misinformed I'd think maybe I actually have something to worry about. However you didn't even get the recommended version right. The 2.4 version is a release candidate and wouldn't normally be recommended by the Tor project. When it is ready it'll certainly be the recommended version no doubt. You come off more like an incompetent reporter than someone who has a clue what they are talking. Learn to read. The project clearly advises users NOT to use the version of Tor shipping with Ubuntu. The version shipping with Debian is kept up to date. 2.3.x is the latest stable release and what most users should be using. You doing nothing more than speculating on something you have no clue about.
Run 1024 DHE TLS over OpenVPN configured with OpenSSL configured with enable-ec_nistp_64_gcc_128 to support ECC curve P-256. Sounds layered and suboptimal, but suffices?
Question:
The article is a bit weak on the details:
Did you do the traffic analysis after "your" TOR-Software decrypted the target-adress. (have you altered the tor software or "hooked" the decryption routine, that you can analyse the negotiated keys)
Or did you really only run a rouge exit node (one that redirects, filters and manipulates out and ingoing traffic comming out or in of your exit node )
And just baited about https-everywhere and weak SSL-encryption.
> the newer Elliptical keys may turn out to be relatively easier to crack than people thought
That wold be news to me. Do you have a reference?
>> the newer Elliptical keys may turn out to be relatively easier to crack than people thought
> That wold be news to me. Do you have a reference?
There's concern that the constants used to define the elliptical curves were influenced by the NSA and give them a way to break it.
https://www.schneier.com/essay-198.html
One thing to remember is that traffic once recorded can be scrutinized any time. Get the uncrackable encrypted data today and break it the day after tomorrow.
So updating to the presumably less (or more) insecure version which uses elliptical keys won't help you with the things you did with Tor 2.3 in case your traffic has been recorded and stored away by the NSA during that time.
So, why not use both ECDHE and DHE to encrypt? (and use zillion-bits)
Post a Comment