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

Some comments about the rating system

Danny Thomas

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

    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.

    • Some comments about the rating system

      Hi there,


      just my two cents what I learned during the last days.

      I wouldn't drop the score because the score allows you to compare certain detail configuration.

      A penalty for renegotiation, PCI compliance, session resumption and BEAST issues would

      make some sense. FIPS readiness is another issue, because FIPS doesn't cover the SHA256

      and SHA384 algorithms of TLS1.2 (basically FIPS is TLS1.0-based) and there are lots of national requirements incompatible with FIPS.

      However in our case we are not allowed to activate RC4 to defeat BEAST. Allowed ciphersuites

      are based von AES-256, AES-128 and 3DES-EDE togehter with RSA, RSA-PSK and (ECDHE-)


      Therefore we would like to deactivate TLS1.0 because TLS1.1 is the official minimum requirement,

      we're not interested to serve/support users with TLS1.0-only browsers. I don't know if ssllabs would

      be still able to connect to our servers to inspect the new configuration.


      Best Regards,