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?

[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

[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.

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.

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

[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

[sgt scrub]

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

Re:You don't need to use BEAST

[sgt scrub]

Sad but true.

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

[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.

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: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?

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.