Announcing the SSL Server Rating Guide and the Public SSL Server Database
It is my great pleasure to announce two new SSL Labs projects today. Although I launched SSL Labs a month ago using something else as an excuse, the two projects I am announcing today are the real reason SSL Labs exists. After several months of hard work, my two projects are finally ready for the public.
-
The SSL Server Rating Guide is a no-nonsense SSL server assessment guide. From the introduction:
The Secure Sockets Layer (SSL) protocol is a standard for encrypted network communication. We feel that there is surprisingly little attention paid to how SSL is configured, given its widespread usage. SSL is relatively easy to use, but it does have its traps. This guide aims to establish a straightforward assessment methodology, allowing administrators to assess SSL server configuration confidently without the need to become SSL experts.
The general idea is to give people something concise to work with, something they can pick up and use in a very short period of time. The guide not only makes SSL server assessment very easy, it also gives clear guidelines on what good configuration looks like.
-
But what good is a rating guide if you don't have tools that will do the hard work for you? Noticing a lack of good SSL assessment tools, I built one and made it into a free online service. The Public SSL Server Database was born.
I hope you will find the projects useful!





Yes - very useful. I think "Table 6. SSL configuration guidance" is particularly helpful.
Perhaps getting away from the issue of SSL configuration, and more onto application design, there's a couple of areas where I feel OVER-use of SSL might be a problem:
1. sites that ONLY operate under SSL, and are not available without SSL, even though most of the content is public and not in any way sensitive (does this over-use undermine confidence or increase distrust is other non-SSL sites?)
2. sites that are generally not SSL, but allow content to be accessed using SSL by unauthenticated users (authenticated users always being forced to use SSL)
Are these SSL-abuse problems or not?
Posted by: Clerkendweller | July 23, 2009 at 09:17 AM
Any thoughts on making a private SSL database for sites that don't want others knowing about poor configurations? I'd love to use this service but I also don't want others knowing if we use weak/null ciphers. Of course if the site is public, anyone can find this out for themselves unless you restrict it to sites using the "private" service.
Good idea! I guess we can stop using SSLDigger since it hasn't been updated in ages...
Posted by: Neil | July 23, 2009 at 09:29 PM
Colin,
Those are very interesting questions. I though it would be better to discuss them in a separate blog post: http://blog.ivanristic.com/2009/07/can-you-have-too-much-ssl.html
Posted by: Ivan Ristić | July 24, 2009 at 12:37 PM
Neil,
I am glad you asked that. My plan is to introduce commercial services later on, and private (and real-time) testing is one of the features the list. The idea is to use the revenue from the commercial services to finance the free stuff.
Posted by: Ivan Ristić | July 24, 2009 at 12:41 PM
The SSL server assessment fails with the "standard" java error about duplicate extensions if I craft such a server certificate with duplicate extensions(this is not allowed within RFC 3280 section 4.2).
Just wanted to see what happens in this case(not sure if this one is of interest for you, anyway I pasted it here)...
If one uses a (private) CA(I can name one I guess) which when signing a certificate request adds certain extensions(if configured to do that) and does not check if for one extension same value already exists, duplicate extensions may appear(depending how it will add that extension).
With regards,
Adrian
Posted by: adrian | September 08, 2009 at 02:13 PM
Adrian, thanks for your comment. That's an interesting angle, although I am not sure if you're saying that SSL Labs does the right thing or the wrong thing?
Posted by: Ivan Risti | September 11, 2009 at 08:53 AM
I think it does the right thing in not continuing the assessment as such a certificate seems to not comply with the 'must not' from RFC 3280 section 4.2 related paragraph.
Perhaps the error or explanation why the assessment failed is not the most fortunate, but if it worths a more detailed error or explanation depends on the frequency of such a case in practice(maybe other things are more important now).
Cheers!
Adrian
Posted by: adrian | September 13, 2009 at 02:34 PM
I agree that the error messages can be improved. Fixing that is going to be a challenge, as many of the messages are generated by the underlying libraries and are not documented. Thus the only way to discover that a message exists is to run into it like you did.
Posted by: Ivan Ristic | September 16, 2009 at 09:42 AM