Why the BEAST Doesn't Threaten Tor Users

Earlier in the week, we posted news of a vulnerability discovered in virtually all websites secured with theoretically outdated (but widespread) versions of SSL and TLS encryption. Luckily for all non-nefarious users, this vulnerability (called BEAST, short for Browser Exploit Against SSL/TLS) was discovered and disclosed by researchers Thai Duong and Juliano Rizzo, and browser makers are pushing out changes to nullify it. Many systems, though, will remain unpatched for a long time. Nick Mathewson (nickm) of the Tor project has posted an explanation of why Tor traffic, as he understands the attack, remains safe. As a side benefit for those of us who aren't security experts, his description explains in plain language just what the danger is.

Comments

Bad Cert?

[Anonymous Coward]

and the link throws an SSL error, sorry not going

Re:Bad Cert?

[Anonymous Coward]

No error from here. This is how the cert looks from my browser http://imageshack.us/photo/my-images/705/cert.png/

Re:Bad Cert?

[Anonymous Coward]

Does it matter? Really? Do you indent to enter personal/confidential information into the site? Your bank details perhaps?

Re:Bad Cert?

[Lennie]

Be sure not to choose to remember the choice permanently by adding the certificate (or CA !) to your certificate store.

Let me guess the person above has disabled the GeoTrust CA.

Just make a good security standard already

[Co0Ps]

What an epic fail for TLS. The certification system is broken by design and now apparently the block encryption as well. Let's take this opportunity to draft a new standard that:

A) Solves the having-to-trust-cert-authorities in china by using DNSSEC instead for certification. It should also optionally support manual cert distribution or remember-public-key for advanced users.

B) Just like SSH it should supports a range of handshake methods/encryption algorithms. It's insane to rely on a single algorithm. So when (note "when", not "if") an algorithm gets busted I can simply patch my browser.

So somebody, please write an RFC now, anyone? :)

Re:Just make a good security standard already

[hairyfeet]

But if you are using DNSSEC aren't you just trading Chinese certs for American servers? Don't think I really like our record right now when it comes to things like privacy or rights or...well pretty much anything that doesn't give a handjob to a corporation. According to the Wiki DNSSEC all starts with and is tied to the root zone DNS which is currently controlled by US Department of Commerce NTIA

I'm sorry but after the whole "AT&T secret room" bit came out I wouldn't trust our government with jack shit when it comes to privacy, as obviously they don't give a fuck. We just don't have a track record post PATRIOT worthy of having that kind of power sadly.

Re:Just make a good security standard already

[maxwell demon]

So somebody, please write an RFC now, anyone? :)

What about you?

Re:Just make a good security standard already

[Lennie]

B. SSL/TLS already supports many methods/encryption algorithms. If everyone would be easiliy be able to install newer software instead of having to support old, we'd all be able to turn off the older SSL/TLS methods. But as we can't, the other solution is to setup to server to prefer an other older method, which uses RC4 instead of CBC, which this tries to attack. The RC4-based method is also safe.

And for those webdevelopers who complained about Opera and Mozilla disabled support of the older websocket protocol. If they didn't websockets could have potentially be used for this attack as well instead of the Java-applet which is used for this attack.

Re:Just make a good security standard already

[Co0Ps]

You make an excellent point. Such a certification system would still be 1000% better than the current system though. It's very plausible that one of the 100 authorities in my browser list screws up or maliciously generates rouge certificates to spy on regime dissidents. A scenario where the US would choose to secretly use the root cert to create rouge certs for MITM attacks is not very likely as it would be easily detected and would undermine the trust in DNSSEC and the whole infrastructure of the Internet so I doubt the US would risk that. It would probably result in some sort of diplomatic crisis.

Re:Just make a good security standard already

[Lennie]

What DNSSEC can bring is, is a way for the domain-owner to communicate which certificate and thus which CA is used on his/her website for HTTPS (SSL/TLS).

This is definitely very useful, but don't expect DNSSEC to be deployed everywhere any day soon. Many DNS-relays in DSL-routers, corporate firewalls and so on are just braindead. :-(

Re:Just make a good security standard already

[fast turtle]

The US Doesn'tt have a track record prior to 1750 of respecting privacy worthy of having any kind of power I'm sorry to say. All that we're now seeing is that politicians are not out to help their constituients but to line their own and family pockets while ensuring that they remain in power.

Re:Just make a good security standard already

[TheLink]

Would someone who took over the domain be able to communicate which certificate and thus which CA is to be used?

If they can do that then what is there to prevent an MITM attack in the "Hostile Gov" scenario?

Does DNSSEC really help in for such scenarios?

Re:Just make a good security standard already

[ArsenneLupin]

Would someone who took over the domain be able to communicate which certificate and thus which CA is to be used?

Depends on exactly what you mean by "took over the domain". If you mean, the attacker somehow managed to corrupt the actual DNS server of the domain, then sure.

But most attackers don't do that. Indeed, if the attacker has such prowess, why not infiltrate the web server directly?

Instead, most attackers try to attack name servers nearer to the browser instead (such as in the user's vulnerable network router). And with DNSSEC, they now face the hurdle that they not only need to forge a certificate signed by any CA of his choosing among the hundreds trusted by most browsers, but that he must also first forge another certificate signed by one specific entity (the parent of the target domain).

So, DNSSEC used in such a way is still more secure than just CA certificates alone.

Re:Just make a good security standard already

[TheLink]

Because they don't have access to the web server but have access to the victims traffic (including DNS traffic). Example scenario: XYZ Gov vs people in XYZ country.

Re:Just make a good security standard already

[ArsenneLupin]

So, you're in the second case. Thanks for clarifying. Then continue reading paragraphs 3 and 4.

Re:Just make a good security standard already

[TheLink]

But can't the XYZ Gov get all those signed?

After all CNNIC (China) has their CA certs signed by Entrust. And the US Gov can probably get the big US CAs to sign whatever they want.

Thehackers generally won't MITM connections - they'd target the servers and users/clients. The Govs and ISPs are the ones who'd be able to mass MITM people. I don't live in a country with all those "nice amendments" to its Constitution, and my ISP has already MITMed my connections to insert ads, they seem to have stopped but who knows what else they would do.

In practice it probably wouldn't make a difference for most people since they would get phished ;).

Re:Just make a good security standard already

[ArsenneLupin]

But can't the XYZ Gov get all those signed?

Not if one of those depends (exclusively) on the ABC Gov. Of course, ABC and XYZ could always collude, but this makes the situation safer than the alternative, where XYZ could pull it off on its own.

Re:Just make a good security standard already

[Lennie]

Here are some facts about DNSSEC and handling of certificates with DNSSEC:
1. DNSSEC is used to sign the answers from the authoritive nameservers of a domain
2. This means answered can only be dropped, not faked. Obviously this only works if the the receiver verifies it.
3. 'above' the top-level-domains (com, org, edu, country tlds: uk, de) is the root, which has it's own nameservers
4. the procedure for signing the root and the procedures to get something changed at the root are long and have many checks, I don't expect anymore to be able to change or hack it.
5. the public key (or hash of that) of the root is the only thing that is needed to verify anything which is DNSSEC-signed if it is part of the normal DNS-hierarchy.
6. Each TLD has one organisation, the registry, who deals with the content of the TLD, the TLD points to the individual domains within the TLD
7. When a domain is registered by their owner they do this at a 'registrar', they register it for them at the registry
8. If the TLD supports DNSSEC, they will sign their own domain, the TLD, first and send a 'DS-record' to the root
9. the DS-record is a hash of the public key of the domain
10. sometimes the hosting-provider is also the registrar or they outsource that part to one.
11. When a domain-owner wants their domain DNSSEC-signed they will need to sign their domain. And they will need to update their keys every few weeks or months just to be save.
12. They also need to send a DS-record to their parent, the TLD.
13. All parts of this process can be handled by the domain owner or outsourced to for example a hosting-provider: creating the content of the domain, setting up and maintaining the nameservers, hosting the nameservers, signing the domain, being a registrar.
14. so when a domain-owner handles their own signing, they usually are not the registrar. So they have to send the DS-record to the registrar which sends it to the register (TLD-operater).
15. This might be automated with a XML-protocol over HTTPS like: EPP or possible send by email with PGP for example.
16. when a TLD is signed and a DS-record for a domain is put in DNS, then this tells clients that a domain has to be signed with a suitable key.
17. when a TLD is signed and no DS-record for a domain is put in DNS (if something does not exist, this is also signed), then this tells clients that a domain is not signed.
18. DNSSEC is just signing, it is not encrypted.
19. There are a few protocols that can be used to add a signed record in DNS with the (hash of) a certificate which could tell a browser or other application which certificate to expect. The protocol with the most traction is probably DANE.
20. some systems use offline-signing for DNSSEC, which means every time a change in DNS is made, the whole domain has to re-signed on a seperate system
21. some systems use online-signing for DNSSEC, which means the key for signing is stored on the nameserver

So where are some of the problems ?
- if a TLD is stationed in a country where the government has access to the TLD, they can point it where they like. Maybe doing a man-in-the-middle attack of some sorts if they only redirect the traffic. If a domain is signed, it will not be possible/easy to redirect only part of that traffic with the use of DNS.
- if a hosting-provider gets hacked, all the domains can be changed or transfered.
- if a hosting-account gets hacked, the domains of a domain owner could be changed or transfered.
- handling DS-records properly is obviously very important
- when online signing is used, if a nameserver is hacked, the keys might stolen as well
- a lot of systems don't yet understand DNSSEC, so applications can't use them yet. They are for example: operating systems, DNS-serversoftware, firewalls, DSL-routers with DNS-relay functions.
- DNSSEC-signed answers are a lot bigger, some systems don't understand large(r) answers either
- a client can ask a 'caching DNS-server' (like at the ISP) to verify the DNS-answer, but obvi

Re:Just make a good security standard already

[jroysdon]

While the US could muck with the root zone, it would be a one-time event. The root only has records for the TLDs, like .COM, .NET, .CN, .RU.

While the US has mucked with gTLD zones by forcing Registrars in the US to point the DNS to their servers, they have never gone into the TLD zone itself or interfered with the operations of the gTLD zones directly. They could, but going the Registrar route is easier. Going directly to a TLD zone edit would also most likely be a one-time event.

When I say "one-time" event, I mean that if the US touches the root zone outside of the established processes, everyone else is going to insist that the UN or other International body maintain control and/or they will move to a new root under the control of the UN, etc.

As far as a "one-time" event for the gTLDs that the US controls, it will force anyone with any security mindset to move outside those gTLDs. In fact, this may already be the case for most due to the Registrar-based takeovers by the US ICE and others.

What moving to DNSSEC gives you is control at the "dot" level. The US (nor any other country outside of each country's own ccTLD) should have no control whatsoever for any ccTLDs (.CN, .RU, etc.) other than to maintain the root servers which point to the ccTLD NS and the DNSSEC info needed to establish the chain of trust from the root down.

The problem with SSL Root CAs is that they have global authority for all domains. DNSSEC authority is tied to the zone-level.

The problem with both is that a DoS/MitM attack can stop either from working. All I have to do is block DNSSEC records and you just have to say "oh well, I cannot get secure records back." But it is the same situation with a MitM SSL decrypt/encrypt with a fake Root CA (you just have to shrug and known you are not getting a secure connection).

Ultimately I think DNSSEC + CA certs servers/signatures in DNS which are limited to the zone they are for is going to be the way to go. This is going to take support on the Browser Vendors to get on board. Good news is Google Chrome is already on the way.

Re:Just make a good security standard already

[hairyfeet]

Uhhh...if they have root they'll HAVE the keys, so I don't even know if you could call it a MITM, more like "we own this thing" because with the root keys anything encrypted using that key could be decrypted by them since they have the private key, or am I wrong?

Either way i think the answer will come from hackers, tools like Freenet and Tor are just the beginning. Frankly the corruption is so thick in the USA right now I wouldn't trust the gov with privacy as far as i could throw your average lobbyist. I mean for the love of Pete they gave retroactive immunity for basically copying every bit that went through the AT&T networks!

Re:Just make a good security standard already

[Anonymous Coward]

The US Doesn'tt have a track record prior to 1750 of respecting privacy worthy of having any kind of power I'm sorry to say. All that we're now seeing is that politicians are not out to help their constituients but to line their own and family pockets while ensuring that they remain in power.

I thought the US didn't exist prior to 1776, or thereabouts?

Re:Just make a good security standard already

[kmoser]

...maliciously generates rouge certificates...use the root cert to create rouge certs for MITM attacks....

I didn't realize Sarah Palin was capable of creating certificates.

Re:Just make a good security standard already

[Anonymous Coward]

It is hardly an epic fail for TLS, when they fixed this damn issue FIVE YEARS ago, the only reason it is a problem is because there are too many lazy ass server admins running servers that only support TLS 1.0, which cause problems when browsers try to use a newer version so browsers don't enable the newer versions by default.

Re:Just make a good security standard already

[Anonymous Coward]

Well, you can't fault the accuracy of the statement. :P

Summary

[Anonymous Coward]

Summary for Technical People who don't want to read through a ton of crap:

Tor uses OpenSSL's "empty fragment" feature, which inserts a single empty TLS record before every record it sends. This effectively randomizes the IV of the actual records, like a low-budget TLS 1.1. So the attack is simply stopped.

Tor: What about different TCP-connections ?

[Lennie]

Tor it self is not vulnerable, but what about the webtraffic going over the Tor-channels ?

Does Tor route different TCP-connections to different destinations over the same Tor exit nodes ?

If not, I would think the Tor exit node can still attack you with this Man-in-the-middle attack.

Re:Tor: What about different TCP-connections ?

[Lennie]

Here is what I found on the Tor-site:
"For efficiency, the Tor software uses the same circuit for connections that happen within the same ten minutes or so. Later requests are given a new circuit, to keep people from linking your earlier actions to the new ones."

https://www.torproject.org/about/overview

That doesn't sound all that great.

Re:Tor: What about different TCP-connections ?

[TheLink]

You can always get it to change when you are about to do something that you think requires a new session.

What I do notice when using tor is that Facebook for some reason alternates between different certs. Facebook says the certs are OK but the whole situation does look very strange: http://dankaminsky.com/2011/08/31/notnotar/

To me it's no big deal if the US Gov is MITM'ing or cracking my facebook traffic - they can get everything straight from Facebook anyway ;).

Re:Tor: What about different TCP-connections ?

[Lennie]

Yes, I had read that article before.

This article is very misleading

[Anonymous Coward]

The headline here is completely wrong. The attack DOES affect users browing the web through tor. When you connect over https in tor, your web browser and the HTTP server on the other side are responsible for the encryption, and are completely vulnerable to the attack. Tor doesn't add any protection because it's just tunneling the already encrypted stream between the client computer and the tor exit node.

TFA is only about how TLS is used internally in TOR, not how TLS is used in browsers and other applications which connect through tor. It explicitly states:

Also, this only goes for the Tor software itself. Applications that use TLS need to watch out. Please install patches, and look for new releases if any are coming out soon.

Re:This article is very misleading

[Lennie]

As I posted above, I think a Tor exit node might be a good place for an attacker.

It might be slightly harder to pulll off, you'll need a bit of luck.

DNSSEC

[Anonymous Coward]

Where your first and only line of defence is godaddy.
Or
Howabout convergence.io

Re:DNSSEC

[Lennie]

Why not combine it ?

You can have a convergence.io notary which does not just check HTTPS-sites, but also checks DNSSEC.

You don't need to use BEAST

[sgt scrub]

Tor's flaw is not MIM attacks, it is not knowing who owns the exit node.

Re:You don't need to use BEAST

[Anonymous Coward]

Evil nodes are *assumed* when you are using Tor. Everyone knows this.

Re:You don't need to use BEAST

[quickgold192]

Who cares who owns the exit node as long as the same entity doesn't own every other node in the circuit? And as long as you don't transmit any traceable information in plaintext?

Re:You don't need to use BEAST

[jroysdon]

Riiiiiiiight, and no government would ever set up thousands of Tor exit nodes just to watch traffic. Couldn't be done

Re:You don't need to use BEAST

[dohcvtec]

Riiiiiiiight, and no government would ever set up thousands of Tor exit nodes just to watch traffic. Couldn't be done

I don't have a citation, but Tor's circuit-building algorithm constructs the chain such that each of the 3 nodes are in different countries. A government can set up as many Tor nodes as they want, but unless they are also in different countries they still won't own enough of the chain to break it

Re:You don't need to use BEAST

[Anonymous Coward]

so having three buildings with internet access is beyond any government...

embassy...anyone...

Re:You don't need to use BEAST

[sgt scrub]

And governments don't share information. [/snark]

Re:You don't need to use BEAST

[sgt scrub]

Sad but true.

Opera & Chromium have a good solution

[Anonymous Coward]

Disabling javascript as I do does better, because I can't get infested by BEAST in the 1st place!

APK

P.S.=> For example? Opera allows for GLOBAL policy sets (not using potentially dangerous things like iframes, plugins, javascript, cookies, etc./et al, 1st)...

1.) Tools menu -> Preferences submenu -> Content left-hand-side ribbon item (uncheck them ALL as to javascript, iframes, cookies, & plugins, FIRST - this creates a "global default policy" of ONLY letting those potentially dangerous things run in the 1st place on sites you frequent, or don't frequent & stumble upon/are linked to).

Then, you can set "by site" prefs to run each/any (or all) of them individually BY SITES you choose, is how/why...

AND, again - If you don't use javascript (I avoid things like ecommerce because of it in fact)? You can't be harmed...

2.) Then, for example, to make an EXCEPTION? Say on YouTube (specifically since it regards FLASH)? Right-click on the page itself... the popup menu has an "EDITSITE PREFERENCES" menu item (use it): There is a CONTENT tab (for plugins & more), COOKIES tab, SCRIPT tab (javascript), DISPLAY tab (iframes/frames), & NETWORK tab (for leaving tracking info. of a sort)).

NOW, if you NEED to use javascript for ecommerce, but are worried the site's NOT "SSL safe" vs. BEAST?

You CAN check a site's SSL/TLS level (make sure its 1.1 or 1.2 @ least) via this method in Opera:

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu (outlines what type of SSL, TLS, certificates & such that a site offers, by PAGE no less).

OR, use this site:

https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45

(A google query for say, the Apache webserver can also help by showing you which mod_ssl level for OpenSSL is needed for it to be safe server-side too, ala -> http://www.google.com/search?sclient=psy-ab&hl=en&site=&source=hp&q=%22Apache%22+and+%22TLS%22&btnG=Search )

Incidentally, Chromium's latest builds can do pretty much the same via exceptions lists you can make, see screenshot here:

http://it.slashdot.org/comments.pl?sid=2439924&cid=37481432

... apk

Re:Opera & Chromium have a good solution

[Lennie]

Should I respond...?

Hmm... well, if you enable javascript just on the sites you frequently visit will not make you save for attacks with BEAST.

With BEAST the attacker is between you and all (most/enough) sites you visit. If you have any site you allow JavaScript on (AND which only uses HTTP) the attacker can inject JavaScript on that page as well. Well, than again. Just disable Java-applets, seems the current attack still depends on Java-applets.

If you want to check on TLS/1.1 TLS/1.2 you will need to enable it in your browser AND check the website you linked, not OR. Both need to have it enabled.

Re:Opera & Chromium have a good solution

[Anonymous Coward]

Learn to read on OR where 2 tools are shown by apk for testing website SSL TLS levels by using OR correctly for that (not for doing tls 1.2 in opera, "or", using the tools in Opera that check site security or the weblink instead if not using both to double-verify).

Quoting apk directly here on how OR was used which you misunderstood or jumped the gun on from his original post you just erroneously replied to here:

http://it.slashdot.org/comments.pl?sid=2444720&cid=37508248

You CAN check a site's SSL/TLS level (make sure its 1.1 or 1.2 @ least) via this method in Opera:

Opera's View menu -> Developer Tools submenu -> Page Security Info submenu (outlines what type of SSL, TLS, certificates & such that a site offers, by PAGE no less).

OR, use this site:

Guess you shouldn't have replied Lennie, since you asked. It only showed us you jumped the gun without reading carefully, because apk not only enables tls 1.1/1.2 but also checks sites for levels of ssl tls encryption used with 2 tools for it. He's safest of all by not using javascript though. That's how you get beast infected in the first place.

Re:Opera & Chromium have a good solution

[Lennie]

Maybe, I did misread his comment this time round.

I guess I expected APK to mention how to enable TLS/1.1 and TLS/1.2, because they are not enabled by default.

I never enable javascript though

[Anonymous Coward]

Ever, & since that is the case? I don't contract BEAST either. Pretty simple, first of all...

Secondly - This IS what I meant anyhow, you're just restating it:

"If you want to check on TLS/1.1 TLS/1.2 you will need to enable it in your browser AND check the website you linked, not OR. Both need to have it enabled." - by Lennie (16154) on Sunday September 25, @12:08PM (#37508380) Homepage

Thus: Hence, why I offered up the methods of testing the site AND by mentioning TLS 1.2 in Opera, as well as completely "proofing yourself vs. BEAST" by not using javascript @ all (as I do, & not just vs. this attack, but myriads of others also)... apk

Re:I never enable javascript though

[WaffleMonster]

Ever, & since that is the case? I don't contract BEAST either. Pretty simple, first of all...

What is to stop someone from using a location redirect header to collect encrypted response known plaintext with javascript disabled?

Re:I never enable javascript though

[Anonymous Coward]

What's that got to do with the price of tea in China (or BEAST), hmmm?

APK

Lennie, come on: Are you stalking/nitpicking

[Anonymous Coward]

Trying to also insinuate that I, of all people here, DON'T KNOW or NEVER MENTION that you need to enable TLS 1.1/1/2 in Opera?

Well, apparently not, per this exchange we had the other day: http://it.slashdot.org/comments.pl?sid=2439924&cid=37478006

Want more like it, such as -> http://news.slashdot.org/comments.pl?sid=2437606&cid=37462834

OR (pun intended) here now too?

APK

P.S.=> If you're NOT nitpicking, then fine, but seems like you are (You MAY be trying to be "thorough" here, after all, right? LOL!) Hey - we (you & I) covered this ground days ago, & yes, despite you saying there was no GUI for a SECURITY CHECK, Opera has one I noted here (lol, "surprise-surprise" U FAIL ON THAT NOTE, lol...)... apk

Look familiar Lennie?

[Anonymous Coward]

http://it.slashdot.org/comments.pl?sid=2439924&cid=37478006

APK

P.S.=> How many times do I have to mention it? apk

PSI NET/Cogent Communications

[E.I.A]

What I'd like to know, is why such a huge portion of TOR traffic traverses PSI-NET through Washington DC. I am skeptical about this to some extent.

Wasn't this fixed like a DECADE ago?

[WaffleMonster]

This smells like the same issue openssl patched 10 years ago.

Am I correct in assuming as long as you don't set
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS your good to go and this attack does NOT effect you for SSL 3/TLS1?

If not is there any protocol level information avaliable? The gooblygook in TFA is not particularly helpful.

Re:Wasn't this fixed like a DECADE ago?

[Anonymous Coward]

I don't think so, it uses the issue that was fixed with TLS v1.1 and was previously just thought to be a theoretical vulnerability. Unfortunately many web servers don't accept above TLS v1.0 and break if you try to use a higher version which is why browsers don't automatically enable TLS v1.1 and TLS v1.2.

you missed this part

[Onymous Coward]

Tor uses OpenSSL's "empty fragment" feature, which inserts a single empty TLS record before every record it sends. This effectively randomizes the IV of the actual records, like a low-budget TLS 1.1. So the attack is simply stopped.