Blog: Ivan Ristić / SSL

RC4 in TLS is broken: Now what?

2013-03-09T14:38:47+00:00

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.

Recommendations

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.

SSL Labs update increases security requirements

2013-02-07T12:38:47+00:00

The SSL threat landscape has changed significantly since the rating guide was first published, back in 2009. The original text is thus no longer entirely adequate to deal with the threats of today. In addition, we now have several years of experience using the criteria in real life, and we know what works well and what not so much.

Our plan is to update the rating criteria to take all this new knowledge into account. However, because that process will take several months to complete and because an update to the guide is long overdue, we have decided to release a small patch release, labelling it 2009c. The year in the version number indicates that this is conceptually the same guide as previously published, with improvements.

Essentially, the purpose of this release is to keep the rating criteria relevant for a little while longer, until the next major version is ready. The text of the original document remains as is, but the following changes apply:

SSL 2.0 is not allowed (F).
Insecure renegotiation is not allowed (F).
Vulnerability to the BEAST attack caps the grade to B.
Vulnerability to the CRIME attack caps the grade to B.
The score (0-100) is not shown any more, in order to focus on the grade, which is more useful. Future versions of the guide will probably remove the score altogether.

In addition, we've taken the opportunity to remove the old configuration advice, directing the readers to our SSL/TLS Deployment Best Practices document instead.

Large-scale passive SSL monitoring at ICSI

2012-11-12T14:43:03+00:00

The International Computer Science Institute (ICSI) recently announced a new certificate notary project. Although I find the notary aspect of the project interesting, I think that their work is much more important because of the potential of their approach, which is based on large-scale passive monitoring of SSL connections. In the last couple of years I spent a lot of time looking at the server-side aspect of SSL (most recently, in the SSL Pulse project), but there's a large gap in our understanding when it comes to client-side capabilities, and actual real-life usage. The gap can be explained by ICSI's data.

Sadly, ICSI is unable to share their data because of various privacy concerns. However, they can still mine the data themselves. I decided to put together a list of unanswered SSL usage questions, as a way of contributing to the effort.

Focusing on client capabilities is a good way to start. Some of the most interesting attributes to track might be:

Highest TLS version
Cipher suites (and their order)
TLS extensions
Compression methods
BEAST mitigation
SNI (virtual SSL hosting)
Secure renegotiation (via extension or SCSV)
Session ticket support
Request for OCSP stapling
SPDY support (via the NPN extension)

The most exciting aspect of the project is that it might be able to finally give us the answer to the effective security of SSL. Some key data points include:

Negotiated protocol version
Negotiated cipher suite/strength
Was the suite actively selected by the server
Authentication strength (certificate key size)
DH params/strength (for applicable cipher suites)
Compression usage
Session resumption status (tracked via either mechanism)
Seen stapled OCSP response
Server certificate information
- Key size
- Signature algorithm
- Is it expired?
- Is it self-signed?
Certificate chain correctness
Is the trust root a well-known CA?
Vulnerabilities:
- Renegotiation (do both sides support secure renegotiation)
- BEAST (no browser mitigation and a CBC suite using TLS 1.0 or earlier)
- CRIME (use of TLS compression for the connection)

Improved passive SSL fingerprinting in sslhaf

2012-10-18T11:12:54+01:00

I've had some available time recently to work on sslhaf, my passive SSL fingerprinting tool. I made the following improvements:

Detect browser BEAST mitigation (1/n-1 splitting)
Extract compression support
Extract TLS extensions
Change licence from GPLv2 to BSD
Bug fixes

I think that the detection of BEAST mitigation measures is particularly useful, because it will help understand the risk coming from this attack. Most, but not all, major browsers have mitigations in place. In addition, we don't know how many vulnerable older clients there are. I hope to publish some measurements soon.

The tool is stable but technically still experimental, so use at your own risk. I'd be willing to make it production ready if there's anyone interested in deploying it in a large web site.

CRIME: Information leakage attack against SSL/TLS

2012-09-14T12:01:00+01:00

It seems that it is that time of year again, when Juliano and Thai present their most recent attack against crypto system. Last year, it was BEAST. This year, it's CRIME, a practical attack against how TLS is used in browsers. In a wider sense, the same attack conceptually applies to any encrypted protocol where the attacker controls what is being communicated.

Initially, it was only known that the attack builds on top of an information leakage weakness, and the full results were going to be revealed at the talk at Ekoparty on September 21. Funnily enough, the details that were revealed themselves "leaked" and were sufficient for the experts to understand what is going on: On StackExchange, Thomas Pornin speculated that it was about compression. An academic paper from 2002 (PDF) was revealed. A proof of concept was submitted by xorninja, and improved by Krzysztof Kotowicz. Dan Goodin wrote a great summary of what was known at the time, and included a video of the demonstration. Finally, Threat Post published a confirmation from Juliano and Thai that was indeed compression.

What is the problem?

The root cause of the problem is information leakage that occurs when data is compressed prior to encryption. If someone can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then she will be able to extract the unknown data from it.

In practice, the attack works best against session cookies. If a man-in-the-middle (MITM) attacker 1) can observe network traffic, and 2) manipulate the victim's browser to submit requests to the target site, she can, as a result, steal the site's cookies, and thus hijack the victim's session. In the current form, the exploit uses JavaScript and needs 6 requests to extract one byte of data. The use of JavaScript is desired, but not required: simple <img> tags can do the job just as well, although with a performance penalty.

How bad is it?

Several aspects need to come together for CRIME to be widely exploited. First of all, there has to be server-side support for compression of request data before encryption. TLS supports DEFLATE compression (not to be confused with HTTP response compression, which is very popular, but not vulnerable to CRIME), but not all servers implement it. SSL Labs tests across the SSL Pulse data set indicate that about 42% of the servers support TLS compression. The servers include some of the most popular sites in the world.

Another possibility is that the newer protocol, SPDY, is also vulnerable, because it has a separate mechanism for request header compression. In that case, all servers that support SPDY would be potentially vulnerable. SPDY is a young protocol and not very widely supported, but the sites that do support it are typically larger properties. SSL Labs is currently half way in measuring the support for SPDY across the SSL Pulse data set, but we're currently seeing SPDY support at ~~0.8~~2%.

The second requirement is that client-side also supports compression, and here we will find that the situation is much better. The only browser to properly support TLS compression is Chrome. As for SPDY, both Chrome and Firefox support it. However, it is understood that both Chrome and Firefox have removed support for TLS compression in their most recent updates. (For Firefox, it's even not clear if it was ever enabled.) SSL Labs runs a passive SSL fingerprinting tool called sslhaf. Using it we were able to estimate that only about 7% of browsers support compression at this point. This is on our site, which gets a higher portion of the traffic from Chrome and Firefox users. Analysing the logs, we could see traces of Chrome, and, it seems, some mobile browsers. It is not clear if there were any changes to the SPDY implementation in Chrome and Firefox, but it is reasonable to expect that there will be.

The third requirement for wide exploitation is an easy to use exploitation tool. Unlike BEAST, CRIME seems much easier to exploit; we've already seen a simple proof of concept, and so it's likely that we will see a complete tool soon, maybe as a fork of sslstrip.

Taking all of the above in the account, CRIME will be easy to exploit, but it will be harder to find vulnerable clients. Internet Explorer, Safari, and Opera do not seem to be affected. Chrome and Firefox seem to be, but they use automatic updates, so I expect that the majority of the user base will upgrade to the patched versions. The vulnerable clients will thus be restricted to those using older clients.

Further, unlike BEAST, which requires a manual intervention to mitigate, CRIME will be easier to patch. I expect most vendors will simply disable TLS compression.

What to do?

First of all, if you're using an older Chrome or Firefox, upgrade to the most recent version. If you're operating a web site, use the SSL Labs assessment tool to determine if your site supports TLS compression and SPDY (look for Compression and Next Protocol Support on the results page, towards the bottom). If you think the risk is too high, disable compression if your web software allows you to do it. (If they don't today, they will soon.)

Update (15 Sep 2012) In Details on the "CRIME" attack, iSec Partners give a very good overview of which browsers are vulnerable, and how to disable compression server side.

How good is client-side support for RC4?

2012-07-17T20:40:01+01:00

When it comes to the mitigation of the BEAST attack against SSL/TLS, the usual advice is to prioritize RC4 cipher suites in order to avoid CBC suites, which are vulnerable. In some cases, companies may even have to use RC4 suites exclusively. For example, I've recently heard of a case where a company was failed on its PCI compliance test because they had non-RC4 cipher suites enabled in their configuration.

When RC4 prioritization is discussed, people often seek assurance that RC4 is widely supported. Obviously, if you are going to disable a large number of cipher suites, you start to worry if the remaining suites are going to be sufficient for your user base. Until recently, I had no answer to those questions. Even though all major browsers support RC4 by default, there was no way to quantify the support. Further, some browsers allow users to turn off certain cipher suites, and we just didn't know what the situation on the ground was.

About two months ago I re-enabled mod_sslhaf on the SSL Labs web server. This Apache module, a project of SSL Labs, records all cipher suites offered by clients. Today I looked at the results, curious to find out exactly how many of the SSL Labs clients supported RC4. I choose to compare the total number of unique IP addresses against the number of IP addresses that did not support TLS_RSA_WITH_RC4_128_MD5 (0x04) or TLS_RSA_WITH_RC4_128_SHA (0x05).

In about two months, SSL Labs saw 48,481 unique IP addresses. Only 45 of those -- or 0.09% -- did not support RC4. Looking at the user agent information, the clients not supporting RC4 seem to be largely those whose users decided to explicitly disable RC4 for one reason or another.

The usual disclaimer applies here: the sample is taken from the SSL Labs web site and may not apply to other sites. However, if the assumption that the only non RC4 clients are those where this cipher suite was disabled by their owners, you could argue that an average site will see an even smaller number of non-compatible clients.

My Infosecurity London 2012 SSL Panel Notes

2012-05-23T11:19:20+01:00

Last month, GlobalSign invited me to participate on an SSL Panel at Infosecurity London. Other participants were David Holmes (F5), Ryan Hurst (GlobalSign), and Steve Roylance (GlobalSign, moderator). These are my rough notes. I hope you will find them interesting.

Can you tell us about yourself and why you’re here?

In 2009 I quit my job (because I had become bored), and I decided to work on something I can be passionate about. As it happens, that something was SSL. I had discovered SSL a few years before, while working on my book Apache Security, and always wanted to go back to it, to research it in more detail. To my dismay, I discovered that SSL, arguably the most important security protocol on the planet, is poorly documented, difficult to configure correctly, and that there are no tools to test SSL configurations. That's when SSL Labs was born. Today, SSL Labs offers the best assessment platform and for free. In the past 2 years we've conducted several large-scale surveys of public SSL implementation in an effort to understand exactly where we are, when it comes to the security of the Web.

Talk to us about your perspective on the last two years and the breaches at third-party trust providers?

I think that, in the last 2 years we learned that security is not static. It's not something you work on, and then leave it behind. You know, SSL was designed in 1994, and, today, in 2012, remains essentially the same, conceptually. In the meantime, we saw the Web evolve, and evolve around SSL. The threat model of today is vastly different to the threat model of 1994. Eighteen years! So we dropped the ball. But I think that's actually how things work, for us humans. We don't think about security while it's not a problem. As a result of that, security it becomes a real problem eventually, and then we start to think about it. It's a cycle; a never-ending cycle.

How would you describe the current situation of Public Trust on the Internet?

It's not as bad as it seems. I think that, practically speaking, our biggest problem is not that we have too many CAs, but that we cannot yet build secure systems. The events from the last two years made us realise that any system can be broken into, and -- surprise, surprise -- even the CAs. Once you accept that, the obvious problem with Public Trust is that any one CA can create a certificate for any web site. Site owner's permission is not even required. I am hopeful that that will be fixed with a new standard supporting public key pinning. Then, site owners will be able to say which CAs can issue certificates for their web sites.

Why aren’t Extended Validation certificates saving us now?

You know, back in the day, all certificates used to be "EV". I remember very well jumping through many hoops to get a certificate -- so long ago I don't even remember what year it was. I don't think that many people realise that, prior to EV certs, there wasn't a standard for certificate issuance. Today, there isn't a standard for non-EV certificae issuance [we may get one officially any time now]. So I welcome EV certificates, because they connect your online presence to your off-line identity. That's great, if you need it or if you want it. At the same time, DV certificates are getting cheaper, which is how it should be. The basic security of the communication channel should be available to everyone.

What is your take on the recent advances in cryptographic and protocol focused attacks?

The recent attacks against SSL are a sign of protocol maturity. The reality is that we are not smart enough to foresee all problems when we're designing protocols. So the only way to arrive at something that is secure, is to give it our best shot, start to use it, and fix it as problems are discovered. The recent attacks against SSL demonstrate that people are looking at SSL, and that's a great thing. That means that we're improving. The sky is not falling; but please don't tell everyone. I don't mind the sensational headlines, because they get people's attention. Without the headlines -- without fear -- we wouldn't be able to improve security in the same way. For example, about 75% of all SSL sites are vulnerable to the BEAST attack. I wouldn't mind seeing a sensationalist headline scaring everyone to improve their configuration. The reality is that we need more headlines and more working exploits. How CISO’s should approach trust providers and risk? Choose a CA that you can trust, and a company for which certificate issuance is a significant business (revenue stream). Most of the risk is in-house, in which how you manage your certificates, configure your SSL servers, and implement your applications.

If you were to sit down with an IT manager today and talk to them about his biggest risks relating to SSL what would you tell them?

The biggest SSL-related risk is at the application layer. Your SSL server may be misconfigured today, but you can fix that very quickly. We have people testing themselves using our online assessment tool, getting a bad grade, improving their configuration and even getting a new certificate, just an hour later. And, to be honest, no one is attacking SSL directly. The real risk lies in the application layer, when applications use features that completely subvert SSL. It's like SSL isn't there. We conducted a deep survey of these issues last yar (in the most popular web sites), and the conclusion was that most sites are vulnerable, and SSL effectively useless. I have a lot of hope for declarative security measures. For example, HTTP Strict Transport Security is an emerging standard where you can declare that your application/site uses only SSL (never plain-text HTTP). That means that, even if your application contains implementation errors, you remain secure. I also have a lot of hope for new protocols, which will include SSL as a mandatory component. Eventually, we will migrate to an Internet that is 100% encrypted. I hope.

What do you think is the future of Public Trust?

Realistically speaking, I think we will stay pretty much where we are. Public Key Pinning will remove the most obvious problem. To change anything else -- that's too much work for anyone's taste. I would very much like to see browsers incorporate some elements of crowd-source (Covergence-style) trust for those who understand it. Password-based SSL authentication could be interesting.

What changes are being proposed to augment existing security technologies and how these changes may affect the industry?

We've seen many proposals, but not all of them are equally easy to implement. For example, there's DNSSEC that implements a secure DNS, and DANE, which is a bridge between secure DNS and PKI. Because there is no doubt that we need a secure DNS, I have no doubt that DNSSEC will be widely deployed, eventually (it will take a few years). In the meantime, low-effort proposals, such as HSTS and Public Key Pinning, are likely to become practical. Technically speaking, other proposals can become reality, too, but they require a lot of lobbying and involve a lot of politics.

What do you think about DNSSEC and DANE?

There's one aspect of DANE that I am not sure about, and that's the ability to have valid certificates without CAs. It's not that I like CAs very much, but we forget that the PKI infrastructure was designed to be independent of DNS. And, with DNSSEC, we will revert to only one trust root -- that in the DNS. On the other hand, everyone deserves basic security, and that's something DNSSEC will most certainly achieve. The biggest problem is that with current CA-based ecosystem or with DNSSEC, site owners have no say.

What are the biggest problems of the security industry?

Our biggest problem is in having the security industry in the first place. Security is the business of the developers (used here in a wider sense, to mean those who implement things.) We have the security industry today only because those who are implementing our systems are not building security in. And that's our biggest problem. It's only when the economics of secure development improve that we are going to see substantial improvement in security. Apart from that, our biggest problem is complacency. For example, the CAs, who were (and are) getting serious money from issuing certificates, could have stayed on top of things. The could have tracked the threat model and reacted to new threats. (I don't actually blame CAs for that. I mean, I do, but, ultimately, a wider community should take the responsibility.) Browser vendors could have fixed usability issues (rather than putting the burden of security on the shoulders of end users). And so on... We need our incentives aligned, so that it is in everyone's interest to have better security.

Announcing SSL Pulse

2012-04-30T16:36:44+01:00

Last week we announced SSL Pulse, a continuously updated dashboard that is designed to show the state of the SSL ecosystem at a glance. While it is possible today to deploy SSL and to deploy it well, the process is difficult: the default settings are wrong, the documentation is lacking, and the diagnostic tools are inadequate. For these reasons, we cannot say that the Web is yet secure, but we hope that someday it will be. The purpose of SSL Pulse is to bring visibility to SSL implementation issues on the Web, and while businesses are starting to fix these issues we can keep track of progress made towards making SSL more robust and widely adopted on the Internet.

SSL Pulse is based on the assessment technology and testing conducted by SSL Labs. The underlying data set draws from the information on about 200,000 SSL web sites that represent the most popular web sites in the world. We cherry-picked only the most important data points, focusing especially on those aspects where improvements are needed. We have so far conducted only one round of testing, but, when the next month’s results become available, we will start to show historic values and hopefully see improvements for each data point.

So what do the results tell us? Looking at the SSL Labs grades, which are designed to sum up the quality of SSL configuration, we can see that about 50% (99,903 sites) got an A, which is a good result. Previous global SSL Labs surveys reported about 33% well-configured sites, which means that more popular sites are better configured. Unfortunately, many of these A-grade sites (still) support insecure renegotiation (8,522 sites, or 8.5% of the well-configured ones) or are vulnerable to the BEAST attack (72,357 sites, or 72.4% of the well-configured ones). This leaves us with only 19,024 sites (or 9.59% of all sites) that are genuinely secure at this level of analysis.

The number of sites vulnerable to insecure renegotiation is decreasing at a steady pace, as patches are applied or servers get replaced. The very high number of sites vulnerable to the BEAST attack is worrying, because this problem needs to be addressed in configuration, and that requires awareness, time, and knowledge. Plus, freshly installed systems are equally likely to be vulnerable because of the insecure defaults.

Among other interesting data points, we found only 19 weak private keys in our data. There are also 9 keys that trigger our black list of weak Debian keys. The support for HTTP Strict Transport Security, which is the state of the art configuration for SSL, is at 0.85% (1,697 sites).

As part of this effort, we also published an SSL/TLS Deployment Best Practices guide with clear and concise instructions to help overworked administrators and programmers spend the minimum time possible to deploy a secure site or web application.

Qualys supports reform at CA/Browser Forum

2012-03-30T10:08:16+01:00

Last month, the CA/Browser Forum announced the creation of a working group that will focus on organizational reform. We welcome the announcement with open arms; the public PKI infrastructure needs more structure, collaboration, and visibility, and the CA/Browser Forum is in the best position to advance the robustness of the infrastructure in the short term.

The PKI infrastructure has been evolving organically for too long, and, because of that, we are today faced with many of its structural cracks. The challenge now for the security community (not just the CA/Browser Forum) is to:

understand the complexities of the public PKI infrastructure,
bring all the key stakeholders together,
establish a system of governance that serves the collective interests,
realign stakeholders' incentives to make the ecosystem stronger,
in the short-term, resolve key structural and technical issues,
maintain an up-to-date threat model and address weaknesses proactively, and,
in the long-term, evolve the ecosystem to adequately address the real threats.

There is no doubt that a reform is needed; what is not clear is how it will take place. To facilitate the change, the CA/Browser Forum will need to transform substantially, inviting a wide participation as well as embracing openness and transparency. There is already a large number of organizations and individuals working on improving the security of the PKI infrastructure; those efforts need to be streamlined, and the changes orchestrated.

Some of the pressing issues that need to be addressed include the following:

The large attack surface stemming from a compromise of any one Certificate Authority
Not enough visibility into the operation of Certificate Authorities
Insufficiently defined operational requirements and auditing standards
Lack of reliable control mechanisms and ability to deal with failures
Low adoption rate of SSL/TLS across all web sites
Numerous configuration and implementation issues that subvert security in those sites that did adopt SSL/TLS
Inadequate browser SSL/TLS implementations that do not make security seamless and easy (instead pushing the burden of security onto the shoulders of the end users, who are not in the position to make informed decisions), but still make it difficult for advanced users (who are in the position to make informed decisions) to pursue alternative approaches

SSL and Browsers: The Pillars of Broken Security

2012-03-07T18:31:36+00:00

Last week at the RSA Conference, Wolfgang and I gave a talk called SSL and Browsers: The Pillars of Broken Security. We could have easily called it a State of SSL, because we went through the most relevant SSL issues today, demonstrated the problems using the data from SSL Labs surveys, and discuss how the issues can be overcome. Here's the talk summary:

Recent attacks on browsers and certificate authorities for SSL have shown how fragile these systems are, yet we all depend on them while using the Internet on daily basis. This talk will explore the implementation flaws in the SSL protocol and the browsers that support it. The speakers will showcase extensive research collected from millions of websites that reveal the state of SSL and Browse Security on the Internet. The session will then explore the mitigation options for the problems we are experiencing today, and provide a framework in which we can solve future SSL security issues.

Get this slides here:

SSL and Browsers: The Pillars of Broken Security (PDF, 4 MB)

Announcing the SSL/TLS Deployment Best Practices guide

2012-02-23T11:12:47+00:00

SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works . . . except that it does not, really. The first part is true—SSL is easy to deploy—but it turns out that it is not easy to deploy correctly. To ensure that SSL provides the necessary security, users must put more effort into properly configuring their servers.

In 2009, we began our work on SSL Labs because we wanted to understand how SSL was used and to remedy the lack of easy-to-use SSL tools and documentation. We have achieved some of our goals through our global surveys of SSL usage, as well as the online assessment tool, but the lack of documentation is still evident. This document is a first step toward addressing that problem.

Our aim here is to provide clear and concise instructions to help overworked administrators and programmers spend the minimum time possible to obtain a secure site or web application. In pursue of clarity, we sacrifice completeness, foregoing certain advanced topics. The focus is on advice that is practical and easy to understand. For those interested in advanced topics, we provide references at the end of the guide.

Download the guide:

SSL/TLS Deployment Best Practices (PDF, 500 KB)

TLS Renegotiation and Denial of Service Attacks

2011-10-31T18:48:52+00:00

A group of hackers known as THC (The Hacker's Choice) last week released an interesting DoS tool that works at the SSL/TLS layer. The tool is exploiting the fact that, when a new SSL connection is being negotiated, the server will typically spend significantly more CPU resources than the client. Thus, if you are requesting many new SSL connections per second, you may end up using all of the server's CPU.

The issue abused by the tool is not new, but what is new is that we now have a well publicised working exploit, and that always makes you pay attention. In addition, the tool uses the renegotiation feature, which means that it can force a server to perform many expensive cryptographic operations over a single TCP connection. It's not clear if the relying on renegotiation helps with the DoS attack (there's a very good analysis of the trade-offs on Eric Rescorla's blog), however the fact that external DoS mitigation tools (e.g., rate limiting setups) are only seeing one TCP connection certainly helps with avoiding detection.

But that's only if your server supports client-initiated renegotiation. If it does not, anyone wishing to perform a DoS attack against the SSL layer will have to fall back to using one TCP connection for one SSL connection. IIS, for example, does not support client-initiated renegotiation. Apache used to, but changed its behaviour when implementing RFC 5746 (which fixed the TLS Authentication Gap problem). Even if you depend on a product that does support client-initiated renegotiation, chances are you can easily disable that feature. And, when you do, you are not going to miss it (unlike server-initiated renegotiation, which some sites that require client certificates might need).

To help you with assessing your systems for this weakness, we have updated the SSL Labs assessment tool to test not only if secure renegotiation is supported (which we've been testing for some time now), but also to check if secure client-initiated renegotiation is enabled. Previously we only tested for insecure client-initiated renegotiation.

The sensible thing to do is to check for client-initiated renegotiation support in your servers, and disable it where possible. Although that won't substantially help you overall (defending against DoS attacks is notoriously difficult and expensive), it will harden your defences against this particular technique.

Mitigating the BEAST attack on TLS

2011-10-17T19:36:47+01:00

Update (19 March 2013): This blog post advises to use RC4 to migitate the BEAST attack, but RC4 has recently been discovered to be weaker than previously known. At this point the attacks against RC4 are still not practical. The only fully safe choice at the moment is the AES-GCM suites supported only in TLS 1.2. You can find out more in this new blog post.

During the summer rumours about a new attack against SSL started circulating. Then Opera released a patch, but made no comment about what it was patching. Eventually enough information leaked out that some smart people figured what the attack was about. What remained unknown was the exact technique used in the proof of concept, and that was eventually explained in Thai's blog post. For a comprehensive overview of related links, go to Thierry Zoller's blog post on BEAST.

As it turns out, the attack itself was conceived years ago, deemed impractical, but it was nevertheless fixed in TLS 1.1. The new attack technique introduced a few optimizations to make it practical.

In terms of mitigation, I expect this problem will be largely addressed on the client side, despite a potential compatibility problem that may cause some TLS sites to stop working. The only reliable way to defend against BEAST is to prioritise RC4 cipher suites, as proposed by PhoneFactor.

Just as an example, here's one way to do the above in Apache:

SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!ADH

Not everyone likes RC4, even though there is little to no evidence that it is insecure in the context of SSL/TLS. If your server supports TLS 1.2+ you can try the approach recommended by Steve Caligo:

SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.

Now that I've discussed what works as mitigation, let's look at a few approaches that do not work:

Supporting TLS 1.1+ server-side is a good start, but does not amount to much because very few clients support newer versions of the protocol at this time. And even with TLS 1.1+ support client-side, there's nothing preventing the MITM to force a protocol downgrade back to TLS 1.0. (For a discussion on defense techniques against downgrade attacks, see this thread on the TLS WG mailing list).
Enabling the empty fragment technique server-side (details for OpenSSL here) does not work either. TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent.
Compression is said to make the attack impossible, but, as with TLS 1.1+, the support for it client-side is inconsistent.

Update (20 Jan 2012): In testing OpenSSL 1.0.1-beta2, which came out yesterday, I realised that it will happily negotiate AES-CBC-SHA256 even on a TLSv1.0 connection. So I removed it from the recommendation, replacing it with two other TLSv1.2 cipher suites.

SSL Labs: Announcing launch of two Convergence notaries

2011-09-29T23:50:00+01:00

Convergence is Moxie Marlinspike's attempt to introduce fresh thinking into the debate about PKI, certificate authorities, and trust. A hint of what was in the works was in a blog post published in April (SSL And The Future Of Authenticity); the project was launched at Black Hat US in August. Moxie's talk (here's the video on YouTube) was entertaining and insightful.

Moxie advertises the project as a way of dispensing with certificate authorities ("An agile, distributed, and secure strategy for replacing Certificate Authorities"). At the first glance that's true. You get a browser add-on (only Firefox for the time being) that, once activated, completely replaces the existing CA infrastructure. Whenever you visit an SSL site your browser will talk to two or more remote parties (notaries) and ask them to check the site's certificate for you. If they both see the same certificate you decide to trust the site.

But when you dig deeper into the project, you realise that it consists of two parts. The first, and more important, part is the ability to delegate trust decisions from your browser to another party that's remote to you. That means that you are no longer forced to accept the decisions of the browser vendors, but you can make your own. That ability is, for me, the most thrilling aspect of the project.

The second part of the project is the current backend implementation that makes trust decisions. The approach is great in its simplicity: if you can see the same certificate from several different locations you conclude that it must be the correct certificate. We mustn't rush, however. We've just been given the ability to choose whom to trust, and it's too soon to settle on any one implementation. I am far more interested in experimenting with different approaches, to see what works and what does not.

To that end, it makes me very happy to announce that we (Qualys) have decided to support Convergence by financing and running two notary servers. While it's not yet clear if Convergence can succeed (there are many technological and adoption challenges to conquer), we want to play a part in it and help it succeed.

Finally, here are the links to the notary servers (one of which is in the US and the other in Europe):

Note: To use the above links, you have to have the Convergence plugin installed. After that, all you need to do is click on the links and the notaries will become part of your configuration. Please report any problems to convergence-notary@qualys domain name.

Key SSL/TLS mailing lists to follow

2011-09-26T16:05:35+01:00

The best way to really learn about SSL/TLS and related topics is to follow the discussions on the key technology mailing lists. These lists are always interesting, but especially so in turbulent times, when the value of participation simply goes through the roof.

The key mailing lists are the following:

Transport Layer Security Working Group (core protocols); list archive
Web Security Working Group (HSTS); list archive
SSL Observatory (trust ecosystem); list archive

The list archives are publicly available, so there's not even a need to subscribe.

SSL Survey: How many sites support TLS 1.1 and better?

2011-09-23T10:15:00+01:00

In the last two weeks there's been a lot of chatter about a new attack against SSL and a tool called BEAST. You can find some coverage here, here, and here. The public has not seen any details of the attack yet (they are expected to be released at the ekoparty security conference), but crypto experts have a good idea what it is.

As it appears that the attack wouldn't work against TLS 1.1 and better, suddenly everyone is interested in how many web sites support the newer protocol versions. Virtually none. To illustrate, I am including a slide from my recent Black Hat presentation, where you will see that, even though TLS 1.1 is a 5-year old protocol, there is virtually no support for it.

If you're interested in what exactly is supported in various products, Thierry Zoller has a very good overview. If you want to know more about how SSL is deployed in practice, read our full survey results.

Note: The above slides shows results from an analysis of about 300,000 SSL sites from Alexa's top 1m most popular list. In a separate analysis we also looked at all SSL sites (1.2 million of them), and the numbers are practically identical.

So, what really breaks SSL?

2011-08-09T12:22:54+01:00

After years of being ignored -- which is an unusual situation for the protocol that secures the Web -- SSL became the focus of the interests of the security community at some point in 2008 or thereabout. From then on, a couple of months wouldn't pass between discoveries of one flaw or another. Most problems were with the way SSL is implemented, with one notable exception (the SSL/TLS renegotiation gap) in the protocol itself. As a result of this attention, the effective security of SSL has been continuously improving.

However, for an average web site, the security of the communication channel is rarely compromised by attackers using advanced exploitation techniques. On the contrary, the compromises virtually always come from the flaws in the way SSL is deployed. These problems are created by those implementing and maintaining web sites. And, in most cases, they can relatively easily be fixed.

In the most recent round of our SSL research, SSL Labs focused on programming and deployment errors that compromise SSL security even when SSL is properly configured, with strong cryptographic primitives and up-to-date libraries. None of these issues are new: failure to use SSL (when there is something worth protecting), mixing of encrypted and non-encrypted areas in the same site, mixed page content, insecure session cookies, login forms delivered or submitted over HTTP, and so on.

Although we initially started with the idea to discover how many sites have weaknesses, we discovered that the situation is so bad that we ended up looking for sites that do not have weaknesses. And the number of such sites is very, very small. (You can find the details if you download our presentation slides.) Sites with support for Strict Transport Security are preciously rare.

Why are the weaknesses so prevalent?

On one level, problems come from the way web "standards" have evolved. Slowly, over many years, and without a coherent security strategy. The truth is, it is very easy to break SSL with mistakes that occur on the HTTP level. Thus, our challenge here, short term, is that of education -- making developers aware of these issues.

Businesses are not exactly rushing to secure their sites, either, because there is often little incentive for them to do that. Their money (of which there is never enough), is almost always "better" spent doing other things. As a result, companies today spend on security only when they can't avoid it.

Long term, our only option is to incrementally improve our technology stack to build communication channel security in. Once the option to communicate via plain-text is taken away, there will be no way to subvert SSL. This is a tough goal to achieve, but the journey has already started. A security conscientious site operator can today deploy state of the art SSL configuration (which isn't that difficult, by the way), and achieve pretty good SSL security. Over time, the hope is that we will migrate to better communication protocol that embed SSL in, and that, once communication security becomes invisible, we won't have to worry about it any more.

A study of what really breaks SSL

2011-05-25T15:20:32+01:00

Earlier this year, we at SSL Labs conducted a second, much deeper survey of SSL usage. (I can now say "we" and really mean it, because most of the work on the survey was done by my Qualys coleague, Michael Small.) I presented the results last week at Hack In the Box Amsterdam:

We love security metrics because they tell us what really goes on out there. Last year we conducted an analysis of millions of SSL servers, showing, for the first time, how SSL is really used. This year we are pushing our study further by deepening and expending our efforts in several key areas. We will be looking at the problems that really break SSL — insecure session cookies, mixed content, incorrect site configuration, and distribution of trust to third-party sites. The best crypto in the world is not going to help a site that has flaws in these critical areas.

To discover these flaws we are building a custom site crawler, which we are then going to run against the world’s 1 million most used web sites. In addition to all that, we are expanding the scope of the study to include protocols other than HTTP, as well as basing our assessment on an updated version of the rating guide. The end result? We are finally going to find out how useful SSL really is.

Get the slides here:

A study of what really breaks SSL (PDF)

Fresh Internet SSL Survey results (April 2011) available

2011-04-27T17:41:04+01:00

Last week I attended InfoSec World and presented an update to our global survey of SSL configuration. I present the slides for your enjoyment:

Qualys SSL Labs State of SSL InfoSec World April 2011 (PDF)

An analysis will follow shortly.

Unfortunate current practices for HTTP over TLS

2011-01-19T10:47:23+00:00

This is such a good summary of the current state of SSL in web servers from Adam Langley, that I couldn't resist preserving it here in full. Enjoy.

Network Working Group                                         A. Langley
Internet-Draft                                                Google Inc
Expires: July 5, 2011                                           Jan 2011


            Unfortunate current practices for HTTP over TLS
                      draft-agl-tls-oppractices-00

Abstract

   This document describes some of the unfortunate current practices
   which are needed in order to transport HTTP over TLS on the public
   Internet.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 5, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Handshake message fragmentation  . . . . . . . . . . . . . . .  4
   3.  Protocol Fallback  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  More implementation mistakes . . . . . . . . . . . . . . . . .  6
   5.  Certificate Chains . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Insufficient Security  . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12


1.  Introduction

   HTTP [RFC2616] is one of the most common application level protocols
   transported over TLS [RFC5246].  (This combination is commonly known
   as HTTPS based on the URL scheme used to indicate it.)  HTTPS clients
   have to function with a huge range of TLS implementations, some of
   higher quality than others.  This text aims to document some of the
   behaviours of existing HTTPS clients that are designed to ensure
   maximum interoperability.

   This text should not be taken as a recommendation that future HTTPS
   clients adopt these behaviours.  The security implications of each
   need to be carefully considered by each implementation.  However,
   these behaviours are common and the authors consider it better to
   document the state of practice than to simply wish it were otherwise.


2.  Handshake message fragmentation

   Many servers will fail to process a handshake message that spans more
   than one record.  These servers will close the connection when they
   encounter such a handshake message.  HTTPS clients will commonly
   ensure against that by either packing all handshake messages in a
   flow into a single record, or by creating a single record for each
   handshake message.


3.  Protocol Fallback

   Despite it being nearly twelve years since the publication of TLS 1.0
   [RFC2246], around 3% of HTTPS servers will reject a valid TLS
   "ClientHello".  These rejections can take the form of immediately
   closing the connection or a fatal alert.  Intolerance to the
   following has been observed:

      Advertising version TLS 1.0.

      Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1
      or 1.2, around 3% for greater than 1.2).

      Advertising a version greater than 0x03ff (around 65% of servers)

      The presence of any extensions (around 7% of servers)

      The presence of specific extensions ("server_name" and
      "status_request" intolerance has been observed, although in very
      low numbers).

      The presence of any advertised compression algorithms

   Next, some servers will misbehave after processing the "ClientHello"
   message.  Negotiating the use of "DEFLATE" compression can result in
   fatal "bad_record_mac", "decompression_failure" or
   "decryption_failed" alerts.  Notably, OpenSSL prior to version 0.9.8c
   will intermittently fail to process compressed finished messages due
   to a work around of a previous padding bug.

   Lastly, some servers will negotiate the use of SSLv3 but select a
   TLS-only cipher suite.

   In all these cases, HTTPS clients will often enter a fallback mode.
   The connection is retried using only SSLv3 and without advertising
   any compression algorithms.  (This is obviously an easy downgrade
   attack.)  Also, the fallback can be triggered by transient network
   problems, which often manifest as an abruptly closed connection.
   Since SSLv3 does not provide any means of Server Name Indication
   [RFC3546], the fallback connection can use the wrong certificate
   chain, resulting in a very surprising certificate error.


4.  More implementation mistakes

   Non-fatal errors in version negotiation also occur.  Some 0.2% of
   servers use the version from the record header.  Around 0.6% of
   servers require that the version in the "ClientHello" and record
   header match in order to respect the version in the "ClientHello".  A
   very low number of servers echo whatever version the client
   advertises.

   In the event that the client supports a higher protocol version than
   the server, about 0.4% of servers require that the RSA
   "ClientKeyExchange" message include the server's protocol version.

   Some 30% of servers don't check the version in an RSA
   "ClientKeyExchange" at all.


5.  Certificate Chains

   Certificate chains presented by servers will commonly be missing
   intermediate certificates, have certificates in the wrong order and
   will include unrelated, superfluous certificates.  Servers have been
   observed presenting more than ten certificates in what we assume is a
   drive-by shooting approach to including the correct intermediate
   certificate.

   In order to validate chains which are missing certificates, some
   HTTPS clients will collect intermediate certificates from other
   servers.  Clients will commonly put all the presented certificates
   into a set and try to validate a chain assuming only that the first
   certificate is the leaf.


6.  Insufficient Security

   Some 65% of servers support SSLv2 (beyond just supporting the
   handshake in order to upgrade to SSLv3 or TLS).  HTTPS clients will
   typically not support SSLv2, nor send SSLv2 handshakes by default.
   Of those servers, 80% support the export ciphersuites.  (Although
   about 3% of those servers negotiate weak ciphersuites only to show a
   warning.)

   Some servers will choose very small multiplicative group sizes for
   their ephemeral Diffie-Hellman exchange (for example, 256-bits).
   Some HTTPS clients will reject all multiplicative group sizes smaller
   than 512-bits while others will retry after demoting DHE ciphersuites
   in their "ClientHello".


7.  Acknowledgements

   Yngve Pettersen made significant contributions and many of the
   numbers in this document come from his scanning work.  Other numbers
   were taken from Ivan Ristic's SSL Survey.

   Thanks to Wan Teh Chang for reviewing early drafts.


8.  Normative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

SSL Labs: Added test for ephemeral DH parameters

2010-12-23T17:44:06+00:00

Ephemeral Diffie-Hellman key exchange (EDH or DHE, depending on where you look) allows two parties with no prior knowledge of each other to establish a shared secret. In SSL, DHE is used together with some method of authentication (most commonly RSA) in the handshake phase. Ephemeral DH is valued because it provides perfect forward secrecy -- the session keys cannot be recovered if the authentication method is broken (e.g., someone retrieves the server's private key).

DH parameters are typically generated at runtime. Because of that they are not very visible and are often forgotten during the testing. As of 1.0.69, the SSL Labs online test will examine the DH parameters and warn if they are too weak. The scoring system has been modified to take into account the strength of the DH parameters when they are used for key exchange.

Thanks to Adrian Dimcev and Brian Smith for their help with the research of DH parameter evaluation.

Detection of certificate chain issues in SSL Labs

2010-11-30T19:57:31+00:00

One of the recent additions to the SSL Labs test was the detection of various chain issues. The feature is still marked as experimental, and it will remain so until we conclude that the advice we give there is safe.

Certificate chains are a PKI feature that allows root certificate authorities to delegate the work of certificate signing. Roughly one half of all sites have certificates that are signed by a trusted CA. Such sites need only provide the server's certificate in the handshake. The remaining half (of the sites) uses intermediate certificates (usually only one; it is rare to see a site with more than one such certificate). Such sites need to provide all the intermediate certificates in addition to the server's certificate.

In our tests, we detect the following chain issues:

Missing intermediate certificates; When a site does not provide the necessary intermediate certificates, a trust path cannot be established. Generally speaking, we cannot distinguish that case from a certificate signed by a custom CA. However, some server certificates include the information on which intermediate certificates are required, and also where to obtain them. SSL Labs will attempt to fetch missing certificates. If the intermediate certificates are found, then it's very likely that a trust path will be established. In such cases, the test will issue a warning. If you site receives the warning you should reconfigure the server to add the missing certificates.
Certificate chains that are too long; Sites often include more certificates in the handshake than necessary. Of those, most include one extra certificate, and that is the actual trusted root certificate (which browsers already have in their storage). This last certificate is not needed for the validation process. Having an additional certificate in the chain wastes bandwidth and decreases overal performance slightly. A small number of sites will include a very large number of certificates as a result of misconfiguration. Such sites will typically suffer significant performance issues and need to be reconfigured.
Certificates given in incorrect order; According to the standard, certificates must be presented in the order in which they are needed. The main, server, certificate must come first, followed by the certificate that signed it, followed by the next certificate in the chain, and so on. A small number of sites does not get this order right. Most SSL clients will deal with this problem silently, but there is a small number of platforms that will give up.

Debian stable (Lenny) will support secure renegotiation

2010-11-17T12:14:56+00:00

Thijs Kinkhorst from the Debian Security Team wrote to me in response to my recent blog post Disabling SSL renegotiation is a crutch, not a fix. I am publishing his entire comment (with permission):

It's true that Debian stable still doesn't have an openssl which supports the
new protocol enhancement, but it's definately not a refusal to fix it. First
let me note that the fix is already in the upcoming release of Debian,
codename Squeeze. The current stable release, Lenny, does not have the fix
yet, but it is being worked on; an updated openssl is ready but the blocker
currently is that we may need to implement changes in some of the packages
using it. As usual Debian is very cautious with respect to updating its stable
release. It takes a while, and it would have been nice if the fix was out
sooner, but the combination of impacted software takes quite some time and
time is one of the most sought after resources in a volunteer project.

So just so you know that the issue has not been forgotten or ignored; it only
takes "a while" to get everything in order.

Update: The fix was released on January 6, 2011.

Private assessment option added to the SSL server test

2010-10-07T14:58:40+01:00

Everyone I know likes the SSL assessment tool on the SSL Labs web site, but many dislike the fact that their domain name may end up on one of the boards that display recent test history. I am assuming most wouldn't mind being on the "Recent Best-Rated" one, but you never know before the test how it's going to turn out.

That's why we now support the private assessment option. If you tick the checkbox underneath the domain name field, the test results will not be publicly revealed. Not only that, but the results will remain hidden for as long as the results remain cached.

If you intend to send links to hidden assessment results, make sure the URL contains the "hiddenResults=on" bit, which is needed to ensure that a new public test is run after the earlier results expire from the cache.

Disabling SSL renegotiation is a crutch, not a fix

2010-10-06T12:51:08+01:00

In the days that followed the discovery of SSL/TLS Authentication Gap, some sites (those that did not need renegotiation) were able to deal with the problem by disabling renegotiation in server code. With no support for renegotiation, gone was the danger of exploitation. Good for them.

The sites that did need renegotiation had to wait, first for the TLS working group to solve the issue on the protocol level, and then for their SSL library (or web server) vendors to support the enhancement. The TLS working group did a great job negotiating the fix. As for the vendors, some implemented the new feature quickly, some dragged their feet a little, and some (Debian) seem to refuse to fix the problem, leaving their users vulnerable.

To sum it up, today, almost a year after the initial public discovery, we have some servers that are still vulnerable, some that refuse to support renegotiation, and some that support the new standard for secure renegotiation.

So where is the problem, you might ask? If disabling renegotiation prevents exploitation, that's surely a good thing? Well, it depends on how you look at things. Try to look at the problem through the eyes of a browser developer. I was actually prompted to write about this problem by Yngve Nysæter Pettersen, who's part of Opera's security group. Opera wants to protect its users, and for that to be possible they need to know if a particular server supports secure renegotiation. If a server does, Opera can happily renegotiate whenever necessary. But if a server does not support secure renegotiation, you can make an argument that Opera should refuse any renegotiation attempts.

The servers that support secure renegotiation indicate so during the SSL handshake phase, and everyone's happy and secure. The issue is with the servers that disable renegotiation, because they provide no indication of their security status. Some are insecure, while some aren't. Without knowing, browsers can't do anything. They can perhaps only inconvenience users and force them to manually configure protection levels.

While it is possible to test for insecure renegotiation (SSL Labs does it), the test is indicative but not conclusive -- there is no way to test for server-initiated renegotiation. Besides, it's not reasonable to expect browsers to test every SSL site they encounter.

My point is those that disabled SSL renegotiation must nevertheless implement the proper fix as soon as it becomes available for their platform. Patching is slow enough as it is, and we don't need any further distractions to slow us down.

Qualys SSL Labs releases raw data from the Internet SSL survey

2010-10-05T12:29:04+01:00

About two months ago, Qualys SSL Labs published the results of an Internet-wide SSL survey. We said that we would make the raw data available, and today we are following up on that promise. (By the way, we realize that two months is a long time, but we couldn't complete the process faster on this occasion. We hope to make future releases pretty much as soon as we obtain the data. As you may remember, our plan it to make our survey a quarterly event from 2011.)

The raw data contains the SSL assessment results of about 850,000 domain names (out of about 120M we inspected). The main file (1.2 GB 120 MB compressed, 3.5 GB 800 MB uncompressed) is a dump of our PostgreSQL database in CSV format. We include in the download a simple PHP script that iterates through all the rows, which means that you can consume the data directly. Alternatively, you can put the data back into the database and use SQL to run ad-hoc queries (we provide the schema along with the import instructions).

The database schema contains 63 fields that generally parallel the information you would obtain from the SSL Labs online test. The complete original certificate chain is included, which is handy if you want to look into the aspects we didn't. We chose not to release certain sensitive data: the information on the low entropy private keys, renegotiation support, and HTTP server signatures was removed.

This is what you need to do to obtain the data:

First, make sure that our terms and conditions are acceptable to you. At the core, we use the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported licence, but there are a few additional requirements. For example, we ask the obvious -- that you don't use the data for illegal activities. The other requirements are just common sense. (Please do read the entire file, however.)
Second, send us an email (username "ivanr"; domain name "webkreator.com"), introduce yourself, and tell us how you intend to use the data. We will then send you back the download instructions. We need this second step to give us an idea if the data is used, and how.

Update: We are removing the certificate chain data from the database until we confirm that we are legally allowed to redistribute it. If you need such data in the meantime, retrieve it directly from the servers.

Internet SSL Survey 2010 is here!

2010-07-29T16:23:00+01:00

Since joining Qualys in May, I spent virtually all my time perfecting the SSL Labs assessment engine and looking at how SSL is used on the Internet (HTTP servers only this time). I wrote about this work on a couple of occasions already:

Now, after a couple of months of hard work, the slides are finally ready. Here they are, without further ado:

Qualys Internet SSL Survey 2010 v1.6 (PDF, 3.2 MB)

I will present the results at Black Hat later today (10am PDT). Looking forward to seeing you there.

SSL Labs 1.0.63: Detection and reporting of certificate chain issues

2010-07-13T10:34:53+01:00

The latest revision of the SSL Labs assessment engine (v1.0.63) adds several improvements in the area of certificate chains:

The engine will now try to download missing intermediate certificates. Although sites are supposed to configure complete certificate chains, many forget to do that, and their sites fail to work properly as a result.
Chain size and length are reported in the user interface, which makes it easy to spot ridiculously long chains.
Incomplete chain certificates are reported. This is the case where the engine was able to locate missing intermediate certificates elsewhere and establish trust.
Certificate chains that are too long are reported. It turns out that quite a few sites have chains that are longer than necessary. Such setups not only waste bandwidth, they make the overall site performance worse too.
Incorrectly ordered chains are reported too. Although most browsers will deal with this problem, some SSL clients are sensitive to the issue.

SSL Server Survey: So what's with the 22M invalid certificates claim?

2010-07-02T12:28:23+01:00

After I talked about my research in a Black Hat Preview webcast last week, a number of people rushed to tell me that there can't be 22M invalid certificates in the world. Some got in touch directly, some just talked about it, and, in one instance, a company managed to issue a press release (!) to urge me to clarify my statements.

"Surely I was mistaken", they said, because "there's only about 2M certificates sold by commercial certificate authorities? Something does not add up." Of course it doesn't.

The short answer is that they've generally focused on the wrong aspect of the study and that, in fact, I made no such sensational claims. So what is the real story?

The goal of the SSL Survey is to understand how SSL is used in real life. We generally know what is the right way to configure and deploy SSL, but are the best practices followed, and by how many sites? This sort of analysis is difficult to pull off because you have to know what to test. (The testing itself is not so difficult for us, because we already have a robust assessment engine running on SSL Labs.)

Here are the possible approaches to discover publicly-available SSL servers:

Scan all IPv4 address space. This is only possible because of the still-prevalent deficiency of most SSL deployments that they require a dedicated IP address to operate.
Crawl the Internet to discover the SSL servers that appear in all the hyperlinks in the world.
Analyse the domain name space. One option is to obtain the lists of all domain names registered under a specific TLD, which is slow and cumbersome, but possible. Another option is to use a list such as Alexa's top 1M most popular sites, which is a much more palatable approach.
Use a browser toolbar (or a similar service) to collect the hostnames the users are visiting. This is the only approach that will reveal internal SSL servers, although I doubt that would be very useful.

For my study I opted to analyse the domain name space. The other approaches were either not feasible, would take years, or simply cost too much. We'd love to collaborate with the organisations that have the data that we need, but that hasn't happened yet.

From VeriSign's reports we know that there's about 193M registered domain names in the world, and I managed to obtain a list of about 119M to start with (all .com, .org, .net, .biz, .us, and .info domain names). The idea was to first perform a series of lightweight tests (there are so many domain names!) to give us an idea which domain names are worth looking at in depth. Here are the results:

92M domains are active on port 80 or port 443
33M domains have port 443 open
22.65M domain names run SSL on port 443
On 0.72M domain names certificates match the domain name

Now it becomes clear where the 22M invalid certificates number comes from. If you take the number of domain names that responded on port 443 and subtract the number of certificates that matched the domain name on which they reside (0.72M), you get about 21.93M domain names that do not have valid certificates on port 443. This number is not very important and certainly not ground-breaking. It's a by-product of the methodology whose end-goal is to find something else.

The important number is the 720,000 certificates whose names do match the domain names on which they reside. For each of those, someone made an effort to match the names, and those are the servers that are worth investigating further.

Sadly, some people chose to focus on the numbers that help make an interesting headline, but which aren't very interesting from the research point of view. The reason we have so many domain names that do not have proper SSL certificates installed is that most of them are not _intended_ to have them. Multiple domain names will point to the same IP address and, thus, to the same SSL server. (Remember, virtual SSL hosting is not yet mainstream.) The difference in numbers is because of the widespread use of virtual web hosting, which is available for non-SSL sites, but not yet for SSL sites. You can host a million plain-text web sites on a single IP address, but if you want a million secure sites, you'd need a million IP addresses.

SSL Server Survey: what data are we collecting?

2010-07-02T10:53:36+01:00

As you may have heard by now, Qualys SSL Labs is conducting a large-scale survey of SSL servers. Naturally, the focus of such survey is to collect as much data as possible, then mine it to obtain useful information.

This is the data we are currently looking at collecting:

Certificate information

Common name
Is the common name a wildcard?
Alternative names
Validity period (not before and not after)
Revocation information (CRL and OCSP)
Public key algorithm and size
Signature algorithm
Certificate chain: how many certificates are there in the chain?
Certificate chain: Are the chains complete and well formed?
Certificate chain: How long is the certificate chain?
Certificate chain: keep complete raw data for subsequent deeper analysis
Is there support for Server Gated Cryptography (both Netscape and Microsoft flavours)?
Validation type (DV, IV/OV, EV)
Issuer information
Is certificate trusted (and why not if it isn't)?

Protocol support

SSL v2
SSL v3
TLS v1.0
TLS v1.1
TLS v1.2

Cipher suite support

Test for all known cipher suites (200+ of them)
Cipher suite order preference test

Other

Test support for both Insecure and secure renegotiation
SSL session resumption support
Debian weak RNG weakness
Retrieve HTTP server signature
Presence of the Strict Transport Security response header
TLS version intolerance tests
Grade, according to the SSL Rating Guide 2009

Internet SSL Server Survey at Black Hat USA 2010

2010-07-02T10:34:47+01:00

Ever since starting SSL Labs I wanted to know and understand how SSL was deployed in real life. The only way to find out is to perform an assessment of many (most?) public SSL servers. That's a lot of work, but, as with everything else, if you persist and make continuous progress you eventually get there. This survey has been in the making for about a year and a half now.

The survey consists of three major pieces:

The first piece is assessment methodology, which is covered by the SSL Rating Guide. My goals for the guide were two-fold: provide a comprehensive SSL server analysis, but also make the end result easy to understand. I didn't want only SSL experts to find the guide useful.
The second piece is the assessment tool, which implements the methodology. That's the SSL Labs online assessment tool, which has been running for a year now. The good aspect of doing things slowly is that it makes the end result better. This is especially true in this case, because it's one thing to read the RFCs -- making something work as expected in real life and interoperate with other implementations is much more difficult.
The third and final piece is the scan of as many public SSL servers we can find, which is what we are focusing on right now.

The first results of our study will be published at my talk at Black Hat USA 2010 later this month. The good news is that all our work will be publicly available, and that we intend to continue to run the survey in regular intervals.

SSL Labs assessment engine v1.0.59 improvements

2010-06-17T15:10:49+01:00

The latest version of the SSL Labs assessment software (1.0.59) is now online, and it includes the following improvements:

Cipher suite preference test, which tells you if servers pay attention to which cipher suites they use (or merely use the first suite offered by a client)
Clear cache feature, which clears cache and allows for a quick check-fix-check cycle
Detect Strict-Transport-Security header in response, which indicates STS support
Session resumption test, which checks for the performance optimization after the initial full handshake
TLS version intolerance test, which tests how servers react to not-yet-released versions of TLS
Prefix handling changes; this test will now take into account if the tested domain name (with and without prefix) points to a particular server. It will also relax the check for 2nd-level domain names (e.g., secure.example.com)

Enjoy!

Qualys acquires SSL Labs

2010-06-15T17:05:31+01:00

I am late in writing about this, but SSL Labs is now part of Qualys. If you came to this blog entry through the SSL Labs home page, then you already know the news -- it's obvious from the change to the logo. If not, you can visit the site now to see the logo and the new colours.

Apart from the visual changes, there are no plans to change the concept of the site. The idea -- to research SSL -- remains. I do expect that I will have far more time to spend on my SSL-related research in the following months. In fact, I spent the best part of the last month and a half working on a big related project. It's something I've wanted to do for a long time.

But now is not the time to talk about that. I will share my progress with you in the days that follow.

Secure renegotiation test added to SSL Labs

2010-05-25T15:55:35+01:00

When the SSL and TLS authentication gap problem was initially discovered (in November 2009), there wasn't much anyone could do about the vulnerability. You could disable renegotiation altogether, which only worked if your site did not depend on the feature. Thus my initial test focused on testing whether renegotiation was allowed.

A couple of months ago, in February, the TLS Working Group published RFC 5746, Transport Layer Security (TLS) Renegotiation Indication Extension, to address the authentication gap. The RFC adds a secure renegotiation mechanism to both SSL and TLS. With a couple of parties supporting the RFC now (you can follow the status of the various patches and updates at this page at PhoneFactor), I thought it would be a good time to update my SSL Labs code so that the tests accurately report server configuration.

SSL Labs will now not only correctly discover if secure renegotiation is supported, but it will give a nice green cheer every time it sees it on a site.

Special offer: 25% off ModSecurity Handbook until May 31st. Enter discount code MSHBIRY671XHL1V at checkout.

Breaking SSL: Why leave to others what you can do yourself

2010-05-21T07:55:39+01:00

I will be giving my SSL talk at the ISSD conference later today (ISSD stands for International Secure Systems Development). Here's the presentation:

Breaking SSL: Why leave to others what you can do yourself (PDF, 400 KB)

It's virtually the same talk as my Rendering SSL Useless one from a couple of months ago, with slight reorganisation and some slides nicer.

Deep protocol and cipher suite testing in SSL Labs

2010-05-14T10:22:32+01:00

SSL has a usability problem when the negotiation of a secure communication channel fails: the user is left with a cryptic error message and his head to scratch. Let's say that you are someone whose browser is not particularly equipped in the cryptography department and that you want to connect to a high-security site. Your browser fails to negotiate a SSL session and tells you that "SSL peer was unable to negotiate an acceptable set of security parameters" (Firefox). The problem is that there is no way for the site to communicate the problem to you and explain how you can fix it.

It's a hard problem to solve. SSL could be extended to allow a custom redirection URL to be dispatched to the user who is unable to negotiate good-quality encryption, leading him to a non-SSL page with more information. But such a page could be intercepted and modified (think MITM and sslstrip), allowing an attacker to take control over the user's session. Even the redirection URL itself might be intercepted and modified in transit. The same could happen with a custom text message.

Although the failure to negotiate a secure connection is very rare, there are some sites that find it unacceptable. They will thus accept weak protocols and cipher suites on the SSL level, reporting the problem via HTTP. I think this approach is more secure because in many cases using a weaker protocol is better than no communication security at all.

It is inconvenience for me, though, because there is no standard way in HTTP say that you are, in effect, politely refusing to talk to someone. To detect the situation, I have to look for clues in HTTP responses. Here's what NetScaler responds with:

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

<html><body><b>SSL Alert</b><p>The browser and the web-site cannot communicate securely because there are no common encryption algorithms.</p><p>Please try the following:</p><p>- Check the SSL protocol settings on the browser for SSLv3/TLSv1 protocol support.</p><p>- The secure web-site may be using high-strength encryption algorithms(128 bit).<br>  Check the SSL settings on your browser, if it supports high-strength encryption algorithms.</p><p>- Upgrade your browser to latest version.</p></body></html>

I already did that last year for SSLv2 protocol detection, but a couple of days ago I further improved the assessment engine adding support for deep cipher suite testing. SSL Labs now detects the default NetScaler error response delivered for both weak protocols and weak cipher suites. If you want to see an example, have a look at the Amazon.com results.

Speaking on SSL at OWASP AppSec Research in Sweden

2010-04-27T11:22:30+01:00

I will be speaking at the OWASP AppSec European conference in Stockholm, Sweden. I am really looking forward to attending, too. I had a self-imposed year-free-of-security, and I miss it. My talk will be about SSL -- an improved version of the talk I gave to OWASP London earlier this year.

Firefox extension installation process vulnerable to MITM attack

2010-02-09T16:41:39+00:00

Adrian Dimcev made an important discovery the other day: the Firefox installation process is vulnerable to MITM attack. If a man in the middle is able to intercept the traffic of someone installing an extension, he will be able to get the user to install something else. Firefox is supposed to check the integrity of the extensions before it installs them, but it seems something somewhere broke, and the check is no longer in place.

This problem will be fixed in the next release (it has been fixed in the repository, it seems), but the fact remains that the installation process is seriously misleading. Looking at the user interface alone, the impression is that the entire installation process is carried out ever SSL. Even worse, the main domain name where the extensions are "stored" uses an EV certificate, so you are made to feel super-safe. In truth, the extensions are downloaded over HTTP from who-knows-where.

SSL Labs using Firefox 3.6 CA certs

2010-01-25T16:27:35+00:00

With Firefox 3.6 out, I took the opportunity to upgrade the CA root database. Up until earlier today SSL Labs used the Firefox 3.5.1 list, which has 142 certificate authorities on it. The new version of Firefox supports 155 certificate authorities and, now, SSL Labs does too.

After being prompted by Adrian Dimcev, I also added the support for a couple of obscure EXPORT 1024 cipher suites. Thanks Adrian!

How to render SSL useless

2010-01-14T14:01:35+00:00

Later today I will be presenting at the OWASP London meeting. The title of my presentation is How to Render SSL Useless, and I will be talking about the recent issues with SSL/TLS, my work at SSL Labs, as well as listing Top 11 SSL deployment mistakes that render SSL useless.

Here's the presentation:

ivan_ristic-how_to_render_ssl_useless.pdf

Testing for SSL renegotiation

2009-12-15T13:02:03+00:00

Edit: Please note that the test described here works only with OpenSSL version that was not patched to deal with insecure renegotiation. I recommend that you download version 0.9.8k directly from the OpenSSL web site and compile a special binary to use for testing.

Someone asked me how to test for SSL connection renegotiation, so I thought I would also write here for the benefit of everyone. Testing is easy provided you have access to an un-patched version of OpenSSL. To test, you will use the s_client tool (you'll type the bits in blue):

$ openssl s_client -connect www.ssllabs.com:443
[snip... a lot of openssl output]
---
HEAD / HTTP/1.0
R
RENEGOTIATING
28874:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

The idea is that you connect to an SSL server and start by typing the first line of a request. You then type a single uppercase letter R on a single line, which tells OpenSSL to ask for renegotiation. I am aware of the following outcomes:

Your HTTP request completes, which means that renegotiation is enabled
You get an error (one such possible error is shown in the example above), which means that renegotiation did not work
The connection blocks and timeouts after a while, which is how OpenSSL 0.9.8l deals with renegotiation.

Of course, a SSL Labs report will tell you whether a particular server supports renegotiation.

Clientless SSL VPN products break the Web

2009-11-30T23:24:09+00:00

Dan Goodin, of The Register, pointed me to a very interesting advisory issued today that again confirms that convenience trumps security, every single time. This particular problem concerns the so-called clientless SSL VPN products, which basically work like a reverse proxies on steroids. When you're on the road, you log into one of these devices and they provide you with a "window" through which you can access the sites you'd normally only see on your own network. Now, I've known about these products for a long time but, never having actually used one, I didn't think much about how they work. Now that I know, I am terrified. They basically map all the sites you're accessing into a single super-site, rewriting everything behind the scenes to maintain the illusion of a browser within a browser.

For example, if your internal's site address is internal.example.com and your clientless SSL VPN's address is vpn.example.com, while you're on the road you access your internal site through https://vpn.example.com/internal.example.com/.

It's pretty slick in how it's very convenient and works with any browser, but it kills the same-origin policy. A single rogue web site that you access through this VPN window is able to take over all your sessions, interact with all your sites and monitor whatever is that you're doing.

And the best part? The problem has been known since at least 2006. You can get more information from Dan's article or from the advisory.

Shameless self-promotion: ModSecurity Handbook, the guide to the world's most popular web application firewall, is now available for instant download.

Initial test for SSL renegotiation added to SSL Labs

2009-11-17T19:55:26+00:00

I've added an initial implementation of the test that determines if an SSL server is vulnerable to the Authentication Gap MITM attack. At this point the assumption is that no server supports the safe renegotiation TLS extension, which means that a warning is displayed if renegotiation is found to be supported.

In the following days, as the implementations of the safe renegotiation TLS extension start to arrive, I will improve the test to take that into account.

Not just CSRF: SSL Authentication Gap used for credentials theft

2009-11-14T10:37:54+00:00

Most people associate the recent SSL Authentication Gap vulnerability with mild CSRF, but a couple of days ago Anil Kurmus published an improved attack technique that enabled him to access victims' encrypted data streams. He wrote a proof of concept that could have been used to retrieve someone's Twitter credentials. Twitter's SSL servers no longer support renegotiation so the attack no longer works, but the same principle will still work with other sites. Anil's attack technique was posted to Full Disclosure last Wednesday, but it was ignored. It was subsequently picked up by Dan Goodin from The Register.

In researching the possible attack vectors made possible with the SSL authentication gap problem, most focused on trying to use the credentials included with hijacked requests (i.e., session cookies or Basic Authentication credentials). Anil realised that, although he was not able to decrypt the hijacked requests he was still able to include them as payload in arbitrary requests of his own. So all he needed was a site that has some sort of publishing functionality that can be used to reveal data. With the Twitter attack, he simply published the hijacked data as his Twitter status message.

The attack works because the hijacked information is used in a parameter of the attacker's request. Below is a partial attack example to describe the concept:

POST /statuses/update.xml HTTP/1.0
Authorization: Basic [attacker's credentials]

status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic [victim's credentials]

This attack technique is best suited to exploit APIs protected using Basic Authentication. It will work equally well for session hijacking, but hijacking the credentials in the case of sites that use form-based authentication may be more difficult due to the presence of the ampersand characters in victims' data streams.

Marsh Ray (who discovered the SSL authentication gap issue), hinted that information theft might be possible in a comment to Eric Rescorla's blog post, but he said he was more interested in fixing the problem rather than seeking interesting ways to abuse it.

SSL and TLS Authentication Gap vulnerability discovered

2009-11-05T10:37:45+00:00

A serious vulnerability has been discovered in the way web servers utilise SSL (and TLS, up to the most recent version, 1.2), effectively allowing an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. Both the Apache web server and the IIS have been found to be vulnerable.

The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.

To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.

The following example demonstrates how the flaw can be exploited by an attacker to send an arbitrary request using the authentication credentials of a victim. The red parts are sent by the attacker and the blue parts are sent by the victim.

GET /path/to/resource.jsp HTTP/1.0
Dummy-Header: GET /index.jsp HTTP/1.0
Cookie: sessionCookie=Token

The good news is that, although the attacker can execute an arbitrary request, he will not be able to retrieve the corresponding response. On the negative side, the client will see something different from that what she requested.

You can see that GET attacks are essentially trivial to execute. To date, no one has claimed a successful execution of a POST request using this flaw. Until someone does, that means that an application that only makes changes in response to POST requests will probably not be vulnerable. Further, an application not vulnerable to CSRF attacks will probably be safe too, because the attacker won't be able to generate or predict the token required for the request to go through.

Mitigation options:

If you can, disable renegotiation. There isn't normally a configuration option to do this, but patches are being developed and will be available soon. The majority of web sites do not use renegotiation so disabling it won't be a problem. Those that do will need to make changes to their sites to make them work without it.
Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though.
If you can, monitor all connections that make use of the renegotiation feature. That won't help you if renegotiation is an integral feature of your web site, but it may do if it is rarely used.

Further information:

Marsh Ray's blog post (Marsh discovered the problem a couple of months ago) contains a detailed description of the problems in the attachment.
The post by Martin Rex to the TLS mailing list that prompted public disclosure.

Entropy on a USB stick

2009-10-01T13:18:00+01:00

If you care about security then you care about encryption. If you care about encryption then you know how important it is to have access to a good entropy source. (Or you should know. Not many people talk about entropy. I guess that it's something not very exciting to talk about.) Perhaps there are other similar devices and this is old news to some, but I was pleasantly surprised to learn that entropy is now available for little money, on a humble USB key:

The Entropy Key is a small, unobtrusive and easily installed USB stick that generates high-quality random numbers, or entropy, which can improve the performance, security and reliability of servers.

Get it from Simtec Electronics.

Analysis of Elliptic Curve support in current browsers

2009-09-29T13:42:00+01:00

In my previous post I mentioned Adrian Dimcev, who helped me get Elliptic Curve detection right, in SSL Labs. He has now posted a detailed analysis of the current support of elliptic curve cryptography across browsers:

tls.woodgrovebank.com meets the browsers

I recommend that you read this highly informational post if you have even a slight interest in TLS.

SSL Labs: Improved Elliptic Curve and TLS 1.2 detection

2009-09-22T10:33:15+01:00

The latest version of the SSL assessment software running on SSL Labs features much better detection of the SSL servers that use Elliptic Curve cryptography, TLS 1.1 and TLS 1.2. Windows Server 2008 leads when it comes to these technologies and Microsoft's test server (tls.woodgrovebank.com) demonstrates that very well. Sadly, there's currently no browser that can talk to the Windows Server 2008 in a way that uses all the capabilities that are on offer. Even IE8 has some of the high-end features disabled and gets some others wrong.

I must mention Adrian Dimcev, who pushed me to get this work done. He worked relentlessly to figure out the exact combinations of handshake bits (literally) that produce desired results. I've urged Adrian to describe his findings for everyone to read, and let's hope that he'll do that. In the meantime, his recent blog post provides a bunch of useful information on TLS 1.2.

SSL Threat Model

2009-09-09T12:18:29+01:00

SSL is easy to use but also very easy to use incorrectly. The ecosystem, which is built of the specifications, the implementations, the CAs and the PKI, is full of traps, each of which is very easy to fall into. Once I started to spend significant time thinking about SSL I set out to build a model of the ecosystem, for my own education and to ensure that I understand it all. That's how I arrived to the SSL Threat Model. The image is too big to include here, but just click on the link below to get it:

SSL Threat Model (PNG, 65 KB)

I do understand that many of the elements in the model need explanations, but the diagram is all I have at the moment. As a matter of fact, the diagram has been sitting in my virtual drawer for months in the hope that I would eventually accompany it with some documentation. But seeing that the documentation is not going to happen any time soon, I decided to go ahead and publish the diagram alone.

Feel free to post comments here, though!

Two bugs in mod_sslhaf fixed

2009-09-04T10:50:57+01:00

I fixed two bugs in mod_sslhaf (my passive SSL fingerprinting module for Apache; see my previous blog post for details), which means that you need to upgrade if you're using it:

Pure SSLv2 access was ignored due to a badly interpreted version number (SSLv2 uses a different byte order).
There was a problem with sites that do not use SSL, which would cause Apache to stall.

Everything seems to be in order now.

SSL Labs: a batch of small improvements

2009-09-03T13:17:35+01:00

I love when a project enters the phase where you're mainly concerned with improving upon what already works! I had some time yesterday and today to spend on SSL Labs so I used the opportunity to tweak the software a bit. The changes are as follows:

Successful assessments are now cached for 24 hours.
Unsuccessful assessments are now cached for 15 minutes.
Display complete certificate chains, and make clear which certificates are trusted.
Do more to detect SSLv2 error responses (a polite way for a site to say that it does not support SSLv2).
Use colours and tags ("weak", "insecure", "confusing") to point to the bits in a configuration that are bad or can be improved.

I also fixed a bug or two, but that's not very important.

Is RC4 safe for use in SSL?

2009-08-28T12:07:40+01:00

I received a rather interesting and informative couple of emails last week from Paweł Krawczyk, who wanted to make a point how RC4 is still safe to use in SSL. I thought that his comments would be of interest to a wider audience, so here they are (with permission):

[...] TLS_RSA_WITH_RC4_128_MD5 [...] is extremely widespread among commercial servers. Main reasons are 1) it's default preferred cipher in most versions of IIS, 2) these two algorithms are absolutely fastest and least CPU-intensive.
However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.
This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.
On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.

And...

There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.

Further resources:

RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4
Forgery and Partial Key Recovery attacks on HMAC and NMAC using Hash Collisions (PDF; concludes HMAC-MD5, HMAC-SHA1 - No immediate practical threats)

Black Hat 2009 SSL Review: Breaking the Myths of Extended Validation SSL Certificates (Alexander Sotirov and Mike Zusman)

2009-08-07T12:04:13+01:00

Sotirov's and Zusman's talk (the paper and the slides available for download) is a practical exercise in breaking the assurance provided by EV certificates, building on the discovery Collin Jackson and Adam Barth made in their paper Beware of Finer-Grained Origins:

Extended Validation. The browser’s scripting policy does not distinguish between HTTPS connections that use an Extended Validation (EV) certificates from those that use non-EV certificates. For example, Pay- Pal serves https://www.paypal.com/ using an EV certificate, but a principal who has a non-EV certificate for www.paypal.com can inject script into the PayPal login page without disrupting the browser’s Extended Validation security indicators...

The above has the following implications:

EV sites generally use components that are delivered from other non-EV SSL places. Thus, if you have a valid non-EV certificate in the name of the server used for the component delivery, you can subvert the EV site.
Sotirov and Zusman also point out that browsers don't perform SSL certificate pinning, happily accepting a request from a site with an EV certificate, followed by a request from the same site using another certificate. That allows for what they call SSL Rebinding. Through the same-origin policy, a subverted document delivered with a non-EV certificate can assume control of an EV site.
They further point that it is possible to perform SSL cache poisoning, which is a side-effect of the caching subsystem in browsers being separate from the security system. For browsers, a file from a non-EV site is the same as a file from a EV site:
1. A user is somehow lead into requesting a file supposedly from an EV site (e.g., a script file), but the file is delivered by an attacker performing a MITM attack and using a valid non-EV certificate.
2. The user goes to the real EV site, at which point his browser will attempt to refresh the previously cached script file.
3. If the EV site responds with an 304 (Not Modified) response, the browser will continue to use the subverted version of the script.

Sotirov and Zusman offer a number of suggestions to fix the above problems, but admit that most of them are not likely to happen. The problem here is that it is the browser vendors who should be pushing the security envelope (no one else is in a position to do it), but doing so would break sites and the vendors, who are primarily focused on winning market share, won't risk breakage. The only realistic solution seems to be to make it possible for sites to elect to be more secure so that, in time, we can upgrade to a more secure Internet.

I still maintain that a comprehensive solution (in a way similar to that I proposed in the Secure Browsing Mode document) is the best way forward. Band aids can only do so much and, for once, we need to do a job properly.

Black Hat 2009 SSL Review: More Tricks For Defeating SSL In Practice (Moxie Marlinspike)

2009-08-05T15:53:12+01:00

Moxie Marlinspike has a story to tell, and it's a story about SSL implementation flaws. His talk at Black Hat 2009 (get the slides and the movie from Black Hat Archives) is a continuation of his previous activities, which go way back, as early as 2002 (or something). I liked this talk, because it was delivered in a low key, here-is-what-I-discovered, way.

You first learn about the chained certificate validation flaws from the past, which were possible basically because X.509 is complex and programmers don't understand it. It was possible to exploit such flaws with the use of any valid certificate.
Moxie wrote and published his first SSL tool, sslsniff, because Microsoft claimed the chained certificate validation flaws could not be exploited. This tool automates the exploitation and makes MITM attacks really simple (as most Moxie's SSL tools do).
Next comes sslstrip, again a MITM tool, which relies on the fact that most people first browse using plain-text and let sites guide them to SSL. The tool strips away the links to SSL, leaving the user to communicate via plain-text.
The new stuff is about the same problem Dan Kaminsky pointed out in his talk (but independently discovered), which is that most SSL implementations are vulnerable to NUL-byte attacks. As a result, it is possible to get a CA to sign a certificate that effectively allows you to impersonate a web site you do not own. Combining this attack with a wildcard certificate, you get a certificate that can be used to impersonate any web site.
Moxie further discovered that it was possible to interfere (from a MITM position) with OCSP certificate validation to prolong a life of a revoked certificate.
Even worse, he discovered that it was possible to use a NUL-enriched wildcard certificate to subvert the Firefox and Thunderbird update mechanism.

The good thing about implementation flaws is that they are reasonably quick and easy to fix. The first issue is old news, so it's not a problem any more. The new flaws (#4, #5 and #6) are either fixed (I know they were fixed in Firefox) or will be fixed soon. You can make sure you're using a version of the browser that is not vulnerable. There's going to be a lot of people using older browsers, who are going to remain vulnerable. To help them, it is the CAs who are going to have to make sure they don't issue any more rogue certificates.

Although sslstrip is old news, I am worried about the fact that people can't recognise when a connection (to a web site) is insecure. No, scratch that. Why should people need to recognise that? I know how to and I do, but that's only out of necessity. I am really more worried about the fact that it's necessary to think about such things at all. Web sites should just be secure, period.

Short term, EV certificates help. That really means that they help me and you, but I don't believe they help normal (i.e., non-security) people. Can we do anything to help them? A solution comes to mind, and it consists from two parts:

Use only SSL and make plain-text connections impossible.
Refuse to connect to web sites that do not have valid certificates.

Black Hat 2009 SSL Review: Black Ops of PKI (Dan Kaminsky)

2009-08-04T11:23:51+01:00

SSL was again in the centre of attention at Black Hat USA this year (2009). I say SSL, as do many others, but most of the discussion wasn't about SSL but, rather, about the technologies on which it relies. I will cover the Black Hat SSL talks in a series of blog posts, the first of which I publish today.

Dan Kaminsky's talk (get it here as a QuickTime movie) has several very interesting points, but it fails on delivery. When you take the interesting bits out, the rest is a strange mixture of ranting, sarcasm, irrelevant detours and unproductive technology bashing, which I didn't enjoy. Here's my summary of what Dan said:

Humans are imperfect.
We generally care first about getting things done, with security always an afterthought (if we're lucky).

If you want to be more specific, that translates to:

We don't know how to write secure code.
We are using tools and languages that are inherently insecure (e.g., the C programming language, with its buffer overflows and NUL-terminated strings).
Specifications are often ambiguous.

It's hardly news. My biggest complaint to Dan's talk (his attitude aside) is that he doesn't tell us how to improve things. He mentions DNSSEC as a possible improvement, but how do we guarantee that DNSSEC and its implementations do not suffer from the same problems that plague our software today?

The very interesting new points (what Dan really said), are as follows:

MD2 is insecure, yet we are slow in retiring it. There's even one commonly deployed root certificate signed with it. This one MD2 signature could be abused through an preimage attack. Such an attack is not practical today, but it may become practical soon enough for us to be worried. Dan apparently orchestrated a synchronised removal of MD2 from the popular programs and libraries, which is great.
CAs, programs and libraries all have issues with input validation, the result of which is that it's possible to get a certificate with a NUL byte in the common name. This is the issue that was independently discovered by Moxie Marlinspike, who also spoke at Black Hat. (I will discuss his talk in a subsequent post.) The differences in the interpretation of such common names allow such certificates to be abused so that you get a certificate that works for the domains you do not own. It's even possible to get a wildcard certificate that works for all domain names (in some browsers). This problem is being fixed. (As an aside, Dan doesn't mention the alternative names field, so we don't know if it's vulnerable too. It would be very ironic if everyone would fix the problems in the common name field, yet leave the alternative names vulnerable. Perhaps that's an opportunity for a talk next year.)
It is possible for certificates to have more than one common name (e.g., the domain name, in the context of SSL servers), but its implementation-specific which one will be used.
Ambiguities in ASN.1 (which is used to encode certificates) and flaws in ASN.1 implementations can be used to insert OIDs that some consumers interpret as common names, but others don't.

Improved SSLv2 detection in SSL Labs

2009-08-03T13:12:22+01:00

Update (5 Sep 2012) Someone wrote to me recently to point out that accepting SSL v2 connection requests is insecure, even if the intention is to only display an error message. This is, of course, correct. I come to the same conclusion long time ago, but I had forgotten that I had left behind a written trail in favour of this technique.

One of the benefits of public testing is that you get exposed to, well, real life. I love that phase of development because you generally get to polish your code until it is perfect. Thus, after my SSL server assessment service went online, I monitored its performance closely, expecting to encounter a number of unforeseen cases, or cases that I didn't handle well.

One such area was SSLv2 detection. My first approach was to simply detect the cases where servers accept to negotiate a SSLv2 connection, but I soon discovered two edge cases:

Some servers have SSLv2 enabled, but all of the SSLv2 cipher suites disabled. Technically, although they support SSLv2, it is impossible for the handshake to complete, which has the same end result as protocol disablement.
Some servers accept SSLv2, but they always respond with a special error message to all requests. This is actually a very good idea from the usability point of view. An SSLv2 user connecting to a server that does not support SSLv2 is only likely to get a cryptic error message from their browser, which may leave him wondering what to do. Accepting a connection, only to deliver a user-friendly error message is a very good idea.

Now, dealing with the first case is easy: you just keep a would-be SSLv2 connection open for a bit longer. A failure to negotiate a cipher suite means SSLv2 connections are effectively impossible.

Handling the second case is difficult because there is no standard way to deliver user-friendly protocol errors. For example, this is what Amazon gives you (I suspect the error page is delivered by the load balancer, although it's perfectly possible to implement it on the application level):

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>

Amazon is kind enough to indicate that there is a problem by setting the response code to 500, which is easy to detect. Adding a check for this special case was easy. In a general case, however, I can't just assume that everyone is going to do the right thing. I know they won't. So, for the time being, I am logging all unusual responses to requests over SSLv2 connections. In time I plan to automate the detection by observing if the tested site "looks" substantially different over SSLv2 (not sure what exactly that means, but I will figure it out).

Thanks to Bo and Brandon, who emailed me to discuss the above two issues.

TLS Server Name Indication now in Apache

2009-07-29T09:10:09+01:00

Apache 2.2.12, which was released yesterday (see the changes), now supports TLS Server Name Indication (SNI), which is an extension to TLS that makes virtual SSL hosting possible. At the moment, every SSL web site requires a separate IP address and that makes SSL deployment more difficult than it could and should be.

Don't get your hopes up, though. Although the extension was defined in 2003, the support for it is still very limited. For example, Apache's adoption means that, for the first time, SNI is supported in a major web server. (For the record, you could have used SNI previously with mod_gnutls, but mod_gnutls is not widely used yet.) It is only now that the extension begins to have a fighting chance.

However, the server-side support is not the main problem, although we are yet going to see it IIS. The lack of client-side SNI support holds it back. Although Internet Explorer supports SNI since 7.0, the fact that it does so only on Vista and more recent versions, means that we will have to wait many years for SNI to become practical.

Can you have too much SSL?

2009-07-24T12:33:04+01:00

In response to my announcement of the SSL Rating Guide, Colin Watson left an interesting comment, which I thought would be better answered here.

Perhaps getting away from the issue of SSL configuration, and more onto application design, there's a couple of areas where I feel OVER-use of SSL might be a problem:

Overuse of SSL? Having previously stated (in my Secure Browsing Mode proposal) that I'd like to see the Web become a SSL-only place, I don't think overuse is likely. In fact, given my ongoing struggle to find a hosted blog or wiki service that uses SSL properly, I'd rather see overuse than what we have now — no security at all.

1. sites that ONLY operate under SSL, and are not available without SSL, even though most of the content is public and not in any way sensitive (does this over-use undermine confidence or increase distrust is other non-SSL sites?)

Even with web sites that do not contain sensitive content (no need for confidentiality), you'd still want SSL to provide authentication (are you seeing the correct web site?) and integrity (has anyone modified content in transit?).

2. sites that are generally not SSL, but allow content to be accessed using SSL by unauthenticated users (authenticated users always being forced to use SSL)

Actually, allowing non-SSL access anywhere on a site that requires authentication at some point is very dangerous. When you access a non-SSL site you have no way of telling if you are seeing the genuine site. A MITM attacker could have intercepted your DNS queries to redirect your HTTP requests elsewhere. He could have easily modified the site's content in transit. Either way, he's in charge of what you see. Links to an SSL-enabled portion of the web site could be rewritten to plain-text access. Similarly, such links could lead to an SSL-enabled site under the attacker's control. Granted, some advanced users would detect such an attack, most most users wouldn't.

Can you have too much SSL? I don't think so.

Announcing the SSL Server Rating Guide and the Public SSL Server Database

2009-07-22T16:58:58+01:00

It is my great pleasure to announce two new SSL Labs projects today. Although I launched SSL Labs a month ago using something else as an excuse, the two projects I am announcing today are the real reason SSL Labs exists. After several months of hard work, my two projects are finally ready for the public.

The SSL Server Rating Guide is a no-nonsense SSL server assessment guide. From the introduction:

The Secure Sockets Layer (SSL) protocol is a standard for encrypted network communication. We feel that there is surprisingly little attention paid to how SSL is configured, given its widespread usage. SSL is relatively easy to use, but it does have its traps. This guide aims to establish a straightforward assessment methodology, allowing administrators to assess SSL server configuration confidently without the need to become SSL experts.

The general idea is to give people something concise to work with, something they can pick up and use in a very short period of time. The guide not only makes SSL server assessment very easy, it also gives clear guidelines on what good configuration looks like.
But what good is a rating guide if you don't have tools that will do the hard work for you? Noticing a lack of good SSL assessment tools, I built one and made it into a free online service. The Public SSL Server Database was born.

I hope you will find the projects useful!

Firefox SSL extensions

2009-07-16T16:14:57+01:00

When I saw the email Adam Muntner sent to the webappsec mailing list, in which he advertises his webappsec collection of Firefox extensions, I immediately realised I wanted to do something similar, but for SSL. There are a few interesting SSL extensions for Firefox, but people generally don't know about them.

I ended up creating two collections: one for the extensions that work with the most recent version of Firefox, and another for the older ones:

Firefox SSL Add-on Collections

Examples of the information collected from SSL handshakes

2009-07-09T15:45:57+01:00

I've received an email or two asking me about the information I collected using mod_sslhaf, so I decided to make it available for everyone. Here it is:

sslhaf-20090709-2.txt.gz

The file contains a list of unique user agents seen on SSL Labs, each with information on the handshake they used and the protocols and cipher suites they offered to use. For example:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 \
(KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20
 Handshake: h3
 Protocol: 03.01

 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
 TLS_RSA_WITH_RC4_128_SHA (0x05)
 TLS_RSA_WITH_RC4_128_MD5 (0x04)
 TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)
 TLS_RSA_WITH_DES_CBC_SHA (0x09)
 TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x03)
 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x08)
 TLS_RSA_WITH_NULL_MD5 (0x01)

The information gives insight into how SSL is used in real-life, but it's not reliable enough to support any conclusions about individual clients. There are several problems I need to solve:

Parse User-Agent fields to group related clients.
Record request IP addresses in order to be able to verify the search engine clients are who they say they are.
Record request IP addresses to use them as a mechanism to determine forged User-Agent fields.
Deploy mod_sslhaf to multiple high-traffic sensors, in order to further minimise the possibility of using forged User-Agent fields.

Update (10 July): Now with no unknown cipher suites in the output.

Analysis of Googlebot's frugal cipher suite list

2009-07-02T09:21:10+01:00

Two weeks ago, I announced SSL Labs and my technique for passive SSL cipher suite analysis. It won't surprise you to learn that I've been carefully observing the cipher suites used in the requests that came to the web site since. (In fact, I announced the site slightly earlier than I had planned because I wanted to get my hands on some real-life data.) One client's SSL fingerprint immediately caught my attention, because it supported only 4 cipher suites. It was Googlebot.

There were 115 visits from Googlebot in the two-week period, using 5 different user agent strings (although Googlebot will sometimes send a request without User-Agent set):

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Googlebot-Image/1.0
Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; feed-id=9430846974815548184)

The first one is by far the most common, although the other ones appear on regular basis. I used reverse DNS to verify that the IP addresses belong to Google, with the exception of one Feedfetcher request, for which I had to use ARIN.

As I’ve already mentioned, Googlebot's SSL fingerprint is quite short:

h2,03.01,010080,04,05,0a

The first token indicates the version of the SSL handshake used. In this case it’s h2, which is a code for the SSL v2 handshake. The second token indicates the highest SSL version a client is willing to support. Googlebot’s choice, 03.01, indicates that is willing to go as far as TLS v1.0. Modern browsers do not support SSL v2.0 so it's generally rare to see a browser use a SSL v2 handshake. Search engines don’t care about security but they do care about accessing as many servers as possible: they’ll compromise and support the weaker protocols.

What follows is the most interesting part: the codes for only 4 cipher suites. They are:

SSL_CK_RC4_128_WITH_MD5 (0x010080)
SSL_RSA_WITH_RC4_128_MD5 (0x04)
SSL_RSA_WITH_RC4_128_SHA (0x05)
SSL_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)

The first suite is only valid with SSL v2.0, while the three remaining ones work in SSL v3.0 or TLS v1.0. It's obvious that, unlike with most other SSL clients, the cipher suites on this list were hand-picked. If I would have to guess, I would say that the motivation was to save on bandwidth and increase performance. It’s likely that all SSL v2.0 servers support the one SSL v2.0 cipher suite, while 3 suites are needed to support the rest of the Internet.

Assuming the reason for such a short list of cipher suites is frugality, I am surprised it doesn’t contain suites with weaker ciphers. A search bot doesn’t really care about security so it could afford to negotiate a weaker cipher and perhaps save some CPU cycles. Similarly, 3DES is significantly slower (than, for example, RC4) so it would be my first candidate for removal if I am concerned with performance. Thus, I am guessing 3DES is there for interoperability.

It would be interesting to get someone from Google to comment.

Interestingly, my net caught one search engine imposter, who claimed he was Googlebot, but wasn't. While I could have also used a reverse DNS lookup to determine what the imposter wasn’t, in this case I was also able to identify what it was—someone browsing the Internet using a Firefox 2.x browser with and altered User-Agent field. Nice!

Improved handling of SSL warnings in Firefox 3.5

2009-07-01T17:56:00+01:00

Slightly over a year ago I discussed the SSL certificate error handling in Firefox. Where Firefox 2.x allows users to simply click through a warning about an invalid SSL connection, Firefox 3.0.x improves the handling and makes it difficult to access the invalid web site.

My blog post turned out to be quite popular, sparking a lively discussion, which spilled onto the Mozilla's Bugzilla when I filed two bug reports for Firefox:

The first bug report was rejected after a short discussion (still, I was happy to have been heard), but the second lingered on and, one year later, resulted in the change in how Firefox handles invalid SSL certificates. In Firefox 3.5, when you encounter an invalid SSL web site, you get a screen similar to this one:

Notice the improved language. The message now ways "[...] we can't confirm that your connection is secure", instead of "[a site] uses an invalid security certificate" (followed by technical mumbo-jumbo). Clicking the two headings at the bottom uncovers the hidden areas, which contain more information and the button to create an exception:

HTTP client fingerprinting using SSL handshake analysis

2009-06-17T16:22:47+01:00

My first SSL Labs project is about HTTP client fingerprinting when SSL is used. A cipher suite, in SSL, is a collection of cryptographic techniques that defines a secure communication channel. There are hundreds of cipher suites, and they are all built out of a dozen or so basic building blocks: key exchange, encryption and integrity validation algorithms. Different programs often use different cipher suites. By observing the list of supported cipher suites one can determine the maximal communication strength, and often even guess the make of the SSL client on the other side.

Possible uses:

System administrators can make informed decisions about which cipher suites to enable in the SSL servers they maintain. The general goal is disable as many of the weak(er) cipher suites, while leaving enough to still make it possible for users to connect.
Cross-checking the supported cipher suites with the HTTP client identity offered in the User-Agent header may help uncover some automated attack tools that masquarade themselves as browsers. Although the cipher suites used by an SSL client is completely under its control, such evasive actions require a new layer of SSL expertise. (Whereas it is trivial to spoof the contents of the User-Agent header.)

The proof of concept is an Apache module, which monitors SSL handshakes to extract the supported cipher suites. This approach is quite handy, because you can add the fingerprinting facility to your existing installation and suffer negligible overhead.

Security researchers ask Google to enable SSL encryption by default

2009-06-16T18:15:27+01:00

A group of 38 researchers and privacy advocates sent a letter to Google asking it to enable SSL encryption by default in all its applications. Google has had the always-use-SSL option for a while but, since the feature is disabled by default, only a small number of users is taking advantage of it. Google's response was somewhere along the lines of "we'll give the users security... eventually... if we must".

Although the performance overhead of SSL is negligible for most web sites, the price of security is likely to be significant in Google's case, considering the size of its user base.

SSL Labs launches

2009-06-15T19:52:42+01:00

Recently I've found myself spending more and more time not only thinking about SSL, but also working on several SSL-related projects. SSL is a remarkable technology that is not given nearly as much credit as it deserves. I think this is at least partially because SSL is so commonplace today that people take it for granted. Compared to other security technologies, it is also reasonably easy to configure. But therein lies the danger: SSL is so easy to use that most people have stopped thinking about SSL.

I think there's a large gap between how SSL is used today and how it should be used. Actually, I think we first need to make an effort to understand how SSL is actually used today in order to build on that knowledge. With that, in mind, I decided to start a new web site and use it as a launching point for my SSL-related projects. Fast-forward several months; today, I am happy to announce SSL Labs, which has just launched.

My initial work on HTTP client fingerprinting using SSL handshake analysis is already there (I will write more about it in subsequent posts), but I have several other projects, which I will publish in the following weeks.

The worst idea ever: Let's break SSL for mobile users

2009-01-31T14:59:04+00:00

This is definitely the scariest and stupidest idea I have heard in a very long time: some people on the W3C Mobile Web Best Practices Working Group think that is acceptable to break SSL—the security backbone of the Internet—in order to help transcoding proxies reformat content for mobile users:

The “WAP Gap” All Over Again - W3C, HTTPS and Transcoding

This just demonstrates one of the reasons we suck at security: small groups of people who do not really know what they are doing wield significant power and affect millions. It's like year 2000 all over again. We are lucky when in some cases (such as in this one) there are informed people willing to stand for what's right.

Will the real John Viega please stand up?

2008-12-31T17:44:34+00:00

I thought this was very funny. Yesterday I came across this post from John Viega where he discusses the certificate trust model, ending the post with:

That leaves the Internet fundamentally broken.

Then, today, in a guest post on the Zero Day blog, he states:

People are declaring the entire Internet is broken, and that it will be hard to fix. This is simply not true.

HOWTO: Create a rogue CA certificate for $2000

2008-12-30T16:22:20+00:00

An international group of researchers—speaking at the 25th Chaos Communication Club conference—published details on how they had managed to construct a rogue Certificate Authority (CA) certificate (!) using a weakness in the MD5 hashing algorithm. They estimate the attack costs $20,000 to execute today, but that the cost can be reduced to as little as $2000. With a rogue CA certificate in hand they are able to impersonate any SSL-enabled web site and conduct MITM attacks undetected (no browser warnings!).

The presentation is now available for download.

Update (30 Dec): And so is the paper, along with more information and a demonstration site (the CA certificate was purposefully constructed to expire in 2004, which essentially makes it harmless).

Update (31 Dec): Verisign fixes the problem.

Self-signed certificates in production point to a failure of SSL

2008-07-17T13:04:00+01:00

I am realising that, although the problem that many Firefox users have with self-signed certificates points to a failure in software design (this is not a stab at Firefox, rather a testament to how difficult it is to design software to suit a diverse user base), it really points to a failure of SSL. Why do we have such large numbers of self-signed certificates in the first place? Why isn't everyone using valid certificates?

SSL is a great security protocol and a great success overall. Consider the following:

Hybrid protocol that, when properly implemented, offers security and performance at the same time.
Future-friendly design that allows ciphers and hashing techniques to be replaced as they begin to age
Can be applied to any communication protocol (well, almost any; and the problem will eventually be fixed).
Free.
Rock solid, as the designs are in the public and they have been thoroughly reviewed.

The catch is in the "properly implemented" part. SSL can give you security but only if you can build on top of an existing trust relationship. Most people don't really think about the underlying trust foundation because this is something normally handled by browser vendors when they accept to trust the root certificates of the established certificate authorities. By the time you open a browser you already trust a few dozen entities. They, in turn, extend their trust to cover the web sites you are visiting and everything seems great. Except that there are a few rough edges:

Using valid certificates is an optional step in the configuration of any web server. It requires knowledge, time and effort, and many people can't be bothered. There's also the overhead of required regular maintenance.
The cost model falls apart for very small entities, mostly because of the administrative overhead, but also also because of the additional cost of the certificate itself.

At first I thought the best thing to do would be to relax handling of invalid SSL certificates in browsers. After all—I thought—we don't really trust; most people don't check certificates anyway. We really care about transport security and not having our credit card details snapped while in transit. My idea was to simply ignore the fact that a certificate is self-signed. Perhaps use different colours to show the difference. I felt pretty good about that until I realised that would allow for unrestricted exploitation through man-in-the-middle (MITM) attacks. You see, the problem is that it is impossible to differentiate between a self-signed certificate and a MITM attack. It's not a problem of SSL or even the implementation. Oh, well, back to the drawing board. (Bruce Schneier recently wrote about MITM attacks: his post has a couple of very interesting stories and workarounds.)

The only thing I can think of that would help is raising awareness, and browser vendors seem to be doing that at the moment. Yes, there's a number of angry people, but I trust all the vendors will do the right thing—eventually. We should just be patient and wait for it to happen, while continuing to remind the vendors that security matters.

Firefox versus SSL is really about security versus usability

2008-07-15T11:12:41+01:00

My blog post Firefox 3 improves handling of invalid SSL certificates is proving to be very popular. It touched a nerve, and the comments of unhappy Firefox users keep piling on. Although I suspect a large part of the problem stems from bugs (if you read the comments you will find the reports of clearly unintended behaviour), there is a bigger problem between Firefox and its user base: it is one of security versus usability.

Who knows better: developers, or users?

It's not a problem specific to Firefox, nor a problem that only exists in the security sphere. In fact, once you become aware of the existence of the problem and start looking around, you will find it in virtually every aspect of technology. GNOME, for example, is famous for dumbing down the user interface and forcing its users to behave in a certain way.

It's not surprising that, with two opposing sides, there are two schools of thought. Implementing either approach is easy—and that's what many applications do—but that only results in unhappy users. Finding a way to make products usable, yet secure (or feature-full, outside security) is the real challenge. How do we educate the innocent yet enable the proficient?

Speaking of implementation, the answer may be in making applications capable of adapting to user needs. A system-wide setting could tell applications whether a user prefers to have decisions made for him. Alternatively, an application-specific flag could be set during installation. Having just two settings is probably not feasible, but there should be an easy way for advanced users to ask applications to show them everything.

But it may be that, in order to really solve the problem, we need to make a further step back and examine the way we develop applications. I think the majority of applications are still built by technical people, pushed by business people with features (not security or usability) in mind. Happy users are productive users, but very few companies seem to recognise this fact.

Eliminating session hijacking... forever

2008-06-04T12:42:51+01:00

Jim Manico, over at Manicode, is doing an interesting thing: he is trying to convince the maintainers of every web application stack component everywhere (e.g. browsers, web servers, libraries) to implement the HttpOnly mechanism (read more on HttpOnly in Mitigating Cross-site Scripting With HTTP-only Cookies). Actually, he is doing more than that—in many cases he is fixing things himself and submitting the patches. It's his HttpOnly Crusade.

The general idea behind HttpOnly is to prevent the disclosure of session tokens to JavaScript, which would, in turn, reduce the likelihood of session hijacking attacks. It's a noble idea, but one which is very difficult to succeed. The problem is that we are dealing with a leaky bucket. HttpOnly deals with one of the leaks, but it doesn't do anything about the others. And there are many leaks to take care of. If you go through Jim's blog posts, you will find that AJAX requests will also need tweaking (to hide the cookies marked with HttpOnly), and there is not even mention of session tokens embedded in request URIs, or embedded in request parameters. There is no doubt that an implementation of HttpOnly in all software components would raise the bar and make us more secure, but it won't solve the problem. In this particular case I would prefer to replace the entire bucket.

Our real problem is that session management is not standardised, forcing every application platform (and many applications) to provide its own implementation. Why is this bad?

Implementing session management correctly is not trivial. First versions of many implementations have been found to be incorrect and, thus, insecure.
It's a waste of time. Session management is best abstracted and handled by the underlying platform or library.
Application-level implementations of session management (all implementations today) are inherently vulnerable to session hijacking. We must move session management to a different layer in order to be able to implement it securely (see below).

Why is session hijacking possible in the first place? The HTTP authentication model, as originally envisioned, is not vulnerable to session hijacking because it requires authentication on every request. Session tokens are still needed to identify which requests are part of a session, but since authentication always take place there can be no hijacking. The HTTP authentication model was lacking in many other respects (e.g. there were no provisions to log people out, expire sessions, and so on), so most people simply decided not to use it. In the currently dominant session management model authentication is done only once per session, which turns session tokens into time-limited password surrogates, and thus valuable. Anyone who knows a session token can resume the session it refers to.

There are two ways to solve the session hijacking problem cleanly:

Perform authentication on every request, thus making session tokens worthless (as far as hijacking is concerned). You can do this today in certain circumstances, for example if you are willing to use any of the HTTP authentication methods (Basic or Digest), or if your application uses client SSL certificates (in this case all you need to do is to attach the client's SSL certificate to the session, and check that it is the same on every subsequent request).
Start a new RFC effort to define session management, and then implement it in a layer other than HTTP. We already have the ideal candidate for this function—SSL. SSL actually already understands sessions (they were added to version 3 to increase performance) so only a few tweaks would be needed to make the mechanism suitable for web applications.

Firefox 3 improves handling of invalid SSL certificates

2008-04-29T11:45:51+01:00

I have downloaded the beta of Firefox 3 to check out the improvements related to SSL. First, there's the added support for Extended Validation SSL certificates, but I am not very excited about that (I wrote about this previously in Extended Validation SSL certificates not going anywhere, as predicted). It's a nice feature, but it's not going to bring much good overall. On the other hand, I am very happy with the improvements to the handling of invalid SSL certificates.

Firefox 2.x allows users to simply click-through their way to a site that uses an invalid certificate. There is a warning of some sort, but who reads warnings anyway? (Internet Explorer is not much better in this respect, although at least its warning is very clear about not recommending the user to proceed.)

With Firefox 3.x, the situation is much better. First you get the same style of error response as you would for any other network problem:

The beauty of this page is that it does not allow you to proceed to the site. To go through you have to create an exception, which is a multi-step process that you can start by clicking on that link at the bottom. You then get the following:

Another warning; very good. Clicking the Add Exception... button gives you the form that is used to actually create exceptions. There's a nice final warning on the top of the form, which will hopefully deter those who will be attempting to create an exception for the wrong reasons:

The changes represent a great step forward, and significantly reduce the likelihood of successful man-in-the-middle attacks. Still, I wouldn't mention exceptions at all on the error page: advanced users will find a way to do what they must, but normal users are better-off not knowing anything about exceptions.

Update (7 May 2008): My request to make hide the functionality to create exceptions from the error page was rejected. It's good to know that the issue was considered, even if the decision is not the one I would have made. Daniel Veditz pointed me to Johnath's blog post, which describes the history behind the new SSL error page. Very interesting.

Extended Validation Certificates: A change for the better (but not enough)

2007-06-15T12:38:47+01:00

On June 12th, 2007, the CA/Browser Forum (a group that consists of leading certificate authorities and browser vendors) ratified the first version of the Extended Validation (EV) SSL Guidelines. The goal of the guidelines is to introduce a new type of certificate, Extended Validation Certificate, with intent to standardise the certificate issuance process.

Those of you that remember the early days of SSL certificates will find that the "new" process is pretty much identical to the one we had to undergo years ago. Things such as verifying legal existence, identity, registration number, right to use the domain name--are all there. There is one crucial difference, though. This time the process is mandatory whereas before, it turns out, it was merely a matter of choice. No wonder the quality of the vetting had deteriorated over the years as companies fought for the market by lowering prices.

There are many who do not like the new Extended Validation Certificates. They usually say the new type of certificate will not solve our problems. And that they are merely a way for the certificate authorities to extract more money from their customer base. While I agree with the former, I do not necessarily agree with the latter (but this is not to say the CAs will not be happy to collect the extra funds).

The point is that a solid vetting process should have been a mandatory requirement from the start. The fact that we missed the opportunity to do the right thing then does not mean we have to continue living with the mistake. It is true--the new certificate does fall short of solving our problems. But, guess what, that was never the intention. Citing from the EV Certificate Guidelines (page 13):

(c) Excluded Purposes EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant:

That the Subject named in the EV Certificate is actively engaged in doing business;
That the Subject named in the EV Certificate complies with applicable laws;
That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or
That it is "safe" to do business with the Subject named in the EV Certificate.

SSL certificates have nothing to do with trust. (Admittedly, it's a fact we didn't fully appreciate when they were introduced.) Their purpose is simply to identify the party on the other side of the communication channel. For trust we need to turn to other methods. Actually, we developed perfectly good methods to do this in real life. For example, most people take into account the brand name of the store or that of the manufacturer. You are going to be very comfortable buying from Amazon because you know the company. By the same token, you are probably going to think twice before buying from a badly-designed, badly-built web site you've just run across.

There is one aspect where Extended Validation Certificates fall short, and that's the implementation and the changes in the browser user interfaces. To accommodate the new type of certificate browsers have resorted to displaying the sites protected with such certificates in a slightly different way. There are two problems with this. One is that a normal user stands to gain very little from the change. The other is that, even for the small gain that can be achieved, a huge marketing effort is going to be required to explain the difference. This effort is not only going to be expensive but also take time--a lot of time. It something we can successfully do maybe once or twice in a decade. The EV Certificates are simply not worth it.

A far better solution would have been to, slowly and quietly, reform the certificate issuance process. Let the old certificates expire and start issuing better ones today. While that is happening figure out a way to deal with our real problems and inform the normal Internet users only once we are happy we've done the right thing.