SSL Certificates: What are you paying for?

Document Version 1.0 (November 28, 2001)
Author Daniel Fisher <>
Editor Peter Haggerty <>

Copyright (C) 2001 Daniel Fisher. All rights reserved.
Permission is granted to quote, reprint or redistribute provided the text is not altered, and appropriate credit is given.

  1. Introduction

    This document is a small chronicle of our research into SSL certificates. We discovered that 128 bit certificates are no longer necessary to provide strong cryptography solutions and should be phased out.

  2. How it all began

    Recently my group at work (Middleware Services) was given the task of designing and implementing the campus LDAP. We began investigating how to tunnel LDAP communications through SSL. During the process our director asked us to verify that the certificate being sent during the SSL handshake was indeed a 128 bit certificate. At this point we asked ourselves a question we probably should have asked long ago. (After all, we've been using SSL for HTTP communication for quite some time.) That question was: 'What is the difference between a 128 bit certificate and a 40 bit certificate?'. The answer seems simple, right? 128 bit certificates provide better security. This is certainly a reasonable conclusion to draw. I mean after all it is a bigger number.

  3. The wheels start turning

    We began researching exactly how a SSL handshake works and specifically how a 128 bit certificate affects the outcome of that handshake. 1 In order to fully explain our conclusions I will go over the part of a SSL handshake which is pertinent to this discussion. If you want to know all the gritty details you should purchase a book on this topic.

    A simplified SSL handshake looks like this:
    1) the client sends the server a list of supported ciphers
    2) the server chooses a cipher and sends that cipher along with
       it's certificate back to the client
    3) the client verifies the server's certificate and extracts the
       server's public key
    4) the client encrypts a secret using the server's public key and
       sends it to the server
    5) the server decrypts the secret using it's private key
    At this point the client and server both share the secret and can be confident that no one else knows it. The client and server can now use this secret and the chosen cipher to have a secure conversation. Let me reiterate that this is a very simplified explanation of a SSL handshake, but necessary in order to explain what we figured out. So what difference does a 128 bit certificate make in this transaction? The server chooses a cipher before the client ever receives the server's certificate. In order to answer that question we needed a little history lesson.

  4. Cryptography regulations

    Let's step away from the technical issues for a moment and look at some of the regulations the United States government placed on strong cryptography. Before September of 1998 it was against U.S. law to export strong encryption technology. What 'strong' actually meant was up for debate, but 40 bit encryption using RC2 or RC4 was known to get approval easier than other algorithms. There was one caveat to the export regulations, if your software was meant for banking transactions it could use strong cryptography. Web browsers were subject to these regulations just the same as any other software. Which is why when you went to download Netscape you had to choose between the domestic version (strong cryptography) and the export version (weak cryptography).

  5. It starts to come together

    So how is the export version of your web browser any different from the domestic version? Well, you may not believe this (we didn't at first), but the only difference is how the SSL handshake is handled. That's right, export versions of Netscape contain the same strong cryptography algorithms as the domestic versions. This isn't a secret either, C|Net wrote an article about it back in 1997, however it certainly isn't common knowledge. 2 Lets go back to the SSL handshake. The first thing that happens is the client sends a list of ciphers. In the domestic version of your web browser that list included strong ciphers. In the export version that list only included weak ciphers despite the fact that the browser actually contained strong cryptography algorithms. Remember, in order to export the software you couldn't use strong cryptography unless you were talking to a bank.

  6. The last piece of the puzzle

    In order to satisfy U.S export regulations and also allow export clients to be used for financial transactions SSL implementations included a feature to let these export clients start using their strong cryptography. This feature is commonly known as 'Server Gated Cryptography'. Basically what happens is when the client receives the server's certificate (step 3) if the client discovers that the server has a 'Server Gated Cryptography' certificate the client will perform a new handshake (once the current handshake is finished) using a list of strong ciphers. Thus upgrading the current session to strong cryptography.

  7. 128 bit?

    So what's all this business about 40 bit and 128 bit certificates? Let me just preface this by saying I think these are so poorly named it can do nothing but cause confusion. 40 bit certificates are certificates which do not contain the field which enables the 'Server Gated Cryptography' feature in clients. As you may have guessed 128 bit certificates are certificates which contain this special field.

  8. Our conclusions

    If your clients are mostly domestic clients there is no need to purchase 128 bit certificates. Since the U.S government in January of 2000 relaxed cryptography regulations there are fewer and fewer export clients. Netscape has not produced an export grade browser since version 4.74. 3 Therefore 128 bit certificates are less and less useful and should be phased out.

  9. Footnotes

    1. Introduction to SSL
      SSL and TLS: Design and Building Secure Systems
    2. Communicator, IE crypto cleared
    3. Netscape Archived Client Products