Skip navigation
1 2 3 Previous Next

Security Labs

33 Posts authored by: Ivan Ristic

Heartbleed is a name for a critical vulnerability in OpenSSL, a very widely deployed SSL/TLS stack. A coding error had been made in the OpenSSL 1.0.1 code, which was subsequently released in March 2012. The vulnerability is in the rarely used heartbeat mechanism, specified in RFC 6520. The error allows an attacker to trick the server into disclosing a substantial chunk of memory, repeatedly. As you can imagine, process memory is likely to contain sensitive information, for example server private keys for encryption. If those are compromised, the security of the server goes down the drain, too.


Your server is probably vulnerable if it's running any version in the OpenSSL 1.0.1 branch. If you'd like to verify if you're vulnerable, today I released a new version of the SSL Labs Server Test. I went through a lot of effort to implement a test that doesn't attempt exploitation (no server data is retrieved). So it should be safe to use. Despite the availability of the test, if you can identify the library version number, I would urge to assume that you are vulnerable, even if the test is not showing a problem.


It's difficult to underestimate the impact of this problem. Although we can't conclusively say what exactly can leak in an attack, it's reasonable to assume that your private keys have been compromised. Addressing this issue requires at least three steps: 1) patch, 2) replace the key and certificate, and 3) revoke the old certificate. After that you will need to consider if any additional data might have been leaked too, and take steps to mitigate the leak.


Unless your server used Forward Secrecy (only about 7% do), it is also possible that any past traffic could be compromised, but only if you are faced with a powerful adversary who has means to record and store encrypted traffic. If you did not before Forward Secrecy before, now is a great time to ensure you do support it from now on. If this topic is new for you, you can follow my advice here and here.


For more details on the nature of this OpenSSL blog, have a look at this post from Matthew Green.


Mixed content issues arise when web sites deliver their pages over HTTPS, but allow some of the resources to be delivered in plaintext. The active network attacker can't do anything about the encrypted traffic, but messing with the plaintext can result with attacks ranging from phishing in the best case to full browser compromise in the worst. A single exposed script is sufficient: the attacker can hijack the connection and inject arbitrary attack payloads into it.


We tend to talk a lot about other aspects of SSL/TLS, but mixed content is arguably the easiest way to completely mess up your web site encryption.


In the very early days of the Web, all mixed content was allowed; web browsers expected site operators to think through the consequences of mixing content. That, of course, did not result with great security. Site operators did whatever they needed to get their work done and decrease costs. Only in recent years did browser vendors start to pay attention and start to restrict mixed content.

Mixed content in modern browsers

Today, almost all major browsers tend to break mixed content into two categories: passive for images, videos, and sound; and activefor more dangerous resources, such as scripts. They tend to allow passive mixed content by default, but reject active content. This is clearly a compromise between breaking the Web and reasonable security.


Internet Explorer has been the leader in secure mixed content handling. As early as Internet Explorer 5 (according to this post), they had detection and prevention of insecure content by default. Chrome started blocking by default in 2011, and Firefox in 2013. The default Android browser and Safari, however, still allow all mixed content without any restrictions (and with almost non-existent warnings).


Here are the results of my recent testing of what insecure content is allowed by default:


Android browser 4.4.xYesYesYesYesYesYes
Chrome 33YesNoNoYesYesNo
Firefox 28YesNoNoNoNoNo
Internet Explorer 11YesNoNoNoNoNo
Safari 7YesYesYesYesYesYes


They are mostly as expecting, but there's a surprise with Chrome, which blocks active page content, but still allows plaintext XMLHttpRequest and WebSocket connections.


It's worth mentioning that the table does not tell us everything. For example, browsers tend not to control what their plugins do. Further, certain components (e.g., Flash or Java) are full environments in their own right, and there's little browsers can do to enforce security.

Testing for mixed content handling in SSL Labs

To make it easier to evaluate browser handling of this problem, I recently extended the SSL Labs Client Test to probe mixed content handling. When you visit the page, your user browser is tested, and you will get results similar to these:



Mixed content prevalence

Anecdotally, mixed content is very common. At Qualys, we investigated this problem in 2011, along with several other application-level issues that result with full breakage of encryption in web applications. We analysed the homepages of about 250,000 secure web sites from the Alexa  top 1 million list, and determined that 22.41% of them used insecure  content. If images are excluded, the number falls to 18.71%.


A more detailed study of 18,526 sites extracted from Alexa top 100,000 took place in 2013: A Dangerous Mix: Large-scale analysis of mixed-content websites (Chen et al.). For each site, up to 200 secure pages were analysed, arriving at a total of 481,656 pages. Their results indicate that up to 43% of web sites have  mixed content issues.


The best defence against mixed content issues is simply not having this type of problem in your code. But that's easily said than done; there are many ways in which mixed content can creep up. When that fails, there are two technologies that can come useful:


  • HTTP Strict Transport Security (HSTS) is a mechanism that enforces secure resource retrieval, even in the face of user mistakes (attempting to access your web site on port 80) and implementation errors (your developers place an insecure link into a secure page). HSTS is one of the best thing that happened to TLS recently, but it works only on the hostnames you control.
  • Content Security Policy (CSP) can be used to block insecure resource retrieval from third-party web sites. It also has many other useful features for to address other application security issues, for example XSS.

On Friday, Apple released patches for iOS 6.x and 7.x, addressing a mysterious bug that affected TLS authentication. Although no further details were made available, a large-scale bug hunt ensued. This post on Hacker News pointed to the problem, and Adam Langley followed up with a complete analysis.


I've just released an update for the SSL Labs Client Test, which enables you to test your user agents for this vulnerability.


This bug affects all applications that rely on Apple's SSL/TLS stack, which probably means most of them. Applications that carry with them their own TLS implementations (for example, Chrome and Firefox) are not vulnerable. For iOS, it's not clear when the bug had been introduced exactly. For OS X, it appears that only OS X 10.9 Mavericks is vulnerable.


What you should do:

  • iOS 6.x and 7.x: Patches are available, so you should update your devices immediately.
  • OS X 10.9.x: Apple promised a fix would be available soon. Update as soon as it is released. The vulnerability has been fixed in 10.9.2. Update immediately. 

Today, we're releasing a new version of SSL Rating Guide as well as a new version of SSL Test to go with it. Because the SSL/TLS and PKI ecosystem continues to move at a fast pace, we have to periodically evaluate our rating criteria to keep up.


We have made the following changes:


  • Support for TLS 1.2 is now required to get an A. If this protocol version is not supported, the grade is capped at B. Given that, according to SSL Pulse, TLS 1.2 is supported by only about 20% servers, we expect this change to affect a large number of assessments.
  • Keys below 2048 bits are now considered weak, with the grade capped at B.
  • Keys below 1024 bits are now considered insecure, and given an F.
  • MD5 certificate signatures are now considered insecure, and given an F.
  • We introduce two new grades, A+ and A-, to allow for finer grading. This change allows us to reduce the grade slightly, when we don't want to reduce it to a B, but we still want to show a difference. More interestingly, we can now reward exceptional configurations.
  • We also introduce a concept of warnings; a server with good configuration, but with one ore more warnings, is given a reduced grade A-.
  • Servers that do not support Forward Secrecy with our reference browsers are given a warning.
  • Servers that do not support secure renegotiation are given a warning.
  • Servers that use RC4 with TLS 1.1 or TLS 1.2 protocols are given a warning. This approach allows those who are still concerned about BEAST to use RC4 with TLS 1.0 and earlier protocols (supported by older clients), but we want them to use better ciphers with protocols that are not vulnerable to BEAST. Almost all modern clients now support TLS 1.2.
  • Servers with good configuration, no warnings, and good support for HTTP Strict Transport Security (long max-age is required), are given an A+.


I am very happy that our rating approach now takes into account some very important features, such as TLS 1.2, Forward Secrecy, and HSTS. Frankly, these changes have been overdue. We originally meant to have all of the above in a major update to the rating guide, but we ran out of time, and decided to implement many of the ideas in a patch release.


Last week, on October 22, Apple released OS X 10.9 Mavericks, the latest version of their desktop operating system. This was a very important update, given that Safari now, in version 7, supports TLS 1.2. We are slowly moving toward a world in which TLS 1.2 is widely supported. Still, I wanted more. I was hoping that this OS X release was also going to have BEAST mitigations enabled by default. After all, the code was already a part of the previous OS X release (Mountain Lion) and the compatibility risks are minimal given that all other major browser vendors enabled the 1/n-1 split in early 2012.


Going through the security release notes, I was excited to see the BEAST attack (CVE-2011-3389) mentioned, but the explanation of the fix was disappointing. It said:

This issue was addressed by enabling TLS 1.2.

The BEAST attack affects only TLS 1.0 and earlier protocols, but client-side support for TLS 1.2 is currently not sufficient as defence because (1) only about 20% of servers support this protocol version and (2) all major browsers are susceptible to protocol downgrade attacks, which can be carried out by active MITM attackers.


There was still hope that the release notes were incomplete and I didn't want to give up just yet. Given that Apple releases parts of their operating system as open source and that the code for 10.9 was already available, I thought that reading the source code would be a good starting point. And I knew where I should look, because I had previously examined the SSL stack of Mountain Lion.


Today, I was delighted to see that the code had been changed, and that the default setting had been changed from disabled to enabled, meaning that the SSL stack that ships with OS X 10.9 uses BEAST mitigations by default. To see for yourself, look for the first mention of defaultSplitDefaultValue in the source code. It's near the top of the file.


Just to be completely sure, I subsequently observed the 1/n-1 split in action using Safari 7 and Wireshark, against a server running TLS 1.0 with only a single CBC suite configured.

Enabling mitigations on Mountain Lion

If you're still running the previous OS X version and do not wish to upgrade at this time, you can manually enable the BEAST mitigations by executing the following command:


$ sudo defaults write /Library/Preferences/ SSLWriteSplit -integer 2


At the very least, you will need to restart Safari; it's probably best to restart the computer. (Disclaimer: I don't have a Mountain Lion installation and have not tried this procedure for myself.)

BEAST has finally been mitigated client-side

With this, we can finally conclude that BEAST has been sufficiently mitigated client-side, and move on.

Update (11 Nov 2013): Even though the source code indicates that the migitation can be controlled, in practice that does not seem to be the case. It is possible that there is a bug in the CoreFoundation framework that prevents the code from reading the settings correctly. Replacing kCFPreferencesAnyHost with kCFPreferencesCurrentHost in the CFPreferencesCopyValue() invocation makes it work, but requires a one-byte patch to the relevant system library. This investigation is the work of Stefan Becker, who also reported the problem to Apple.


In October we made several changes to how we produce our monthly SSL Pulse reports. They include starting tracking Forward Secrecy and RC4, and removing the requirement to mitigate BEAST server side.

Forward Secrecy

Given the increased importance of Forward Secrecy (FS) in SSL/TLS server configuration, SSL Pulse now tracks support for it among the servers in our data sample.



Just before the October SSL Pulse scan began, we made some tweaks to the way we test, moving away from a simple binary test (Yes or No for Forward Secrecy support) to something more granular and more useful. Now, there are several possible outcomes:


  • Not supported - there are no FS suites in the server configuration.
  • Some FS Suites enabled - the server negotiates FS with some browsers.
  • Used with modern browsers - all modern browsers negotiate a FS suite. This will typically happen with a server that has support for ECDHE suites.
  • Used with most browsers - most browsers negotiate a FS suite. This will typically happen with a server that supports ECDHE suites, but falls back to DHE for clients that do not support Elliptic Curve cryptography.


You can see the October results in the following screen capture:



The results show that a large chunk of the servers (54%) does not use Forward Secrecy with any of the desktop browsers. However, a pretty large chunk (41.8%) does use it with some of the browsers. Only a small number support Forward Secrecy with modern browsers (3.6%), and an even smaller number (0.6%) support robust Forward Secrecy across most browsers.


We took this opportunity to also start tracking support for RC4 suites. As you may remember, earlier this year we learned that RC4 is much weaker than previously thought. In SSL Labs we now categorise RC4 support as follows:


  • Not supported - no RC4 suites supported.
  • Some RC4 suites enabled - server configuration contains RC4 suites, but they might not be actually used. For example, some servers will keep them around to use as a last resort.
  • Used with modern browsers - RC4 is used with at least one modern browser. This shows the servers where RC4 is not used as backup.


And the results are as follows:


As you can see, the green area is very small; only 7.2% servers do not support RC4. This is not very surprising, as RC4 is one of the most popular ciphers in SSL. Most servers (56.3%) have at least one RC4 suite enabled, but they are not always used. But more than a third of servers (36.5%) actually use RC4 with at least one modern browser. This is the number we need to bring down.


This month we stopped requiring server-side mitigation for the BEAST vulnerability. Even though BEAST can still be a problem for some, the impending threat of RC4 means that we must give up on BEAST so that we can start phasing RC4 out.


Given that we are not yet penalizing servers that support RC4, the change in our rating means that there is a much higher number of servers that we consider secure:


But, with more than 50% of the servers supporting RC4, the number of secure sites will most definitely fall again in the following months.


openssl-cookbook-cover.pngOpenSSL Cookbook is a free ebook based around one chapter of my in-progress book Bulletproof SSL/TLS and PKI. The appendix contains the SSL/TLS Deployment Best Practices document (re-published with permission from Qualys). In total, there's about 50 pages of text that covers the OpenSSL essentials, starting with installation, then key and certificate management, and finally cipher suite configuration.



The first version of OpenSSL Cookbook was published in May, but now, five months after that release, I've released version 1.1. The changes in this version are as follows:


  • Updated SSL/TLS Deployment Best Practices to v1.3. This version brings several significant changes: 1) RC4 is deprecated, 2) the BEAST attack is considered mitigated server-side, 3) Forward Secrecy has been promoted to its own category. There are many other smaller improvements throughout.
  • Reworked the cipher suite configuration example to add Forward Security as a requirement, making the example more useful in practice.
  • Increased coverage of different key types with a discussion of ECDSA keys. Explained when each type is appropriate.
  • Added new text to explain how to generate DSA and ECDSA keys.
  • Explained the challenge password, when generating Certificate Signing Requests.
  • Marked cipher suite configuration keywords that were introduced only in the OpenSSL 1.x branch. This makes it easier to use the text for reference purposes, if you're still running the older, OpenSSL 0.9.x, version.


You can get your copy from here.


I am delighted to introduce the most recent addition to the SSL Labs web site, the SSL Client Test. For some reason, even though we released sslhaf, our passive client fingerprinting tool, back in 2009, our attention until now remained on server testing only.


Then, this year, there was a noticeable increase in the interest in computer security and browser capabilities specifically, which led many of our users to ask us to implemented a client test. We already had a page that displayed the capabilities of well known browsers (linked from the Handshake Simulator section); from there, it was really easy to show what your browser can do.


Behind the scenes we rely on sslhaf to extract the entire raw client handshake request and make it available to our application (implemented in Java). From there, we simply disassemble the available information and present it to the user.


With the client test, you are now able to see the SSL/TLS capabilities of your preferred browser simply by visiting the test page. And, because the SSL protocol is designed in such a way that clients always tell servers about their capabilities, the best part is that testing does not take much time. In fact, it's pretty much instantaneous.


We are releasing an update to our SSL/TLS Deployment Best Practices document, which is our comprehensive guide to running secure servers. This is our third update since the first release in February 2012; our main goal is to keep the document up to date with the threats as they're evolving.



Since the beginning of the year we saw three major developments:


  • In March, a group of security researchers demonstrated that RC4 is seriously broken. Although the attack is not yet very practical, we are now recommending that this cipher is phased out. In the previous versions of the guide we had recommended using RC4 to mitigate the BEAST attack server-side. Clearly, this is no longer possible. Although we think that the BEAST attack can still be a threat in some environments, disabling RC4 globally will take a long time and we believe that we need to start that process straight away.
  • Last year, we learned about the CRIME attack, which uses information leakage stemming from compression before encryption. This year, CRIME evolved into TIME and BREACH, two attacks that go beyond attacking TLS compression (which is easy to disable without consequences) to attack the ubiquitous HTTP compression. Because they fall outside SSL/TLS, TIME and BREACH can only be addressed by making changes to application source code. For most, this approach will require a lot of work.
  • Finally, this year we also learned some details about widespread surveillance programs worldwide. In particular, it came to light that server private key compromise is a commonly used approach to breaking secure communication. For this reason, we now recommend that all secure servers support Forward Secrecy. With this feature enabled, each connection uses separate encryption keys, which means that the encrypted data remains safe if the server private key is compromised.


In addition to addressing these major threat changes, we took the opportunity to include several incremental updates, for example to recommend that you retire 1024-bit keys, SSL 3, and 3DES. We also included a discussion about new technologies, such as ECDSA keys.


Download SSL/TLS Deployment Best Practices v1.3 from the SSL Labs web site.

Posted by Ivan Ristic on Sep 10, 2013 in Security Labs

Is BEAST Still a Threat?

Yesterday I changed the SSL Labs rating criteria to stop penalizing sites that do not implement server-side mitigations for the BEAST attack. That means that we now consider this attack sufficiently mitigated client-side, but, there are still some things you should now.


What is BEAST?

TLS 1.0 and earlier protocols suffer from a serious flaw: the Initialization Vector (IV) blocks that are used to mask data (plaintext) prior to encryption with a block cipher can be predicted by an active man-in-the-middle (MITM) attacker. IVs are used to prevent encryption from being deterministic; without them, every time you encrypt the same block of data with the same key, you get the same (encrypted) output. This is highly undesirable. A clever attacker who can 1) predict IVs, 2) see what encrypted data looks like, and 3) influence what is encrypted, is then able to make guesses about what plaintext looks like. Technically, he cannot decrypt any data, but he can find out if his guesses are right or wrong. With enough guesses, any amount of data can be uncovered.


This is a highly condensed explanation of the problem. If you care about the details, I suggest that you start with my previous post on this topic, and follow the links provided there.


Because guessing is not very efficient, the BEAST attack can in practice used to retrieve only small data fragments. That might not sound very useful, but we do have many highly valuable fragments all over: HTTP session cookies, authentication credentials (many protocols, not just HTTP), URL-based session tokens, and so on. Therefore, BEAST is a serious problem.

Mitigation status

BEAST is purely a client-side vulnerability. Since it had been released to the public, most major browsers addressed it using a technique called 1/n-1 split. This technique stops the attacker from predicting IVs and effectively addresses the underlying problem.


But one platform held back—Apple's. We know little about their intentions, because there hasn't been any official communication on this topic. My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.


Without Apple addressing the BEAST attack, there's a substantial chunk of users that are still potentially vulnerable. For this reason, at the beginning of this year, SSL Labs started penalizing all sites that do not incorporate server-side mitigations against the attack.


Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out.


The situation became uncomfortable because we couldn't solve both problems, but also because both issues were of roughly the same risk. (Low.) Still, the end result was clear: RC4 affects everyone and cannot be mitigated; BEAST affects only a part of the user base and there isn't a workable exploitation path for it any more (we hoped). In addition, we knew that attacks against RC4 were going to get better; and that the attack surface vulnerable to BEAST likely to get smaller.

Is BEAST still a threat?

From this conclusion, the work that remained was to prove that the exploitation path used by BEAST was genuinely closed. We had no reliable information about that, and so I set out to test a bunch of browsers running on various platforms, read source code where available, and attempt to exploit BEAST myself.


The research required a lot of effort and time, mostly because I did not want just to run the existing exploit; I wanted to fully understand the attack as well as explore other potential attack vectors. Juliano and Thai (BEAST authors) have been very helpful answering my questions about their choices. I had detours, some because of real problems, some because of my mistakes. For a long time I thought BEAST was still exploitable because, to my great surprise, I discovered that the Same-Origin Policy (SOP) bypass that was used for BEAST still existed. Apparently, the fix for that problem was botched. Using this bypass, a MITM can still use a Java applet to instrument a victim's browser to encrypt arbitrary plaintext and send it to arbitrary hosts.


Fortunately, there have been many changes to how applets work since BEAST was originally discovered. For example, there are now always warnings before an applet is started. In my testing, the Java plug-in had no ability to access HttpOnly cookies; it couldn't even send them in a request, or receive any of them back. Most importantly, HTTPS request made by applets are encrypted using Java's TLS stack, not that of the host browser. Because Java does implement the 1/n-1 split, BEAST cannot be exploited.


Even though SSL Labs no longer penalizes sites that do not implement server-side BEAST mitigation, the problem remains for as long as we have a major browser without the fix. Although I don't believe that the problem is exploitable today, there might be other attack vectors we are not aware of. A new feature added to Safari could make it exploitable again tomorrow. Or, someone with more time on their hands could prove me wrong. For this reason, we need a healthy security margin, and we need Safari to implement the 1/n-1 split by default.


By the way, supporting TLS 1.1 and 1.2 does not actually address BEAST now or in the near future, even though these protocols do not have the predictable IV weakness that's exploited by the attack. The first problem is that most of the Internet still relies on TLS 1.0. Only about 18% of the servers tracked in SSL Pulse support TLS 1.2 today. Thus, even though the next generation of web browsers will all support TLS 1.2, it's going to take a while until the servers are upgraded.


But there is also the second issue, which is that all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.


When Juliano and Thai disclosed the CRIME attack last year, it was clear that the same attack technique could be applied to any other compressed data, and compressed response bodies (via HTTP compression) in particular. But it was also clear that—with our exploit-driven culture—browser vendors were not going to do anything about.


Progress will be made now that there is an exploit to worry about because, this year at Black Hat, a group of researched presented BREACH, a variant of CRIME that works exactly where it hurts the most, on HTTP response bodies. If you're not already familiar with the attack I suggest that you go to the researchers' web site, where they have a very nice paper and a set of slides.



If you don't want to read the paper right this moment, I will remind you that the CRIME attack works by having the attacker guess some secret text. The trick is to include the guess in the same context as the actual secret (for example, the same response body). When his guess is 100% wrong, the size of the response increases for the size of the guess. But, when the guess is correct (fully, or partially, meaning there is some overlap between the guess and the secret), compression kicks in, and the response body shrinks slightly. With enough guesses and enough time, you can guess anything on the page.


TLS does not defend against this attack because, when the protocol was originally designed, it was impossible for MITM attackers to submit arbitrary plaintext via victims' browsers. Since then, the threat model evolved, but the protocols remained the same. (Interestingly, there is a draft proposal to deal with this sort of thing at the TLS level: Length Hiding Padding for the Transport Layer Security Protocol.)



Clearly, one option is to address the problem at the TLS level; but that will take some time.


Outside TLS, the paper itself includes a nice list of mitigation options, and, with exceptions, I am not going to repeat them here. In general, it's not going to be easy. When dealing with CRIME, we were fortunate because few people knew TLS compression existed, and only a small number of browsers/users actually supported it. This time, the flaw is exploited in a feature that's not only very widely used, but one which many sites cannot exist without. Just try convincing a large site to turn off compression, at a large financial and performance cost.


Although most discussions about BREACH will no doubt focus on its threat against CSRF tokens, we should understand that the impact is potentially wider. Any sensitive data contained in responses is under threat. The good news is that session tokens don't appear to be exposed. However, a well-placed forged CSRF request can do a lot of damage.


CSRF Token Defence

For CSRF tokens there is a simple and effective defence, which is to randomize the token by masking it with a different (random) value on every response. The masking does not hide the token (whoever has the token can easily reverse the masking), but it does defeat the attack technique. Guessing is impossible when the secret is changing all the time. Thus, we can expect that most frameworks will adopt this technique. Those who rely on frameworks will only need to upgrade to take advantage of the defence. Those who don't will have to fix their code.


HTTP Chunked Encoding Mitigation

The award for least-intrusive and entirely painless mitigation proposal goes to Paul Querna who, on the httpd-dev mailing list, proposed to use the HTTP chunked encoding to randomize response length. Chunked encoding is a HTTP feature that is typically used when the size of the response body is not known in advance; only the size of the next chunk is known. Because chunks carry some additional information, they affect the size of the response, but not the content. By forcing more chunks than necessary, for example, you can increase the length of the response. To the attacker, who can see only the size of the response body, but not anything else, the chunks are invisible. (Assuming they're not sent in individual TCP packets or TLS records, of course.)


This mitigation technique is very easy to implement at the web server level, which makes it the least expensive option. There is only a question about its effectiveness. No one has done the maths yet, but most seem to agree that response length randomization slows down the attacker, but does not prevent the attack entirely. But, if the attack can be slowed down significantly, perhaps it will be as good as prevented.

Referer Check Mitigation

A quick, dirty, tricky, and a potentially unreliable mitigation approach you can apply today is to perform Referer header checks on all incoming requests. Because the attacker cannot inject requests from the web site itself (unless he gains access via XSS, in which case he owns the browser and has no need for further attacks), he must do so from some other web site (a malicious web site, or an innocent site hijacked from a MITM location). In that case, the referrer information will show the request originating from that other web site, and we can easily detect that.


Now, you can't just drop such requests (because then no links to your web site would work any more), but you can drop all the cookies before they reach the application. Without the cookies, your application will not resume the victim's session, and won't place anything secret in the response. Attack mitigated.


There is a catch, however (as Hubert pointed out to me this morning): if your web site relies on being framed by arbitrary 3rd party web sites, or if it exposes public services to others (for browser consumption), then you can't use this defence. I am assuming your services need the cookies. If they do not, you're back in the game. If you do decide to try it, please test your major use cases in a staging environment first.


You can implement this defence with only two Apache directives (replace with your own domain name):


SetEnvIfNoCase Referer ^https://www\.example\.com keep_cookies
RequestHeader unset Cookie env=!keep_cookies


The cookies are kept only for requests arriving from the same site. There's a potential problem with users that follow links from other sites and bookmarks and expect to be logged in straight away (either because they are already logged in, or because your site supports auto-log in). For such users you might need to have a welcome page, where you will ask them to click on a link to enter the web site. The cookies will be sent again on the next request.


Just to be clear, there is a long history of attacks focusing on spoofing the Referer header. For example, there was one such problem in Chrome just recently. However, such attacks are addressed quickly after discovery. Further, as Krzysztof Kotowicz pointed out, it is trivial to submit requests that do not contain the Referer header (read about it here and here).


To conclude, I can't really say that I like this approach, but its huge advantage is that you can deploy it very quickly at the web server or reverse proxy level, without having to make any changes to the application code. Even with all the constraints, I imagine there will be a large number of applications for which the trade-offs will be acceptable.


We Should Really Fix the Browsers

I would really like to see this problem addressed where it should be addressed—at the browser level. At the moment, a MITM attacker can intercept your non-encrypted requests, mess with them, and trick your browser into sending requests with arbitrary content to the sites that you care about. It's this interaction that's making several very interesting attacks possible: BEAST, CRIME, RC4, and now BREACH.


A carefully designed opt-in security measure could do the trick, but I suppose it would take a lot of talking and politics to get it implemented. The idea is that a web site can control which other web sites (cross-origins) can initiate requests to it, even if it is via <script> and <img> tags.


Incidentally, just a couple of days ago, Mike Shema and Vaagn Toukharian (fellow Qualys employees), proposed a new cookie control (update: and there is now a follow-up post from Mike) that would restrict when cookies are sent. Their intention was to deal with CSRF, but the measure would work against BREACH, too. If a 3rd party web site initiates a request to your web site, against your wishes, being able to tell the browser to drop the cookies would mitigate the potential attacks.



Update (8 August 2013): The first version of this blog post included a referrer check defence that allowed empty referrers, with the idea to support auto-log in for the users following bookmarks. But then Krzysztof Kotowicz pointed out that the Referer header can be removed by the attackers. I have now modified the example to drop cookies on all requests not originating from the web site.


Update (14 October 2013): A better idea for mitigation based on referrer checking is to selectively disable compression, rather than drop cookies. This approach comes with a slight performance penalty, but no loss of functionality. Read the original discussion thread for more information how to achieve this with Apache.


In my earlier blog post, I gave an overview of Forward Secrecy, as well as some configuration tips. If you're new to the concept, I suggest that you go and read that post first. This time, I am following up with detailed configuration examples for Apache, Nginx, and OpenSSL.


Software Requirements

To deploy Forward Secrecy, you need to have both your web server and the underlying SSL/TLS library support Elliptic Curve cryptography. For Apache, Nginx, and OpenSSL, the following minimum versions will suffice:

  • OpenSSL 1.0.1c+
  • Apache 2.4.x
  • nginx 1.0.6+ and 1.1.0+


You will probably want to upgrade to the most recent versions wherever possible, because you don't want to be running old and obsolete and potentially vulnerable software.


You are probably aware that Linux distributions often ship modified packages. The modifications are usually improvements, but could mean feature removal in some cases. For example, Red Hat appears to have no support for Elliptic Curve crypto on their operating systems, because of patent issues. If you're running CentOS, for example, and wish to support Forward Secrecy, you will need to recompile the key packages to put EC support back in. (There appear to be plenty tutorials on the Web for this.)


Once the correct packages are in place, enabling Forward Secrecy requires two steps:

  1. Configure the web server to actively select suites
  2. Activate the correct OpenSSL suite configuration string


The following configuration advice applies only if you are using compatible software components, as described in the previous section. It is not possible to support Forward Secrecy otherwise.


To configure Apache, you need to have the following lines in your configuration:


SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on


To configure Nginx, you need to have the following lines in your configuration:


ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

RC4 versus BEAST

Today, only TLS 1.2 with GCM suites offer fully robust security. All other suites suffer from one problem or another (e.g, RC4, Lucky 13, BEAST), but most are difficult to exploit in practice. Because GCM suites are not yet widely supported, most communication today is carried out using one of the slightly flawed cipher suites. It is not possible to do better if you're running a public web site.


The one choice you can make today is whether to prioritize RC4 in most cases. If you do, you will be safe against the BEAST attack, but vulnerable to the RC4 attacks. On the other hand, if you remove RC4, you will be vulnerable against BEAST, but the risk is quite small. Given that both issues are relatively small, the choice isn't clear.


However, the trend is clear. Over time, RC4 attacks are going to get better, and the number of users vulnerable to the BEAST attack is going to get smaller.

Configuring OpenSSL (with RC4)

This configuration assumes you wish to deploy best-possible configuration supporting Forward Secrecy, and that you have a preference for GCM suites (resistant to timing attacks) and RC4 (resistant to BEAST). To achieve best performance, the faster ECDHE suites are used whenever possible.






The output will be similar to this:


ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1


If you deploy your configuration, your SSL Labs test results might look like this.



  • The list begins with a number of strong TLS 1.2 suites.
  • ECDSA suites are preferred to the RSA ones, giving you a performance edge in a dual-certificate deployment scenario.
  • The main 2 suites (for the current browsers, most of which do not support TLS 1.2) are ECDHE-RSA-RC4-SHA and ECDHE-ECDSA-RC4-SHA, used for RSA and ECDSA certificates, respectively.
  • The DHE suites are there to support those rare browsers that do not support ECDHE. (Opera before version 15 is one such browser. Firefox as shipped on Red Hat systems another.) These suites are slower, but the majority of browsers will offer the faster ECDHE.
  • The RC4-SHA suite at the end is there to support IE8 running on Windows XP. (And possibly IE6, but I have not tested for it.)



  • Internet Explorer, in all versions, does not support the ECDHE and RC4 combination (which has the benefit of supporting Forward Secrecy and being resistant to BEAST). But IE has long patched the BEAST vulnerability and so we shouldn't worry about it.
  • Same comment as above for Firefox on Red Hat systems.
  • It is impossible to support Forward Secrecy for IE8 running on Windows XP, because this browser does not support the necessary suites. The same is probably true for any IE version running on Windows XP. If you'd rather not handshake with such browsers, add !RC4-SHA to the configuration.

Configuring OpenSSL (without RC4)

If you prefer not to use RC4, deploy with the following configuration:




Alternatively (in order to support a very wide range of browsers, including the IE versions running on Windows XP), you could deploy with RC4 enabled, but used only as a last resort:



Final Remarks

Finally, consider the following:

  • There's a vast number of SSL/TLS clients in deployment, each potentially supporting a unique list of cipher suites. It is impossible to guarantee consistent results across such a large user base.
  • The Handshake Simulation feature of the SSL Labs test is of great help when choosing cipher suite configuration. It supports a wide range of desktop browsers (including older versions). However, do note that the support for mobile devices is not very good at the moment.
  • Configuring OpenSSL can be tricky. I recommend reading the (free) OpenSSL Cookbook, which describes the configuration in detail.  !DSS


Update (21 August): I have tweaked the suite configuration string to position SHA256 and SHA384 suites (which are TLS 1.2-only) after GCM suites and before RC4 suites. This helps avoid RC4 whenever possible. (This matters now because Google Chrome 29 has just been released, and, for the first time, we have a desktop browser that supports TLS 1.2 by default). Of course, I assume that you have upgraded your OpenSSL to 1.0.1d or better in order to fix the timing issues with CBC suites (the so-called Lucky 13 attack).


Update (5 August 2013): In my follow-up post, I discuss how exactly to configure Apache, Nginx, and OpenSSL to support Forward Secrecy.


With revelations about mass surveillance in the news everywhere, an obscure feature of SSL/TLS called Forward Secrecy has suddenly become very interesting. So what is it, and why is it so interesting now?

Session keys generation and exchange

Every SSL connection begins with a handshake, during which the two parties communicate their capabilities to the other side, perform authentication, and agree on their session keys. The session keys are then used to encrypt the rest of the conversation (session), possibly spanning multiple connections. They are deleted afterwards. The goal of the key exchange phase is to enable the two parties to negotiate the keys securely; in other words, to prevent anyone else from learning these keys.


Several key exchange mechanisms exist, but, at the moment, by far the most commonly used one is based on RSA, where the server's private key is used to protect the session keys. This is an efficient key exchange approach, but it has an important side-effect: anyone with access to a copy of the server's private key can uncover the session keys and decrypt the conversation.


For some, this side-effect is desirable. Many network security devices, for example, can be configured to decrypt communication (and inspect traffic) when given servers' private keys. Without this capability, passive IDS/IPS and WAF devices have no visibility into the traffic and thus provide no protection.


In the context of mass surveillance, however, the RSA key exchange is a serious liability. Your adversaries might not have your private key today, but what they can do now is record all your encrypted traffic. Eventually, they might obtain the key in one way or another (e.g., by bribing someone, obtaining a warrant, or by breaking the key after sufficient technology advances) and, at that time, they will be able to go back in time to decrypt everything.

Diffie–Hellman key exchange

An alternative to the RSA-based key exchange is to use the ephemeral Diffie-Hellman algorithm, which is slower, but generates session keys in such a way that only the two parties involved in the communication can obtain them. No one else can, even if they have access to the server's private key.1


After the session is complete, and both parties destroy the session keys, the only way to decrypt the communication is to break the session keys themselves. This protocol feature is known as forward secrecy.2


Now, breaking session keys is clearly much more difficult than obtaining the server's private key (especially if you can get it using a warrant, for example). Furthermore, in order to decrypt all communication, now you can no longer obtain just one key (the server's), but you have to compromise the session keys belonging to every individual conversation.

SSL and Forward Secrecy

SSL supports forward secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE). Why isn't everyone using them, then?


Assuming the interest and the knowledge to deploy forward secrecy are there, two obstacles remain:


  • DHE is significantly slower. For this reason, web site operators tend to disable DHE suites in order to achieve better performance. Furthermore, not all browsers support all the necessary suites. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys.
  • ECDHE too is slower, but not as much as DHE. (Vincent Bernat published a blog post about the impact of ECDHE on performance, but be warned that the situation might have changed since 2011. I am planning to do my own tests soon.) However, ECDHE algorithms are relatively new and not as widely supported. For example, they were added to OpenSSL only fairly recently, in the 1.x releases.


If you're willing to support both ECDHE and DHE, then you will probably be able to support forward secrecy with virtually all clients. But ECDHE alone is supported by all major modern browsers, which means that even with only ECDHE you might be able to cover a large-enough chunk of your user base. The decision what to do is entirely up to you. Google's sites, for example, tend to not have any DHE suites in their configuration.

Configuring Forward Secrecy

Enabling forward secrecy can be done in two steps:


  1. Configure your server to actively select the most desirable suite from the list offered by SSL clients.
  2. Put ECDHE and DHE suites to the top of your list. (The order is important; because ECDHE suites are faster, you want to use them whenever clients supports them.)


Knowing which suites to enable and move to the top can be tricky, because not all browsers (devices) support all forward secrecy suites. At this point you may want to look for inspiration from those who are already supporting forward secrecy, for example Google.


In the nutshell, these are some of the suites you might want to enable3 and push (close) to the top:





To make this process easier, I've added a new feature to the SSL Labs test; this feature, tentatively called handshake simulation, understands the capabilities of major browsers and can determine which suites would be negotiated. It will then tell you if the negotiated suites supports forward secrecy.


Here's a screenshot of this feature in action:




When you get it right, you will be rewarded with a strong forward secrecy indicator in the summary section at the top:


Alternative attack vectors

Although the use of Diffie-Hellman key exchange eliminates the main attack vector, there are other actions powerful adversaries could take. For example, they could convince the server operator to simply record all session keys.


Server-side session management mechanisms could also impact forward secrecy. For performance reasons, session keys might be kept for many hours (or longer) after the conversation had been terminated.


In addition, there is an alternative session management mechanism called session tickets, which uses separate encryption keys that are infrequently rotated (possibly never in extreme cases). Unless you understand your session tickets implementation very well, this feature is best disabled to ensure it does not compromise forward secrecy.

(1) Someone with access to the server's private key can, of course, perform an active man in the middle attack and impersonate the server. However, they can do that only when the communication is taking place. It is not possible to pile up a mountain of encrypted traffic and decrypt it later.


(2) It's also sometimes called perfect forward secrecy, but, because it is possible to decrypt the communication by breaking the session keys, it's clearly not perfect.


(3) I am assuming the most common case, that you have an RSA key (virtually everyone does). There's a number of ECDHE suites that need to enabled if you're using an ECDSA key. I am also ignoring GCM suites for the time being, because they are not very widely supported. I am also ignoring any potential desire to mitigate BEAST by favouring RC4, which might be impossible to do across all client devices.


I have just posted an update to the SSL Labs's SSL/TLS Deployment Best Practices document. The new version is now entirely up-to-date, but the changes are largely incremental:


  • Stronger wording to deploy 2048-bit keys (it's getting difficult or impossible to get certificates for anything less, anyway), and upgrade the remaining 1024-bit keys by the end of 2013.
  • Recommendation to use TLS 1.2 as main protocol.
  • Added CRIME to the list of problems that need to be mitigated in configuration.
  • Added more references for those who wish to research some of the topics.
  • Added Extended Validation certificates and Public Key Pinning to the Advanced Topics section.
  • Several smaller changes and clarifications throughout the document.

RC4 has long been considered problematic, but until very recently there was no known way to exploit the weaknesses. After the BEAST attack was disclosed in 2011, we—grudgingly—started using RC4 in order to avoid the vulnerable CBC suites in TLS 1.0 and earlier. This caused the usage of RC4 to increase, and some say that it now accounts for about 50% of all TLS traffic.


Last week, a group of researchers (Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt) announced significant advancements in the attacks against RC4, unveiling new weaknesses as well as new methods to exploit them. Matthew Green has a great overview on his blog, and here are the slides from the talk where the new issues were announced.


At the moment, the attack is not yet practical because it requires access to millions and possibly billions of copies of the same data encrypted using different keys. A browser would have to make that many connections to a server to give the attacker enough data. A possible exploitation path is to somehow instrument the browser to make a large number of connections, while a man in the middle is observing and recording the traffic.


We are still safe at the moment, but there is a tremendous incentive for researchers to improve the attacks on RC4, which means that we need to act swiftly.


What We (SSL Labs) Will Do


  • Start warning our users about RC4 weaknesses. RC4 is demonstrably broken and unsafe to use in TLS as currently implemented. The difficulty is that, for public web sites that need to support a wide user base, there is practically nothing 100% secure they can use to replace RC4. We now have no choice but to accept that, no matter what settings we use, some segment of the user base will be at risk.
  • If Apple were to implement 1/n-1 record splitting in their stacks (the only major browser vendor that hasn’t done that yet*), we’d likely consider BEAST sufficiently mitigated client-side, and that would allow us to start recommending CBC suites over RC4.
  • Start recommending the use of GCM suites. Browsers will no doubt provide better support for TLS 1.2 and GCM suites at an accelerated schedule, and site operators should be ready to take advantage of that.
  • Update SSL/TLS Deployment Best Practices with new information.
  • At some point in the near future, update the rating algorithm to take the RC4 weaknesses into account.


SSL/TLS Library developers

  • Harden the stack against the Lucky 13 attack.
  • Support TLS 1.2 and GCM suites as soon as possible.


Browser vendors

  • Support TLS 1.2 and GCM suites as soon as possible.
  • Implement 1/n-1 record splitting to make CBC suites safe in TLS 1.0 and earlier. As far as we are aware, Apple is the only remaining vendor that has not patched their browsers, either on OSX or iOS.

System administrators

  • Disable TLS compression. This attack is similar in nature to the recent RC4 attacks, but practical.
  • Support TLS 1.2 and GCM as soon as possible.

TLS Working Group

  • Restore algorithm agility and diversity in TLS. AES GCM suites are now the only truly secure option in TLS, but we shouldn’t count on them to stay like that forever.
  • Consider introducing other stream ciphers to the standard. Algorithm agility, which TLS already provides, is not sufficient if there is only one choice for a component.
  • Consider changing how CBC is implemented in order to address the timing issues.

Application developers

  • Harden session management to support reliable and frequent rotation of session cookies, triggered by elapsed time or the number of requests observed. Recent years have seen a rise in attacks that require attackers to control the client end of a TLS connection in some fashion. Most such attacks focus on extracting small bits of information, typically credentials. Session cookies are now the most popular target. Given how many requests are needed for the best attacks to succeed, rotating session cookies frequently is a good defense in depth measure.


(*) Apple appears to have shipped the 1/n-1 split in Mountain Lion, but it is disabled by default. I was also unable to observe any splitting after the functionality had been manually enabled. iOS devices should support TLS 1.2, which means that they might be secure provided TLS 1.2 is available server-side.

1 2 3 Previous Next

Bookmarked By (1)