« Firefox SSL extensions | Main | Can you have too much SSL? »

July 22, 2009

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.

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

  2. 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!

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54fd889f2883401157223a6cd970b

Listed below are links to weblogs that reference Announcing the SSL Server Rating Guide and the Public SSL Server Database:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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?

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

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

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.

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

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?

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

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.

The comments to this entry are closed.

MY WORK

IronBee is the next generation web application firewall engine, and it's open source too.
ModSecurity Handbok cover
ModSecurity Handbook is the definitive guide to the world's most popular web application firewall.
Apache Security cover
Apache Security is the complete guide to securing your Apache web server.
SSL Labs offers a comprehensive SSL security assessment consisting of 250+ checks. To start, enter your domain name below:

ABOUT ME

Ivan Ristić is an open source advocate, entrepreneur, writer, programmer and web security specialist. He is the principal author of ModSecurity, the open source web application firewall, and the author of Apache Security, a concise yet comprehensive web security guide for the Apache web server.   [LinkedIn Profile]

My Photo

TWITTER

@ivanristic

    FEEDS