Comparisons are made against the previous month's data.
This is the summary of the effective SSL security implemented by the most popular web sites. To be secure, a site has to be well configured, which means that it must have the A grade. In addition, it must not be vulnerable to any of the two currently known attacks against SSL (Insecure Renegotiation and the BEAST attack).
The SSL Labs assessment grade reflects the quality of the configuration of an SSL web site. The assessment methodology is documented in the SSL Rating Guide.
All SSL sites use certificates as their digital IDs. However, in many cases a chain of certificates is needed to create a trust link between the user and a trust anchor. A common mistake is that the certificate chain is incomplete, which often results with certificate warnings on sites that are otherwise well configured.
Key strength is the foundation of SSL security. Sites with weak keys cannot provide robust security, even when everything else is well configured. At minimum, web sites should use 2048-bit RSA keys or 256-bit ECDSA keys. This chart shows both RSA and ECDSA keys, but the strength of the latter is converted to their RSA equivalent to make the comparison possible. For example, 256-bit ECDSA keys have strength equivalent to that of 3072-bit RSA keys.
below 1024 bits
HTTP Strict Transport Security (HSTS) is an SSL safety net: technology designed to ensure that security remains intact even in the case of configuration problems and implementation errors. To activate HSTS protection, you set a single response header in your websites. After that, browsers that support HSTS (at this time, Chrome and Firefox) will enforce the protection.
The goal of HSTS is simple: after activation, do not allow insecure communication with your website. It achieves this goal by automatically converting all plain-text links to secure ones. As a bonus, it will also disable click-through SSL certificate warnings.
Strict Transport Security
When it comes to data transfer, cipher strength is the measure of the security of the communication channel. Ciphers weaker than 128 bits are insecure and must not be used.
There are five protocols in the SSL/TLS family, but not all of them are secure. The best practice is to use TLS v1.0 as your main protocol (making sure the BEAST attack is mitigated in configuration) and TLS v1.1 and v1.2 if they are supported by your server platform. That way, the clients that support newer protocols will select them, and those that don’t will fall back to TLS v1.0. You must not use SSL v2.0, because it is insecure.
In 2009, the renegotiation feature of SSL was found to be insecure. A successful exploitation of this issue may allow the attacker to impersonate his victims and extract confidential data. Most vendors have issued patches by now or, at the very least, provided workarounds for the problem.
Extended Validation (EV) certificates are high-assurance certificates that rely on manual identity validation to establish links between web sites and the organizations behind them.
Sites that support the SPDY protocol.
Forward Secrecy is a protocol feature that protects each connection individually. It is designed so that is is impossible to compromise connection security by compromising the server private key.
Key strength is the foundation of SSL security. Sites with weak keys cannot provide robust security, even when everything else is well configured. At minimum, web sites should use 2048-bit RSA keys or 256-bit ECDSA keys. This chart shows both RSA and ECDSA keys, but the strength of the latter is converted to their RSA equivalent to make the comparison possible. For example, 256-bit ECDSA keys have strength equivalent to that of 3072-bit RSA keys.
The BEAST attack is a practical attack based on a protocol vulnerability that was discovered in 2004. A successful exploitation of this issue will result in a disclosure of victim's session cookies, allowing the attacker to completely hijack the application session. It is no longer considered a threat because modern browsers ship with mitigations that prevent the attack.
Sites that support TLS compression. These sites are vulnerable to the CRIME attack.
RC4 is a very widely used cipher suite. Before 2013, we knew of some RC4 weaknesses, but it was thought that they did not affect SSL. With new research published in early 2013, we now know that RC4 is weak and should not be used.
The strength of a certificate signature depends on the strength of the hashing function used to produce it. Most certificates use SHA1 for hashing, but this function is known to be weak. It is advisable to use signatures that use SHA256 for hashing.
A vulnerability in OpenSSL 1.0.1 versions (before 1.0.1t) and 1.0.2 versions (before 1.0.2h). This vulnerability can be exploited by MITM attacker using a padding Oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server supports AES-NI.
The POODLE attack affects even some TLS implementations that don't have proper padding checks after decryption. The end result is that an active network attacker can relatively easily uncover small fragments of encrypted data (e.g., cookies).
RC4 is a very widely used cipher suite. Before 2013, we knew of some RC4 weaknesses, but it was thought that they did not affect SSL. With new research published in early 2013, we now know that RC4 is weak and should not be used.
RC4 cipher suites
This chart shows the weakest key exchange supported by the servers we monitor. Values of 512 bits are typically observed on servers that support insecure export suites; 768 on some servers that use weak DH parameters; 1024 bits is very common and also usually comes from weak DH parameters. At this time, 2048 bits is the minimum expected strength.
(CVE-2014-0224):
A vulnerability in OpenSSL 1.0.1 (all releases) allows a MITM attacker to attack connections with clients who also use OpenSSL (all versions). Successful attack downgrades the connection and gives the attacker full access to the traffic.
The DROWN attack is a cross-protocol security bug that attacks servers with modern TLS protocol suites by using their support for the insecure SSL v2 protocol and also in cases where the servers don't support SSL v2 but shares the same RSA-key/hostname with server that does. To mitigate this attack disable SSLv2 on all servers you have.
Servers that support a special signalling suite called TLS_FALLBACK_SCSV can detect protocol downgrade attacks when accessed by clients that also support this feature.
OCSP stapling is a performance optimization feature that enables web servers to embed certificate freshness proof in the TLS handshake itself. Clients that connect to servers that support this feature don't need to contact the issuing CA to double-check certificate validity.