AnsweredAssumed Answered

Some comments about the rating system

Question asked by Danny Thomas on May 6, 2012
Latest reply on May 16, 2012 by ckahlo

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 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. 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 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).