Back to qualys.com

SSL Labs Grading Update: Forward Secrecy, Authenticated Encryption and ROBOT

We are giving advance notification for following grading criteria changes applying from March 1, 2018: Not using forward secrecy, not using AEAD suites, and vulnerability to ROBOT. Update: This release also includes a grading change for some Symantec certificates.

Penalty for not using forward secrecy (B)

Forward secrecy (FS) also known as perfect forward secrecy (PFS), is a property of secure communication protocols in which compromises of long-term keys does not compromise past session keys. Forward secrecy protects past sessions against future compromises of private key. The very popular RSA key exchange doesn’t provide forward secrecy. You need to support and prefer ECDHE suites in order to enable forward secrecy with modern web browsers.

SSL Labs will start penalizing servers that don’t support forward secrecy; Grade will be capped to B. We will not penalize sites that use suites without forward secrecy provided they are never negotiated with clients that can do better.

Penalty for not using AEAD suites (B)

Your site should use secure cipher suites. AEAD is the only encryption approach without any known weaknesses. The alternative, CBC encryption, is susceptible to timing attacks (as implemented in TLS). AEAD suites provide strong authentication, key exchange, forward secrecy, and encryption of at least 128 bits. TLS 1.3 supports only AEAD suites. SSL Labs doesn’t currently reward the use of AEAD suites. In this grading criteria update we will start requiring AEAD suites for A.

Grade will be capped to B, if AEAD suites are not supported. As with forward secrecy, we will not penalize sites if they continue to use non-AEAD suites provided AEAD suites are negotiated with clients that support them.

We have talked about these changes in Announcing SSL Labs Grading Changes for 2017.

Penalty for ROBOT vulnerability (F)

Return Of Bleichenbacher Oracle Threat, is an attack model based on Daniel Bleichenbacher chosen-ciphertext attack. Bleichenbacher discovered an adaptive-chosen ciphertext attack against protocols using RSA, he demonstrated the ability to perform RSA private-key operations. Researchers have been able to exploit the same vulnerability with small variations to the Bleichenbacher attack.

SSL Labs will start giving “F” grade to the servers affected by ROBOT vulnerability from February 28, 2018 March 1, 2018. Note: All changes described in this blog post go live on March 1.

SSL Labs has started giving a warning if the site doesn’t support forward secrecy and/or AEAD suites; or if the site is vulnerable to ROBOT.

Penalty for using Symantec Certificates (T)

Starting March 1, 2018, SSL Labs will give “T” grade for Symantec certificates issued before June 2016.

See details in Google and Mozilla are Deprecating Existing Symantec Certificates.

11 responses to “SSL Labs Grading Update: Forward Secrecy, Authenticated Encryption and ROBOT”

  1. I consider this being a major step forward because by this, the basic and known sources of long-term “ancient” and so-to-say “inherited” weaknesses get commonly penalized now.
    Additionally, this prepares and literally “calls” for TLS 1.3 being introduced soon as the “most secure” TLS standard ever proposed (because it excludes former Problems and suites).
    While TLS 1.2 does not urgently need to be abolished first, as long as all required and
    recommended protocol mitigations, plus HSTS, SCSV, no fallbacks, current certificate types and strengths, only strong authenticated ciphersuites are in place using the latest available implementations, by which it also provides sufficient security relating to the recommended conditions as proposed in the latest PCI recommendation.
    Can anyone btw push MS to finally implement ChaCha20_poly1305 [rfc7905] also into their SCHANNEL for IE/Edge as well as for their servers ? (yes and why not also the CAMELLIA suites [rfc3713] which are up-to-date and secure?). This is then what I would really call a “versatile” https engine.

    • Dear BerndP and bloggers,

      A big big fat +1 for your post until Schannel/IE/EDGE.

      You work for a large (read MS shop) company or not in website development.
      I do work for a company in website development.
      We consider IE/EDGE as legacy browsers and avoid spending much work to get it to work with them, implying cosmetic errors are fixed on as time permits basis.

      Schannel (server 2012 side) had its compatibility (are people doing testing there?) issues with AES with GCM, being fixed with a patch to disable these ciphers all together and never got fixed permanently. Leaving AES with CBC as the strongest. Not great.

      Customers can upgrade to server 2016 to get what they deserved (AES w/ GCM) with server 2012 in the first place: this smells like a sales trick of the dirty kind.

      Log story short: avoid MS client and server side to the max or if you are stuck with a 2012 server (or earlier), place NGINX as proxy in front and you can even end up with TLS 1.3 draft 18 on top of all the other RFC goodies. Don’t waste your time with MS and Schannel (I mute from here as a start).

  2. Interest is growing in wanting to know the following.

    1) From an SSL labs perspective – If the appropriate patch is applied and the TLS/RSA cipher is not removed will SSL labs still trigger a failing grade?

    2) From a Qualys VM perspective – If the patches are applied and again the TLS/RSA cipher is not removed from the asset , will the Qualys VM program trigger a vuln. based on the existing TLS?RSA remnant?

  3. SSL Labs also detects it now but has indicated that all sites that have it will be given the lowest grade possible of ‘F’ as of next month. Can you provide a rationale that you can share?

    In comparison, Qualys Enterprise has the vulnerability as a CVSS 4.3, so not as High as an F. When will these failing grades be received Feb.28 or March 1st?

  4. Dear bloggers,

    To be honest, I find the capping to B for sites that have nothing better than ‘TLS_RSA_’ rather double standard and of weak knees. Weak knees and its friends in mitigation, got the SSL/TLS stack in the current mess in the first place.
    Because, if 1024 bits DHE (usually also a common parameter file) is in use, your grade is capped to C and for all the good reasons.
    Also, and even more important, the fine ROBOT researchers made it very clear, passing the ROBOT vulnerability test does not necessarily mean you are in safe waters.
    I like to go even a step further and promote a cap to D for RSA key exchange-only sites.

    On a side note: I have big trouble digesting a site that gets an A+ while having a fall back to ‘TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)’. ‘wired.com’ is such an example, and they avoid here the C cap penalty for legacy DH by falling back to RSA Kx. In fact from a previous blog like this: “To that end, we’ll be modifying our grading criteria to penalise sites that negotiate 3DES with TLS 1.1 and newer protocols. Such sites will have their score capped at C”.
    Disclaimer: It’s all about fairness and nothing against ‘wired.com’ and sub-domains.

  5. Hello:

    When do you start to grade the site to B, if they don’t support AEAD, is that at the beginning of Mar 2018 or end of Mar 2018?

Leave a Reply