Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Communications Encryption The Internet

Why the BEAST Doesn't Threaten Tor Users 54

Posted by timothy from the shaken-and-stirred-and-scrambled dept.
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.
This discussion has been archived. No new comments can be posted.

Why the BEAST Doesn't Threaten Tor Users More

Why the BEAST Doesn't Threaten Tor Users

Comments Filter:

  • Bad Cert? (Score:1)

    by Anonymous Coward

    and the link throws an SSL error, sorry not going

    • Re: (Score:1)

      by Anonymous Coward

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

  • Just make a good security standard already (Score:4, Insightful)

    by Co0Ps ( 1539395 ) on Sunday September 25, 2011 @08:31AM (#37507510)

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

    • Comment removed based on user account deletion

      • Re: (Score:2)

        by Co0Ps ( 1539395 )
        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

        • Re: (Score:2)

          by Lennie ( 16154 )

          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: (Score:2)

            by TheLink ( 130905 )
            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?

            • 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

              • Re: (Score:2)

                by TheLink ( 130905 )
                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.
                • So, you're in the second case. Thanks for clarifying. Then continue reading paragraphs 3 and 4.

                  • Re: (Score:2)

                    by TheLink ( 130905 )
                    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 kn

                    • 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: (Score:2)

              by Lennie ( 16154 )

              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 do

        • Comment removed based on user account deletion

        • Re: (Score:1)

          by kmoser ( 1469707 )

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

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

      • 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" ev

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

      What about you?

    • Re: (Score:3)

      by Lennie ( 16154 )

      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 prot

  • Summary (Score:2, Informative)

    by 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 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: (Score:2)

      by Lennie ( 16154 )

      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 [torproject.org]

      That doesn't sound all that great.

      • Re: (Score:2)

        by TheLink ( 130905 )

        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/ [dankaminsky.com]

        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 ;).

  • This article is very misleading (Score:1)

    by 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 applicatio

    • Re: (Score:2)

      by Lennie ( 16154 )

      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.

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

  • You don't need to use BEAST (Score:3, Informative)

    by sgt scrub ( 869860 ) <saintium@yahoAAAo.com minus threevowels> on Sunday September 25, 2011 @09:38AM (#37507854)

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

    • Re: (Score:2, Interesting)

      by Anonymous Coward

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

    • Re:You don't need to use BEAST (Score:4, Insightful)

      by quickgold192 ( 1014925 ) on Sunday September 25, 2011 @01:17PM (#37509054)
      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?

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

        • 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

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

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

Slashdot Top Deals

"Our vision is to speed up time, eventually eliminating it." -- Alex Schure

Close