A number of security researchers recently discovered that Dell laptops come pre-installed with an additional root certificate call eDellRoot. Since the private key is also available on the machine this exposes their customers to the risk of a Man-in-the-Middle (MITM) attack. In a MITM attack, the attacker sits on the network between server and client and uses the eDellRoot certificate to intercept and manipulate HTTPS connections. This vulnerability leaves anyone using these Dell laptops at risk for sensitive data exposure and even infections with malicious payload, all under the cover of a trusted connection.

Dell has released an automatic update to uninstall the certificate; however, we can’t assume that all affected machines will receive this update in a timely fashion. In the meantime, the crucial next step is to know immediately which machines have the eDellRoot certificate, so that they can be fixed. We’d recommend using the power of our Cloud Agent and AssetView query service to instantly determine which machines are at risk and automatically group and tag these assets for remediation.

Find Affected Machines Instantly and Continuously

With a simple query, you can instantly find all machines that have eDellRoot installed. You can also convert this query into a dynamic dashboard, to constantly monitor the scope and impact of this vulnerability. Continuous monitoring is essential, because if any of these Dell computers are ever set back to the factory default, the eDellRoot certificate will once again be restored and the vulnerability reinstated.

Here’s the specific query syntax you can use to find systems with the eDellRoot certificate:

manufacturer.name=dell and vulnerability.vulnerabilities.qid=1018

Qualys Cloud Agent transmits installed Certificate Authorities to the Qualys platform and makes them available for reporting in AssetView. That way, you can continue to monitor the health and validity of all of your SSL certificates.

How boring would social networking websites, blogs, forums and other web applications with a social component be if they didn't allow their users to upload rich media like photos, videos and MP3s?  The answer is easy: very, very boring! Thankfully, these social sites allow end-users to upload rich media and other files, and this makes communication on the world wide web more impactful and interesting.

But user-uploaded files also give hackers a potential entry-point into the same web apps, making their safe handling an extremely important task for administrators and the security team. If these files are not validated properly, a remote attacker could upload a malicious file on the web server and cause a serious breach.

Qualys Web Application Firewall protects against uploads of malicious files by providing automatic validation of uploaded files. Specifically, it inspects the contents of the HTTP request and response associated with the file upload, which allows it to identify specific indicators of whether the contents of the file upload are legitimate or not.

This blog post describes how Qualys WAF does its magic.

About Unrestricted File Upload Vulnerabilities

Malicious files uploads are the result of improper file validation: OWASP calls it Unrestricted File Upload, and Mitre calls it Unrestricted Upload of File with Dangerous Type. According to OWASP, unrestricted file upload vulnerabilities can allow two different types of attacks:

1)  Missing proper validation of file name

This can allow an attacker to overwrite application files using a specially crafted request, for example “../../../index.php”. If not handled correctly, the request in this scenario may overwrite the default application home page, or worse, upload the file to a user-accessible location which is outside the file storage sandbox.

2) Missing proper validation of file content and size

Allowing attackers to upload a file of any size without restriction may allow consuming all storage space on the server, potentially causing a denial of service and even crashing the server in some cases.

The allowed file content type is the most critical issue. This should be taken care of properly, otherwise it may result in arbitrary code execution on the server. Let’s discuss more about this second case. If we look at software affected by unrestricted file upload issues on exploit sharing sites such as exploit-db we can find hundreds of applications affected. Most of these are unauthenticated issues, meaning attackers don’t need to have valid credentials to exploit the issue. This gives us a rough idea of the scope of the issue; it is quite common.

Common But Ineffective Mitigations

An examination of some common but ineffective mitigation techniques gives insight into how hackers can attack your web apps.

File Extension Verification

Blacklisting and whitelisting of file extensions is the most common validation method implemented by developers.

To implement blacklisting, the developer needs to gather all executable extensions disallowed by the server, which is obviously a tricky task, which can be defeated several ways in practice:

• Blacklisting can often be bypassed using uncommon executable extensions such as php3, php4, php5, shtml, phtml, cgi which are understood by server.
• Hackers can also use “.htaccess” file tricks to upload a malicious file with any extension and execute it. For a simple example, imagine uploading to the vulnerabler server an .htaccess file that has AddType application/x-httpd-php .htaccess configuration and also contains PHP shellcode. Because of the malicious .htaccess file, the web server considers the .htaccess file as an executable php file and executes its malicious PHP shellcode. One thing to note: .htaccess configurations are applicable only for the same directory and sub-directories where the .htaccess file is uploaded.
• In certain configurations, multiple file extensions such as shell.php.jpg will trick the server to execute file.
• The infamous null character injection (%00) attack falls under this category.

The whitelisting approach gives developers more control over security as compared to blacklisting, since only allowed file extensions are specified and every other file extension is refused. Still there are some pitfalls in this method. There is a history of server side bugs which allow bypassing such protections, including:

• The IIS 6 semi-colon vulnerability caused by a parser bug which allow user to upload and execute file with names such as test.asp;.jpg, and
• ADS streams on Windows which may allow an attacker to bypass these protections.

Content-type Verification

This kind of verification completely depends upon content-type header, e.g. Content-Type: image/jpeg, containing the MIME type. This is a very weak validation mechanism, as this header is supplied by the user (attacker).

Image Type Content Verification

Many developers believe this is the safest method to prevent malicious file upload issues, it is not foolproof with certain configurations and can still cause issues. For example, using the image processing getimagesize() function which provides information about uploaded file including filetype,size,dimensions which is helpful to detect if an uploaded file is indeed an image.

Security researchers already demonstrated a way to inject executable code in certain sections of images. Some examples of such attack are JPEG image EXIF header injections and encoding of executable code in PNG IDAT chunks. Injecting malicious code inside another file format is not completely new; in the past we have also seen some interesting attack methods like GIF/Javascript Polyglots and the GIFAR attack which bypassed almost all protection mechanisms implemented at the time.

How Qualys Web Application Firewall Protects

As can be seen in the above examples, most file upload attacks are triggered by the fact that the application relies on an established protocol for communication with the client. By playing with this protocol, an hacker can deceive the application and make it think that uploaded files are legitimate when in fact they are malicious.

When the application relies on a content-type verification, the hacker sets an accepted content-type while uploading a PHP script. If the application expects a specific extension, the hacker will be happy to rename his payload file with the desired extension. And if the application tries to validate the file format with classic PHP functions, the hacker will insert the code inside a file that respects the desired format (EXIF header injection described above).

Qualys WAF throws standard protection techniques on their heads by applying deep inspection mechanisms to the bodies of requests instead of performing file validation. Qualys WAF analyzes all parts of the file upload request for signs of trickery or malicious payloads. While parsing a file upload request, it looks for any malicious content indicators such as executable code containing classical dangerous functions (system, exec, kill), functions used for code obfuscation (base64_decode, urlencode, preg_replace) or uncommon tricks used for evading detection. When enough signs are present the WAF will block the request to prevent the application to be damaged.

All signs of attack will be accurately reported to help the user to understand what's happening. When a user tries to upload a malicious file such as a web shell, Qualys WAF blocks that attempt. The detailed information about this malicious user action gets logged and displayed in the user interface. The event details contain information about detection type, method, severity, user request details, origin of request, etc. which provides valuable insight of attack.

Example: Blocked Upload

The screenshot below shows an example of an attempted file upload that was blocked by Qualys WAF.

The Qualys WAF administrator can configure what level of threat is reported and what level is blocked. In this case, the threat level of 80 shown in the red box exceeds the blocking threshold, so the event was blocked.

The Event Details section shows the detection information details. For the event shown here, QID 150114 is triggered which indicates the user tried to upload a malicious file. QID 226016 indicates the detected event threshold (Threat Level 80) is greater than the blocking threshold (31 in this example), and as a result this request is blocked.

The Event Details section also shows what is in the headers and body for both the request and response, which makes it easy for the administrator to analyze the specifics of the threat.

Click the image below to view full-size.

For more than two decades SSL has ruled the roost as the predominant encryption protocol on the Web. This is unfortunate, at least because in recent years many vulnerabilities have surfaced in SSL. It’s had its day, done its job, and is now battle weary. Today, to say the least, early versions of SSL and TLS don’t get the job done when it comes to securing website traffic.

In fact, earlier this year, the PCI Security Standards Council removed SSL from its list of strong crypto protocols in the PCI Data Security Standard, and as of June 30, 2016 it will no longer be permitted as a security control. “That isn’t much time for everyone who needs to become compliant to become compliant,” said Ivan Ristic, director of application security at Qualys during his presentation The TLS Maturity Model here at Qualys Security Conference 2015 in Las Vegas.

“Life was much simpler back when we thought that encrypted communication via TLS was just secure. Not so any longer,” Ristic said.

Why does it matter? SSL and TLS, simply put, encrypt traffic between two endpoints, such as the web browser of a shopper and the server of an eCommerce provider. SSL has shown that it remains vulnerable to all sorts of attacks, such as the ability to grab data during communications, man in the middle attacks, among others.

“The SSL protocol (all versions) cannot be fixed; there are no known methods to remediate vulnerabilities such as POODLE. SSL and early TLS no longer meet the security needs of entities implementing strong cryptography to protect payment data over public or untrusted communications channels. Additionally, modern web browsers will begin prohibiting SSL connections in the very near future, preventing users of these browsers from accessing web servers that have not migrated to a more modern protocol,” the PCI Security Standards organization wrote in its report Migrating from SSL and Early TLS.

What should organizations do? One would think that it would be very straightforward, but it's not, Ristic explained in his keynote. He developed a TLS Maturity Model that is designed to help enterprises get to where they need to be, not only to be compliant, but to be secure.

The model has five levels, which range from utter chaos in Level 1 to a Level 5 which is probably more security than is necessary for most mere mortals. Level 4 is were most organizations will want to be, Ristic said.

Here is the model as he described in this post:

At 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 websites, 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 website 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.

LAS VEGAS – Philippe Courtot, Qualys (QLYS) founder and CEO, in his keynote address today at the Qualys Security Conference 2015, spoke to the massive and rapid evolution in business-technology systems currently underway in the enterprise. They are grappling with the complexities of securing their information in the public and private cloud, on mobile devices, and the data gathered by all of the sensors associated with the Internet of Things. Enterprises are “faced with the challenge of having to retool their entire infrastructure,” Courtot said.

While all of these new, emerging, and some rapidly maturing technologies are helping the enterprise to be more agile and respond to changing market conditions – all of these efforts need to be done securely.

“We still need to secure everything,” Courtot said. “In the old days everything was essentially perimeter-centric, and we were living very happily as the networks were evolving. But the problem with security started to become very critical as we needed to deploy more and more applications. “Unfortunately, enterprises are still architected for the old client/server world,” Courtot said.

So how do enterprises secure themselves in an "everything is connected to everything” world, Courtot asked? Well, what enterprises have been doing to date has not been working well for anyone. They’ve been turning to a plethora of point solutions: data leak protection/prevention, anti-virus and anti-malware, intrusion detection/prevention systems, network and next-generation firewalls, vulnerability assessment tools, threat intelligence and more. It’s very difficult to adequately protect enterprise systems when those enterprise systems, applications, and data are so dispersed across so many cloud services and endpoint devices, Courtot said.

Sensors and the Cloud

When it comes to building a security framework that would work for the modern and highly-agile enterprise, Courtot pointed to an analogy that is familiar to most everyone: home security systems. How are homes secured today? Home security systems rely on sensors and management systems that monitor homes for changes in heat, or signs of fire or flooding, motion detectors for intruders, and the status of garage and building doors and windows. "All of that information is beamed up to a cloud platform were all of that data is analyzed. And depending on conditions it then sends alerts and information to incident response, such as the local fire department, police, or perhaps private services. And all of that information is centrally managed [by the homeowner] on their phone,” Courtot said.

That’s how cloud security services for the enterprise need to also work: sensors in the enterprise environment that gather security and compliance information, asset information, and other data about the state of the systems and all of that data is then sent to a cloud service for analysis, which then provides security teams the information they need to protect their environments.

“Our appliance is unique from others,” Courtot said, and made the parallel to home security systems regarding how the Qualys Cloud Platform gathers all of the information security teams need about the state of their network, and how they can manage their security from anywhere in an app.

Going forward, that’s the kind of security capability enterprises will need to manage security at the scale that their clouds services are growing. “You need sensors that are gathering data from everywhere in the enterprise. And you need to integrate that security data with information about your assets, and analyze it all to see if they are secure and in compliance. If not, it needs to be acted upon,” Courtot said. “And today that means it has to scale, it has to be in the cloud,” he said.

Sometimes standard web application scanning techniques are too intrusive. The web application owner may not want to run a scan that tests for a vulnerability by uploading application data because that might have negative side effects for the application. It can be better to use an indirect method like web application fingerprinting which inspects static files in the web app to determine its version, and then reports the known vulnerabilities for that version.

Blind Elephant is a trustworthy open-source static-file web application fingerprinter. It attempts to discover the version of a (known) web application by comparing static files at known locations against pre-computed hashes for versions of those files in all available releases. This technique works well when the static files change with every release, allowing the fingerprinter to identify the application version based on the contents of the files. This technique is non-invasive and generic, and the use of pre-computed hashes means it is fast, low-bandwidth and highly automatable.

Over the five years since the open source Blind Elephant project was introduced, Qualys has maintained it, integrated it with the Qualys Cloud Suite, and added lots and lots of detections. That makes the Qualys integration a useful tool for web application security teams.

Qualys Integration & Detections

Qualys has been steadily adding detectable applications to the Qualys integration, which now detects over 200 web applications, plugins and extensions, and this number continues to grow every week. Qualys customers can look up QID 45114 in their scan reports and see a listing of the web applications found in their environment.

In order to add a detection, the Qualys team needs access to the source code and a few versions of the web application. With too few versions or files that remain unchanged across versions, it is not possible to create detections.

Uses Cases

The Blind Elephant engine can be most effective in the following scenarios that are too intrusive into the customer's application, and where it's better to determine the existence of the vulnerability indirectly, i.e. via fingerprinting:

• Post-Authentication Vulnerabilities: For example, persistent cross-site scripting vulnerabilities which need a user with certain rights in order to be successfully exploited.
• File Upload Vulnerabilities: Vulnerabilities that require the upload of arbitrary data on a customer's application to be successfully exploited.
• Remote Code Execution Vulnerabilities: Vulnerabilities that require execution of arbitrary code on a targeted system. For example, command injection vulnerabilities can be safely identified via Blind Elephant.
• SQL Injection: Because the number and names of tables may vary with the implementation of the application, so it's not possible to automate table lookups.

I remember a particular case when Blind Elephant was really helpful: MediaWiki DjVu and PDF File Upload Remote Code Execution Vulnerability (QID 12832). This was a zero-day affecting the software that powers Wikipedia. The tricky part was that to execute arbitrary code on an affected installation, one needed to upload a legitimate file on the server and then pass shell meta-characters to the application which would execute arbitrary code. Making it more urgent, a PoC was available! Since Qualys has always treated customer data confidentially, a file upload was out of the question. It was with Blind Elephant that this detection was made possible.

More Detections

Keep visiting the Blind Elephant Supported Detections to read about the support added for different web-applications and their extensions/plugins.  If you want a detection added for a certain open source web application, please post your request to the Blind Elephant community.

The OpenSSL team has announced a fix to resolve a high severity vulnerability (CVE-2015-1793) which allows certificate forgery. During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. It affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d

OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

Stable distributions of many Linux flavors are not affected:

RedHat: No Red Hat products are affected by the CVE-2015-1793 flaw. No actions need to be performed to fix or mitigate this issue in any way.

OpenSUSE: The OpenSSL versions shipped in openSUSE 13.1 and 13.2 are not affected. The openSUSE Tumbleweed distribution never received a vulnerable version and was never affected. The next submission into Factory will skip any vulnerable versions.

Ubuntu: Ubuntu versions 12.04LTS, 14.04LTS, 14.10LTS, 15.04 and 15.10 are not affected.

Debian: The stable and old stable versions are not vulnerable. The 'testing' and 'unstable' versions are affected.

Qualys has released QID 38104. Please refer to the knowledge base for more information on this check.

Would you buy a cellphone with a hardcoded password? Definitely not. I wouldn’t either.

But as is sometimes the case with non-mass-market devices, security can be overlooked in favor of convenience, even if in retrospect it’s clearly a mistake to do so. Fortunately, this story has a happy ending, thanks to responsible disclosure and quick vendor response.

As a vulnerability research engineer at Qualys, I routinely audit various devices, and today Qualys is releasing information on three new vulnerabilities I found on the Garrettcom Magnum 6k and Magnum 10k Series managed switches.

These devices had the following security issues:

• The firmware contained hardcoded password linked to a privileged account used for support and maintenance operations. A malicious person who discovered the password and had access to the device could execute commands or shut down the device. Even worse, a Shodan search indicated that at least seven of these devices are connected to the Internet and publicly discoverable.
• The firmware also contained hardcoded RSA private keys and certificate files. An attacker having access to these certificates and keys could not only decrypt the HTTPS secure traffic but also log in via ssh without a username/password to any device running the same version of the firmware.
• Less interesting but still important to fix were some cross-site scripting (XSS) vulnerabilities.

In accordance with Qualys’ responsible disclosure policy, we notified the vendor and ICS-CERT, the vendor has released fixes for the Magnum 6k series and for the Magnum 10k series, and now we are going forward with coordinated disclosure following publication of the ICS-CERT advisory.

About Garretcom Magnum

Garrettcom Magnum devices are a range of managed switches specially designed and hardened to withstand some of the most grueling industrial environments with high EMI, extended temperature range and significant atmospheric contamination. GarrettCom estimates the affected products are deployed primarily in the United States with a small percentage in Europe and Asia. According to GarrettCom, the devices are deployed across several U.S. critical infrastructure sectors including critical manufacturing, defense industrial base, energy, water, and transportation. According to their website the devices are used in the power industries, smart grid backbones, intelligent traffic systems and other industries / systems.

All tests were performed on firmware (Rel_6K_A450.bin) version 4.5.0 for Magnum 6k series as shown in the image below of the string output for the firmware binary.

I found three classes of vulnerabilities.

1. CVE-2015-3959: Hardcoded Passwords (A5: Security Misconfiguration)

CVSS Score: AV:N/AC:L/Au:N/C:C/I:N/A:N (how to read)

Firmware with hardcoded credentials or backdoors leave any device at a huge risk of getting hacked if an attacker gains knowledge of this information, allowing complete control of the device, as the accounts are generally high privileged accounts meant for support or maintenance operations. The firmware contained a hardcoded password for a high-privilege user : “factory” as shown in below snapshot:

The account was meant to provides an elevated access to the device, meaning an attacker having access to the device could gain elevated access to the device and change the device setting or initiate a complete shutdown causing a denial of service. Search results returned by Shodan reveal 17 active devices that are accessible over the internet, which are still having vulnerable versions of firmware running on them. The vulnerability were reported to be patched in earlier versions of the firmware, but we found that the account and password still exist. The newer firmware revision 4.5.6 fixes this issue, and users are advised to upgrade to the latest version.

2. CVE-2015-3960: Hardcoded RSA private key (A5: Security Misconfiguration)

CVSS Score: AV:N/AC:L/Au:N/C:C/I:N/A:N (how to read)

During the reverse engineering process of the firmware, it was discovered  that the firmware had hardcoded RSA private keys and certificate files, which were used by the server for SSH and HTTPS connections. Any firmware using hardcoded private keys and certificates pose a greater security risk, as the firmwares are meant for a series of multiple devices, all the devices running the affected or earlier versions of that firmware are by default vulnerable, which means that an attacker just has to gain access to the keys/certificates and he would be exploit any similar devices with ease. An attacker having access to these certificates and keys can not only decrypt the HTTPS secure traffic but can also log in via ssh without username/password to any device running the same version of the firmware.

A general best practice that should be followed while developing the firmware is to:

• Avoid use of any hardcoded keys
• The private keys should not be stored unencrypted format
• The private key should be protected with a strong passphrase which is long and hard enough to crack in case anyone gains access to the keys

In case with Garrettcom Magnum 6k and 10k device series, the firmware contained hardcoded key which were used for ssh connection to the device. The key are meant to provide ssh access to the device without any password, the key were protected using a passphrase that was easy to guess as demonstrated in the below snapshot.

Proof-of-Concept:

The snapshot below shows the key used for SSH connections to the device. The key is being protected by passphrase: “magnum6k” which was verified using PuTTY Key Generator, as shown below in next snapshot.

The firmware also had keys and certificates that were meant for HTTPS communication. Access to these certificates and private keys means that any attacker intercepting the traffic between the device and the users can decrypt the communication channel and tamper the data or conduct replay attacks. The below snapshot is for the key and cert used for HTTPS connections.

The private key above present in the firmware was tested using the HTTPS traffic captured between the browser and device and was successfully decrypted using the above key obtained from the firmware.As the private keys are hardcoded in the firmware, same keys were used across range of devices.

3. CVE-2015-3942: Improper Sanitization of user input (A3: Cross-Site Scripting XSS)

CVSS Score: AV:N/AC:L/Au:N/C:N/I:P/A:N (how to read)

Multiple XSS vulnerabilities were discovered in the web server which is present on the device. These vulnerabilities exist due to improper sanitization of user input which can be leveraged by an un-authenticated attacker to carry out cross-site scripting (XSS) attacks. As the web server and files remain same across all the devices, all the Magnum 6k and Magnum 10k devices are vulnerable

Proof-of-concept:

Below is the demonstration of the vulnerability, which shows that the device is vulnerable to XSS.

http://<server_url>/ gc/service.php?a="><img src=x onerror=alert('Xssed')><"

http://<server_url>/"><img src=x onerror=alert('Xssed')><"

http://<server_url>/gc/flash"><img src=x onerror=alert('Xssed')><"

Below is a snapshot of the vulnerability.

Private Keys and Certificates

Below are the private keys and certificates that were extracted from the firmware. The first Certificate and RSA key pair is for SSH connection. The rsa key is protected using passphrase: “magnum 6k” and can be verified by loading it in PuTTY Key Generator.

-----BEGIN CERTIFICATE-----

MIIDcTCCAtqgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBiDELMAkGA1UEBhMCVVMx

EzARBgNVBAgTCkNhbGlmb3JuaWExEDAOBgNVBAcTB0ZyZW1vbnQxGDAWBgNVBAoT

D0dhcnJldHRDb20gSW5jLjERMA8GA1UEAxMIbWFnbnVtNmsxJTAjBgkqhkiG9w0B

CQEWFnN1cHBvcnRAZ2FycmV0dGNvbS5jb20wHhcNMDUwNDI5MDEwOTM1WhcNMDYw

NDI5MDEwOTM1WjCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx

EDAOBgNVBAcTB0ZyZW1vbnQxGDAWBgNVBAoTD0dhcnJldHRDb20gSW5jLjERMA8G

A1UEAxMIbWFnbnVtNmsxJTAjBgkqhkiG9w0BCQEWFnN1cHBvcnRAZ2FycmV0dGNv

bS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKAjwUUr3aS5O+iuLz7Q

R6F+pHp+HyUPoWUvxBnKcr2/12FpN25OkBEubTWJ+wwDz9bX/V6Q9RsL6PWdY1OS

x6KBaN1274r71fQf4wzE0sZq/ThkXon5M1C1mRFGjFBf731A1DDSgYHXlY/Ekn0R

b4mhUCBmWORhdC7hNyyHTM9XAgMBAAGjgegwgeUwHQYDVR0OBBYEFIcT5dxybegN

e8G8SnqOXcZYNBs7MIG1BgNVHSMEga0wgaqAFIcT5dxybegNe8G8SnqOXcZYNBs7

oYGOpIGLMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEQMA4G

A1UEBxMHRnJlbW9udDEYMBYGA1UEChMPR2FycmV0dENvbSBJbmMuMREwDwYDVQQD

EwhtYWdudW02azElMCMGCSqGSIb3DQEJARYWc3VwcG9ydEBnYXJyZXR0Y29tLmNv

bYIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAFzVduVeU2+3BjPt

a3sAMTJJyGyb+5/HowxQLhlkpWy//CdrD9UTwPIs4qXOjB0ETJMNPCpxoJj5o6od

x7K3fpPYb0Un+5HLovXvkaWb+Hg1fcfoFucCjmiP2FrkaYdcCYvjwXkVwDADNepu

Lxq15PtoLcchtQXEob0jJMSDld+7

-----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,58D326A37D2A5F52

lfVfiGyCCCg/U1g6U5Exa7E5KpqqyE1ihCbvvPlb9BRpwa0b7ur+YUKWFrnP+/Hc

qcxa1vTdQkbofkjs2L8FYsnvzq7osXzXi3FhIcdGKgoLR3p5jg2OdwZagj1fBf5Q

fQu0oYMwved2fdLEdLaJkjfm/S72Z/ESGOyj1zVIdGZC5ltbD9Qp1lvhkLoez6JB

Z8B0UQ30EFyTPcJ0Auc+NIHpvuKrwcT84hun0QJEvgcn9Z1u28pu25jmIsC0LLz3

n8zn5TbQELwZF8llEWr0asSsAFsKO02gdah/w7kdaT91CjFbUEFgUQHqkRs2ALwf

oZqs1ZLvibtEM2rn9Ldq5ZZ9A5IlkecuhbeLshT2vMjW9raBdKutsGuviYWVvSIg

CF2A36BZdzeGspJuo6J/7DtAvTDsLp1jiumSldf31xiR6KWmbVgJfka89X72c0Lv

tNdrAv17qRmwxxug6yEoSo/U7CleBIE8ReN6TS7Hi0ZjBU7/kg5XNqDEI1S4Uasr

tE/cAdb0zxVXn7sVF8F5bJWP3BvTlDa5cMVwtDGPvV0yiPDiv8FUTuRtlUgLTUZ3

p3A1MfxaWBPO/dhDGC98HjyRlI2Dy5ykHxZRC44EEEn7E9W8b1K+vh1Hu+Ecu2+3

SCJ0xQZqzl5w4S934vG/M9tqzsnOkyl695nT0HICYeu1fLcN3UvaOVdRF8WQ63PT

Z4Jsoka+z6xTmX9LUGfd/bKYm+bTMAbog1eaiuP8mk0kaQFDx3NmZLSLleXSnS5I

Bxdgilak6Gd9sredChTzdGgG0988z+ClXy18CycBANL8U2jVu+j9iQ==

-----END RSA PRIVATE KEY-----

The below key and certificate are being used for HTTPS connections:

-----BEGIN RSA PRIVATE KEY-----

MIICXQIBAAKBgQC+NtXC4dGI5wf1h8p7hzSiYNlbsdQp68Aih4zFPQSBmcvAh0Cu

PeATnRiSG4w56Fo6PaDlmCkAg24l01qScyfJDe6t/3spmeZbWzU1k6OtndvNtqPl

2HfO7wiOthJS/oNq9r2tTkqX+VeZubpvJWZSC7kI6ohHotgRmYKPxfsLOQIDAQAB

AoGBALIXRSyhoT08kgcgjEP74xvk8Z0YcjyNreamYvaImp99D3fDKpv48sNqYobp

o/DTyyacbPiJ7lm8tHRV3ocfqi7EOERq4YXCyDFenlWvBuByyUAak6xG6K6zIhIG

r0xKXosAWiboWYemzDeS81EYQVfVdRTbo/CI7pmbziAj0uPBAkEA9uyqQ2BU5EnG

b5ddKM5Uk2vmvdK/We7lnlcXl214LBcOcFHvbf+h1VfG/2Lek73xCwHdcj5KcnEu

VbM1Ix0RlwJBAMU0k+jOD8S03Nox9CGNY79usEjn0Wfzj2pj4Eltb9em0K5RaRax

9lbqiRonnmfLBg5Ymot6M3kIjekPQQ+6w68CQE0TeN5JLpaH9NoWbGz1Yu8VilQM

edBvwtsXInURJabVl5s16D/0wKZgnOxRB1skuh4OefpUOVbZv3Xe16JbS4cCQH1K

qGaS9QW++0pNzpO6pxMrGilXz33CCu5HQmqkcxiKTa9S3fejXaVfIXhSj5vWK6TV

umq/WxCc1LysCmQZ/tUCQQDexekhrldyve81TuOG0G4tiJjIV/7GEQYsRHPjPqRj

WULhzmMEdnGnReH4ZY+eiqs94rxwt1FPkkff1/izsGRZ

-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE-----

MIICqTCCAhICAQAwDQYJKoZIhvcNAQEEBQAwgZwxCzAJBgNVBAYTAlVTMQswCQYD

VQQIEwJDQTEQMA4GA1UEBxMHRnJlbW9udDEYMBYGA1UEChMPR2FycmV0dGNvbSBJ

bmMuMRQwEgYDVQQLEwtFbmdpbmVlcmluZzEXMBUGA1UEAxMOU29mdHdhcmUgR3Jv

dXAxJTAjBgkqhkiG9w0BCQEWFnN1cHBvcnRAZ2FycmV0dGNvbS5jb20wHhcNMDYx

MjExMjAzMzA5WhcNMTYxMjA4MjAzMzA5WjCBnDELMAkGA1UEBhMCVVMxCzAJBgNV

BAgTAkNBMRAwDgYDVQQHEwdGcmVtb250MRgwFgYDVQQKEw9HYXJyZXR0Y29tIElu

Yy4xFDASBgNVBAsTC0VuZ2luZWVyaW5nMRcwFQYDVQQDEw5Tb2Z0d2FyZSBHcm91

cDElMCMGCSqGSIb3DQEJARYWc3VwcG9ydEBnYXJyZXR0Y29tLmNvbTCBnzANBgkq

hkiG9w0BAQEFAAOBjQAwgYkCgYEAvjbVwuHRiOcH9YfKe4c0omDZW7HUKevAIoeM

xT0EgZnLwIdArj3gE50YkhuMOehaOj2g5ZgpAINuJdNaknMnyQ3urf97KZnmW1s1

NZOjrZ3bzbaj5dh3zu8IjrYSUv6Dava9rU5Kl/lXmbm6byVmUgu5COqIR6LYEZmC

j8X7CzkCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCucRNrjIRa+F4cfNoh10fTESzR

cJw0Uh80JxAued1x1WM5J+RWx8jECSx6xu28QKoqRa5ru9/pngu0TS3eKRmscKSr

0+ILC6H9gyO2lOKRfhKQDH7Xee57QD141cWkQd4wnKcpSJqMEu305WSQdlF8ma8w

k6yX4cP+nUyw+/CQ7g==

-----END CERTIFICATE-----

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.

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

Update June 3, 2015: Notification of SSL Labs grading changes (including signups to get notifications by email) is now available at SSL Labs Notifications.