As part of my job working on SSL Labs, I spend a lot of time helping others improve their TLS security, both directly and indirectly–by developing tools and writing documentation. Over time, I started to notice that deploying TLS securely is getting more complicated, rather than less. One possibility is that, with so much attention on TLS and many potential issues to consider, we're losing sight of what's really important.That's why I would like to introduce a TLS Maturity Model, a conceptual deployment model that describes a journey toward robust TLS security. The model has five maturity levels.Hide the remainder of this articleAt level 1, there is chaos. Because you don't have any policies or rules related to TLS, you're leaving your security to chance (e.g., vendor defaults), individuals, and ad-hoc efforts generally. As a result, you don't know what you have or what your security will be. Even if your existing sites have good security, you can't guarantee that your new projects will do equally well. Everyone starts at this level.Level 2, configuration, concerns itself only with the security of the TLS protocol, ignoring higher protocols. This is the level that we spend most time talking about, but it's usually the easiest one to achieve. With modern systems, it's largely a matter of server reconfiguration. Older systems might require an upgrade, or, as a last resort, a more secure proxy installed in front of them.Level 3, application security, is about securing those higher application protocols, avoiding issues that might otherwise compromise the encryption. If we're talking about web sites, this level requires avoiding mixing plaintext and encrypted areas in the same application, or within the same page. In other words, the entire application surface must be encrypted. Also, all application cookies must be secure and checked for integrity as they arrive in order to defend against cookie injection attacks.Level 4, commitment, is about long-term commitment to encryption. For web sites, you achieve this level by activating HTTP Strict Transport Security (HSTS), which is a relatively new standard supported by modern browsers (IE support coming in Windows 10). HSTS enforces a stricter TLS security model and, as a result, defeats SSL stripping attacks and attacks that rely on users clicking-through certificate warnings.Finally, at level 5, robust security, you're carving out your own private sliver of the PKI cloud to insulate yourself from the PKI's biggest weakness, which is the fact that any CA can issue a certificate for any web site without the owner's permission. You do this by deploying public key pinning. In one approach, you restrict which CAs can issue certificates for your web sites. Or, in a more secure case, you effectively approve each certificate individually.The conceptual simplicity of the TLS Maturity Model enables us to easily understand where we are and what we need to do to improve. As a result, we can focus our attention on what really matters. Although level 5 provides best security, it involves most work and addresses risks that don't exist for most sites. Level 4 is arguably the minimum level that can be called secure, and the level that most organisations should be aiming for.

Earlier this week we released SSL Labs 1.17.10, whose main purpose was to increase the penalty when RC4 is used with modern protocols (i.e., TLS 1.1 and TLS 1.2). We had announced this change some time ago, and then put in place on May 20. The same release introduced another change, which was to increase the penalty for servers that don't support TLS 1.2 from B to C. And it seems that this second change is being somewhat controversial, with many asking us to better explain why we did that.Hide the remainder of this articleAlthough what initially prompted us to think about changing the grading for not supporting TLS 1.2 was grade harmonisation (ensuring that a wide range of servers all get grades that make sense -- in other words, to have better-configured servers have better grades), that doesn't change the fact that the reality is that TLS 1.0 is an obsolete security protocol. TLS 1.0 came out in 1999, followed by TLS 1.1 in 2003 and TLS 1.2 in 2008. These new protocol versions were released for a reason -- to address security issues with earlier protocol versions. But, despite being obsolete, TLS 1.0 continues to be the best supported protocol version on many servers. It's not very bad, mind you -- we know from SSL Pulse that about 60% of servers already support TLS 1.2. Client-side, the situation is probably better, because modern browsers have supported TLS 1.2 since 2013. You could say that, overall server configuration is the weaker link.In that light, we feel that the increase of the penalty for the lack of TLS 1.2 is the natural next step in the deprecation of TLS 1.0. In fact, SSL Labs is probably late in doing that. Just last month, the PCI Security Council deprecated SSL v3 and TLS 1.0 for commercial transactions. No new systems are allowed to use TLS 1.0 for credit card processing and existing systems must immediately begin to transition to better protocols. In comparison, the SSL Labs change of grading is only a mild nudge in the right direction. And, while some people are not happy that we're pushing for TLS 1.2, others are complaining that we're not doing enough. For example, the Chrome browser has been warning about lack of TLS 1.2 and authenticated (GCM) suites for some time now. Clearly, it's difficult to make everyone happy.The bottom line is that TLS 1.0 is insecure and we must migrate away from it. In 2011, there came the BEAST attack, and, in 2013, the Lucky 13 attack. TLS 1.0 remains vulnerable to this problems, but TLS 1.2 (with authenticated suites) isn't. These attacks are serious and some organisations continue to use RC4 in combination with TLS 1.0 just to be sure that they are mitigated. We understand that many organisations face significant challenges adding support TLS 1.2, but that is unavoidable. In computer technology, and in security in particular, it is often necessary to keep running just to stay in place.We did get one thing wrong, however -- we didn't communicate our grading changes in advance. It was not our intention to surprise anyone. In fact, we'd prefer much more if changes were smoother. To that end, in the future we'll be announcing all grading changes with at least one month notice, and hopefully more for some more significant changes.

Yesterday we released SSL Labs 1.17.10, whose main goal was to introduce grading adjustments we had talked about a month ago. We delivered the planned changes as well as a few additional tweaks. Our release coincided with an announcement of a new attack against TLS, called Logjam, and we had some time to work on that, too.Hide the remainder of this articleRC4As discussed last month, starting with this version we are increasing our penalty for using RC4 with modern TLS versions, namely TLS 1.1 and better. Sites that do that are now capped at C. Sites that use RC4 only with older clients will be capped at B. Sites that do not use RC4 will get an A, assuming absence of other problems.No TLS 1.2 SupportIt is important for servers to support modern protocols in order to take advantage of the best security features present in modern clients. To emphasise this, sites that don't support TLS 1.2 are now capped at C (was B previously). This most recent TLS version is the only version that supports authenticated suites (AEAD), which are currently the only properly secure type encryption in TLS. It came out in 2008 and there was a long gap before it was implemented by browsers in 2013. Today, seven years later since the RFC, there should be no excuse for not supporting it.LogjamLogjam, the new attack on weak Diffie-Hellman (DH) parameters is yet another reminder that supporting obsolete cryptography is never a good idea. Even though TLS provides a negotiation mechanism that should in theory enable modern clients to communicate using only strong security, in practice there are ways to abuse either the clients or the protocol and perform downgrade attacks.Diffie-Hellman key exchange strength is a relatively obscure aspect of TLS protocol configuration. Until recently, most web servers didn't even have an ability to tune this setting, and some servers don't even today. That wouldn't be a problem, except that most servers default to insecure values. SSL Labs started highlighting servers with weak DH parameters some years ago in an effort to raise awareness of this issue.Logjam affects only incorrectly configured SSL/TLS servers. Those who have followed best practices (e.g., SSL/TLS Deployment Best Practices from SSL Labs) aren't using any of the vulnerable cryptography and need not make any changes to mitigate LogJam. In addition, for performance reasons, well-tuned sites prefer key exchanges based on Elliptic Curve cryptography, avoiding problems with DH altogether. In SSL Labs, servers vulnerable to the LogJam attacks are graded as F; no changes were made specifically for this attack.That said, we did extend our SSL/TLS Client Test to detect when user agents accept Diffie-Hellman key exchange that has only 512 bits of security.Weak DH ParametersEven though for most sites there isn't an immediate vulnerability if they're using 1024-bit DH parameters (state attacks are not part of most sites' threat model), such parameters are weak and should be discouraged. We have been warning about weak DH parameters for a long time; now, with the announcement of Logjam, we feel that it's a good time to move one step further. As of yesterday, sites that continue to use weak DH parameters are capped at B.

Part of the responsibilities of the Qualys Web Application Firewall (WAF) security team is to analyze newly disclosed vulnerabilities. We must ensure their correct detection, and when necessary, publish security updates that will be pushed onto customers' sensors so they can be protected. For most vulnerabilities, these changes are only cosmetic. The inspection engine already knows all the classic web attack strategies (SQLi, XSS, …), and typically our patches are about displaying specific messages to warn the customer that a known vulnerability has been targeted.But occasionally, as in the case of the Magento remote code execution (RCE) vulnerability described by Checkpoint, the vulnerabilities are far more interesting. As I describe in this article, these vulnerabilities are in application-specific protocols on top of the HTTP protocol. That means they are not blockable by standard web application firewalls, and it is necessary to write and deploy custom signatures to block them. Qualys is writing a set of these custom signatures, called "Application Security Templates," to provide accurate inspection for application-specific behaviors and protocols. They extend and enrich the classic HTTP inspection to provide "state of the art" security for the most well-known applications.Hide the remainder of this articleIn Search of the Lost PayloadsTo assert the effectiveness of our security engine against the RCE attack, we must understand how the exploit payloads are sent. Our starting point will be the blog post published by Checkpoint.The unauthenticated remote execution is triggered using three different vulnerabilities named CVE-2015-1397, CVE-2015-1398, CVE-2015-1399. Checkpoint researchers have documented at length the investigation process they have conducted to discover these weaknesses, as well as some dead ends they have reached. But after having carefully read their blog post, we have to face the facts: some critical technical details are missing and some tricks have been hidden from the public. The reason for that is obvious. Magento is a critical application widely used for e-commerce, and nobody wants to give script kiddies an easy way to write an exploit. Browsing the web to find exploit signatures used by black hats lead to the same result: all exploit payloads have been hidden to prevent an easy exploit reconstruction.We are left with no other choice than to download the vulnerable application code and follow the Checkpoint researcher’s steps. Let's analyze the three CVEs from the WAF detection point of view.CVE-2015-1398 : Authentication BypassThe first discovery made by the auditors is the ability to use reflection to trick the application to load admin controllers from classic user context. The controller’s class names are constructed from values derived from the URL.To load “Mage_Downloadable_Adminhtml_Downloadable_FileController.php” an authenticated administrator will request:

Yesterday (27 April), we released a new version of SSL Labs. In this blog post I'd like to quickly go over what was changed: there were a healthy number of improvements, a few fixes, and a large number of additions to the API.Hide the remainder of this articleNew features and assessment improvements:

Nobody wants to use RC4. This well known stream cipher would have been retired long time ago if it weren't for several critical problems in SSL and TLS, problems that affect block ciphers only–for example, BEAST, Lucky 13, and POODLE. So RC4 ended up being the lesser evil.Hide the remainder of this articleTake BEAST, for example. There are mitigations for it (the so-called 1/n-1 split) in all major browsers, but there's also potentially a large number of users who are not updating their browsers (or operating systems). For POODLE, on the other hand, we don't have a workaround. Those who can disable SSLv3 are lucky, because they don't have to worry about this problem. Anecdotally, there are still many companies that can't do that. Small sites usually don't have to worry about these problems, but, for large companies, the worry is about the long tail of vulnerable clients.So it seems that we have two large groups: in one corner are users with modern software. They support TLS 1.2 and modern cipher suites. They are safe. In the other corner we have those with old SSL/TLS stacks, who support TLS 1.0 at best; some of them might be vulnerable to the BEAST attack, and most of them to POODLE as well. At SSL Labs, we want to fully deprecate RC4, but we don't want to penalise those who continue to need this cipher to support old clients. After all, there are no publicly-known feasible attacks against RC4, but there are such attacks for BEAST and POODLE.At the moment, when a server offers RC4, we cap the grade at B, because we deem that the server supports an undesirable encryption algorithm. Although it might be all right to continue to use RC4 in some cases, it's only fair to give a better grade to those servers that do not use it.In the future, we're going to start differentiating between servers that use RC4 with everyone and those that use it only with older clients. If you're using RC4 only with SSL 3 and TLS 1.0, your grade will continue to be capped at B. However, if you're using RC4 with TLS 1.1 or a better protocol, the penalty will be harsher.In order to give time to server operators to act, we will increase the penalty in two steps. The first change will be in May, about one month from now, when we will start penalising servers that use RC4 with modern clients. They will be capped at C (now B). Several months after that (tentatively September), we will increase the penalty to F.To sum up:

It was a routine patch Tuesday and I was developing signatures for Qualys VM to identify vulnerabilities. But when I glanced at CVE-2015-1635 it was clear immediately that there was nothing routine about it. It’s a critical vulnerability which can allow remote attackers to take complete control of IIS web servers without have any prior credentials to the server. Now that is BIG! After releasing the VM signature I started working on this blog post which explains a bit further on how an attack using CVE-2015-1635 works. The blog post also explains the working of Qualys VM QID 91041.Hide the remainder of this articleBackgroundHTTP Range allows HTTP clients to fetch the specified offset within the file on the HTTP server. It’s mainly used for ‘Resume broken downloads’. Let’s say you are downloading a file called ‘welcome.png’ whose file size is 2KB. And after downloaded the first 1 KB your client browser crashed. The next time, your browser or your downloading tool just needs to send the Range request 'Range : 1024-2048' to get the rest of the file. In this article I will refer to the lower boundary (1024 in the example) as 'range-low' and higher boundary (2048) as 'range-high'.Windows Kernel Caching is implemented in HTTP.sys. It provides caching for HTTP requests in Windows kernel to increase performance for IIS. The real technical details were never exposed to the public, but with some poking around we can find that out.Let's say an HTTP client requests the file 'welcome.png' by using

While working on some older vulnerability signatures, I discovered multiple new input validation vulnerabilities in SearchBlox version 8.1.x and earlier which are listed below. As per our responsible disclosure policy I contacted the vendor, SearchBlox, and they fixed the issues.SearchBlox is an enterprise class content search engine server built on top of Apache Lucene/Solr and Elasticsearch. It is used by more than 300 organizations across 30 countries. The solution can be used to search information in websites, e-commerce product catalogs, intranet applications, the cloud, and Salesforce.Hide the remainder of this article1. CVE-2015-0967: Improper Sanitization of User InputA3: Cross-Site Scripting XSSCVSS Score: AV:N/AC:L/Au:N/C:N/I:P/A:N (how to read)SearchBlox contains multiple cross-site scripting (XSS) vulnerabilities, which are caused by improper sanitization of user input.1.1. Reflected XSS in the default search box:

Today we’re releasing the second edition of OpenSSL Cookbook, a free OpenSSL book. This edition is a major update, with some improvements to the existing text and new content added. The new edition has about 95 pages, an increase of about 35 pages.Here’s a brief overview of what’s new: