10 Replies Latest reply on May 16, 2012 4:43 AM by ckahlo

    Some comments about the rating system

    Danny Thomas Lurker

      First off, thanks for this project which identified the

      configuration of our somewhat opaque load-balancer included

      40/56bit ciphers amongst other issues.



      NB I know virtually nothing about the area

      The Rating Guide has "For Consideration in Future Releases"





      * it's not the fault of the system, but some people might

        seek to maximize the ratings without realizing the potential

        impact. I can get a Protocol Support rating of 100% by only

        offering TLSv1.2, but suspect that would limit the range of

        clients who could connect



      * so apart from fixing obvious weaknesses pointed out by

        the individual scores, it would seem most people should

        be happy achieving a letter rating of "A". But it does

        seem incongruous that none of the Miscellaneous items

        count, apart from being flagged in the Summary. So it's

        possible to have a 98% "A" but

          * be vulnerable to BEAST

          * have insecure renegotiation

        I think these should carry a penalty so that you can't get

        an "A", maybe "B+". Similarly I thinks items not affecting

        security but indicative of sub-optimal configuration:

          * not offering session resumption

        could incur a 1 point penalty



      From those I've seen in the "Recently Seen" & "Worst Rated",

      it doesn't seem there's a reasonable distribution of "F" .. "A"

        I think SSLv2 & weak ciphers can give a "C" because the

        weak ciphers also reduce Key Exchange score

      I'd be tempted to

        * stop double-counting weak ciphers

        * move the thresholds upwards


      Perhaps offer a popup offering the choices listed in Server Rating

      "Configuration Guidance"

        Sites involving authentication


        internet banking and other high-value

        sites that contain highly sensitive data

      e.g. in the last case it becomes practical to limit the range

      of browsers that can be used.



      Finally, could a link to community.qualys.com be put on these

      pages as that (currently) has more entries of interest mainly

      because it covers a longer period of time.





      Best Practices == SSL_TLS_Deployment_Best_Practices_1.0.pdf

        Rating Guide == SSL_Server_Rating_Guide_2009.pdf



      There will be an update to the Rating Guide





      Protocol Support


      looks like

        95 with TLSv1.0, ...

        90 with SSLv3, ...

      which does match Rating Guide algorithm

        (score of strongest + score of weakest) / 2







      Cipher Strength


      Empirically noticed

        100 for >= 256bits

         90 for >= 128bits

      which does match Rating Guide algorithm

        (score of strongest + score of weakest) / 2

      You get 0 with an insecure cipher, e.g. anon







      Key Exchange


      The Rating Guide suggests the score is based purely on key length,

      and it does seem you need >= 4096 bits to get a 100% rating,

      e.g. factor.cc. The practical advice given in Best Practices is

        anything more (than 2048) than that is a waste of CPU power

        and will impair user experience.

      Server Rating recommends 4096 for sites with "highly sensitive data"



      It was not clear why uq.edu.au only gets a score of 40 as it uses

      a 2048 cert, but some experimentation on another site which

      scored 80 originally dropped to 40 after enabling 40bit ciphers.

      Maybe this is what Rating Guide means by "exportable key exchange"

      (which shows only a handful of hits on Google, so I don't think

      this phrase is commonly used).

        • Some comments about the rating system
          Ivan Ristic Level 5

          Hi Danny,


          Many of the points make are due to the fact that the Rating Guide was written in 2009, when we weren't aware (for example) about the issues with renegotiation and BEAST. The rating guide needs to be updated for today. The Best Practices guide is fairly recent, and has better advice.


          Yes, for virtually everyone it's only an A that matters, and not the score.


          Regarding SSL v2 and cipher suites, I see now reason to go there: SSL v2 should not be enabled, period. Why "improve" the scoring in that section, when SSL v2 should not be supported in the first place. Personally, I am inclined to fail everyone with vulnerabilities (and the includes SSL v2).


          I've toyed with the idea of using a scale that goes beyond 100. So, "normal" sites can score 100, but super-secure sites can score, say, 125. Or we can simply drop the numerical score altogether, leaving only the letter grades.