Blog

What the Renegotiation Bug Means to You

By David J. Meier

A few weeks ago a new TLS and SSLv3 renegotiation vulnerability was disclosed, and there’s been a fair bit of confusion around it. When the first reports of the bug hit the wire, my initial impression was that the exploit was too complex to be practical, but as more information comes to light I’m starting to think it’s worth paying attention to. Since every web browser and most other kinds of encrypted Internet connections – such as between mail servers – use TLS or SSLv3 to protect traffic, the potential scope for this is massive.

The problem is that TLS and SSLv3 allow renegotiation outside of an established TLS connection, creating a small window of opportunity for an attacker to sit in the middle and, at a particular phase of a connection, inject arbitrary data. The key bits are that the attacker must be in the middle, and there’s only a specific window for data injection. The encryption itself isn’t cracked, and the attacker can’t read the encrypted data, but the attacker now has a hole to inject something which could allow unanticipated actions, such as sending a command to a web application a user is connected to.

A lot of people are comparing this to Cross Site Request Forgery (CSRF), where a malicious website tricks the browser into doing something on a trusted site the user is logged into, like changing their password. This is a bit similar because we’re injecting something into a trusted connection, but the main differentiator is where the problem lies. CSRF happens way up at the application layer, and to hit it all we need to do is trick the user (or their browser) to get access. This new flaw is at a networking layer, so we have a lot less context or feedback.

For the TLS/SSL attack to work, the attacker has to be within the same local network (broadcast domain) as the victim, because the exploit is at the “transport” layer. This alone decreases the risk significantly right out of the gate.

Is this a viable exploit tactic? Absolutely, but within the bounds of a local network, and within the limits of what you can do with injection. This attack vector is most useful in situations where there is easy access to networks: unsecured WiFi and large network segments that aren’t protected from man in the middle (MITM) attacks. The more significant cause for concern is if you are running an Internet facing web application that is:

  • Vulnerable to the TLS/SSL renegotiation vulnerability as described and either…
    • Running a web app that doesn’t have any built in application layer protections (anti-CSRF, session state, etc.).
    • Running a web app that allows users to store and retrieve things using simple POST requests (such as Twitter).
  • Or using TLS/SSLv3 as transport security for something else, such as IMAP/SSL, POP/SSL, or SMTP/TLS…

In those cases, if an attacker can get on the same network as one of your users, they can inject data and potentially cause bad things to happen, possibly even redirecting your user to a new, malicious site. One recent example (since fixed) showed how an attacker could trick Twitter into posting the user’s account credentials.

Currently the draft of the fix binds a renegotiation handshake to a particular already established TLS channel, which closes the hole. Unfortunately, since SSLv3 does not support extensions there is no possible way for a secure renegotiation to happen; thus the death of SSL is nigh, and long live (a fixed) TLS.

No Related Posts
Comments

@Meier:

I think what you’ve said above is pretty accurate and does properly frame the risk to most people. Will this mean the death of SSL? I think that conclusion is logical, but reality suggests it’ll linger for a very long time, yet.

One thing I’m not seeing much since the original (way too technical!) details: client certificates.

I’ll grant that the issue with client certificates does not affect your normal anonymous web surfers, but it should get the interest of anything that uses smart cards or embedded authentication via certificates. From my weak understanding of this problem, you can snarf and repurpose those certs if you, again, get into a MITM situation. Stealing auth versus injecting some data is a pretty significant escalation, but to a smaller audience.


Three other thoughts.

1) Injecting something to the client’s browser is one thing, but it does open up the possibility of loading and attacking the client. Then again, if you can plant a payload on the server in the first place….. Also, if you can MITM anyway, why not just strip out SSL in the first place? But, this does allow for injected data into what is otherwise an apparently trusted, encrypted connection: trust breakdown.

2) What happens if/when someone can inject a POST? Things get slightly more interesting there. POST password change?

3) Sounds like a nice feature to add to The Middler and similar tools.

By LonerVamp


The problem with SSLv2 use is that it still gets turned on by default on *servers.* Even IIS 6 still has it on by default. I’m not sure about IIS 7 or Apache off the top of my head. It takes effort to actually turn that stuff off, even today and no one does it unless they have to (ignorance, not choice).

Still, most modern browsers shouldn’t start at SSLv2, but it should still be disabled anyway so you don’t have a MITM downgrade attack. (Not that I’ve ever really heard of any real attacks to break into SSLv2 connections other than theoretical ones…)

I’ve also recently had to turn off those, “You’re using SSLv2, please upgrade…” messages on my load-balance hardware because of auditors. They tend to just run an SSL scan and if it negotiates, fails the specific check in PCI for, “Don’t use SSLv2.” Despite the fact if you connect you’ll see I’m not really allowing it and telling users to stop using antiquated browsers.

I don’t think I’ve even seen any attempts to use SSLv2 other than testers or myself, in over a year.

By LonerVamp


In terms of the Ebay connection if you simply send any arbitrary data after that connection you’ll see the error:

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Length: 309
Content-Type: text/html

<html><body><b>SSL Protocol Alert</b><p>The SSL protocol version that your browser uses is SSLv2 and it is not compatible with the server settings. </p><p>Please try the following:</p><p>- Check the SSL protocol settings on your browser for SSLv3/TLSv1 protocol support and enable the same. </p></body></html>closed

...I see your point, some still use it.  Why, who knows—especially any banks or even newer startups like Twitter.

I couldn’t get the straight up regular McAfee site to allow SSL, but you may have a different ingress point that you had tried.

So you think Bank of America has ever passed a PCI audit?  Wonder who the QSA was?  Someone should tell them RC4-MD5 might be weak.  :)

By David J. Meier


Okay I tried it:

openssl s_client -connect ebay.com:443 -ssl2

New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
SSL-Session:
  Protocol : SSLv2
  Cipher   : DES-CBC3-MD5
  Session-ID: D5F3FA4A3750154014CE495E96E36139
  Session-ID-ctx:
  Master-Key: 35F5ED93B6FC890AA84EBFCE849E9EE54919C8D3FA38D35F
  Key-Arg   : 63826612A872A6AD
  Start Time: 1258654301
  Timeout   : 300 (sec)
  Verify return code: 21 (unable to verify the first certificate)

So something thinks it can speak sslv2, however if I force my browser to use only sslv2 it loops before dying so there’s some business logic stopping it. On the other hand, yahoo and hotmail/live.com both allow ssl2 connections no problem as does twitter and lenovo. Btw, so does Bank of America and Fidelity. So while clearly some folks are getting it (because of PCI?), there are some major players who don’t.

Btw even the security vendors don’t do it right, McAfee allows SSLv2 only connections (Symantec doesn’t) as does HiTrust (gotta love an organization dedicated to security that screws it up).

And my all time favorite, the IRS allows SSLv2 connections _and_ has an invalid cert.

So lots of potentially vulnerable sites, which in general make MitM attacks much easier, renegotiation bug or not.

By David Mortman


Mortman,

No, but I think it may be where you’re making an assumption.  Just for fun try to go to most any banking site with *only* SSLv2 turned on.  It doesn’t work.  It doesn’t give you a warning, it just doesn’t display the page.  So, sure, your browser may support SSLv2, but the banks don’t anymore—and, in all reality the end user doesn’t notice (even when SSLv2 is still available in their browser).

Sure, the miscreants can force the end users to **try** and fall back to SSLv2, but the server has to support it.  I think you’d be surprised how many legit sites don’t allow it.  Go try it out.  Ebay doesn’t work.  Google doesn’t work.  NYTimes doesn’t work (when choosing to use HTTPS). Securosis.com doesn’t work.  So - the client doesn’t matter in the renegotiation bug if you are trying to direct the attack to a specific site.  Sure, if you want to direct me elsewhere, go for it, downgrade my connection all you want…  The problem is, you can do whatever you want if you’re MITMing me already anyway.

So, again, I am going to respectfully disagree on your stance.  SSLv2 has been dead a while (from a server perspective).

By David J. Meier


Meier,

You’re missing the point. I personally have had SSLv2 disabled in my browsers for years. But the reality is that it doesn’t matter if things work with SSLv2 disabled or not because it wasn’t until firefox 3 that it was disabled by default and I can’t remember which version of IE disabled it by default.

As a result, the vast majority of web users have it turned on by and an even greater proportion of web servers have it turned on as well. This means that the miscreants can potentially force the use of it when they want via this renegotiation bug.

If we can’t get something as basic as SSLv2 turned off and out of production use over a decade after we know that it has some fundamental architecture issues, what makes you think we can get rid of SSLv3?

By David Mortman


Meier,

I know we’re going to keep 443, because STARTTLS isn’t appropriate for HTTPS.

Yes, I have a bunch of naive users. By blocking ports 110 & 143, I can ensure that they never transmit their passwords to my system in plaintext—just like blocking telnet and forcing ssh. I also have postfix (25 & 587) configured to require STARTTLS before AUTH, but this option came along relatively recently, and it’s harder for me to trust. I *know* no mail client will ever send plaintext to port 993 or 995, because it will never receive a plaintext prompt on those ports.

The firewall isn’t to detect and stop plaintext. It’s to very simply ensure no user email client ever sends their credentials as cleartext.

STARTTLS is more secure than plaintext, but I don’t see how it’s more secure than full-time encryption. It’s certainly more complicated to administer than full-time encryption.

By Chris Pepper


Mortman,

I’m not sure what browser your using, but if you’re still using SSLv2 I feel bad for you!  SSLv2 is not on by default in FireFox (just verified).  Sure, it is supported, but v2 was so ripe with problems it’s why there was only 1 year between v3.

Again, turn off SSLv2/3 (although I really hope v2 is not actually on) in your browser and see what problems you run into.  You’re using TLS for the majority of your encrypted web sessions today, I guarantee it.

By David J. Meier


Chris,

From a web perspective you’re always going to have 80 and 443 open regardless anyway - so it’s a no change to your current practice, and in a web situation you don’t use STARTTLS and it’s no different on setting up the encrypted session from SSL (do packet dump of a TLS connection being setup and you’ll see this).  STARTTLS isn’t used in web traffic.

From a TLS perspective, say, for IMAP or SMTP it doesn’t change anything either - that’s the way it’s designed to work.  It’s a question of if the feature set is supported, you bind to 25, start your session, say STARTTLS and you move to an encrypted session (this is a good thing).  This **adds** security to an old standard way of moving mail around without impacting firewalls and the like.  At the end of the day STARTTLS is an extension to plaintext comms, it doesn’t change anything about TLS or how it works - they aren’t the same.

Your firewall rules don’t buy you anything but a warm fuzzy of blocking unencrypted connections.  I can run plaintext or encrypted data all over the board and the majority of firewalls out there won’t flinch, your firewall buys you nothing in that regard.  So, I would respectfully disagree with your perspective on TLS being a step backward, when, it’s really SSL progressing forward.

By David J. Meier


<i>SSLv3 will go away just like SSLv2/1 did</i>

Then we are truly up the creek.

SSLv1 - 1994 private release by Netscape
SSLv2 - February 1995 first open release of SSL
SSLv3 - 1996
TLS - January 1999

Thirteen years after a more secure option became available, SSLv2 is still enabled by default on every major web server (OpenSSL just removed it this summer) and until very recently was enabled by default on every major web browser.

So I think we’ve got a long way to go before we can safely say SSLv2 is gone and even longer before SSLv3. TLS only solves the problem if that’s the only option, otherwise malicious parties can force a less secure conversation.

By David Mortman


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.