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.
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.
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).
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. Despite having been addressed in TLS v1.1 in 2006, the problem is still relevant because most clients and servers do not support newer protocol versions. Practical mitigation requires that your servers speak only RC4 when using TLS v1.0 or SSL v3.0.
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.
(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.
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