1-Way vs 2-Way SSL authentication

Table of Contents

  1. About SSL Authentication
  2. Quick Review
  3. Creating a Certificate Authority
  4. 1-way “Standard” SSL Authentication
  5. 2-way “Mutual” SSL Authentication
  6. Advanced SSL Authentication: CRLs, CDP, and OCSP
  7. Concept Review

About SSL Authentication:

SSL Authentication is nothing more than proving the authenticity of one or both parties in the formation of an SSL “Secure”  connection.

1-way “Standard” SSL Authentication is the most common, you use this every time you log into Facebook, your bank website, google, etc. The point of this type of authentication is for you (as the client) to verify the authenticity of the web site you are connecting to and form a secure channel of communication.

2-way “Mutual” SSL Authentication is less common than the traditional “one-way” SSL authentication we are a custom to when visiting secured websites. When we connect to our banking website or our favourite web e-mail site, we as the client are verifying the identify of the site we are requesting content from. This “one-way” authentication allows us as the client to connect with confidence that the web site we are receiving content from has been verified. this authenticity check is performed by our client browser with a little help from a third-party certificate authority.

Let’s first review a one-way SSL connection.

  1. The Client browsers receives https://google.com in it’s address barf
  2. Client browsers knows based on https:// that this connection will require an SSL handshake and sends a CLIENT_HELLO to the destined web server (google). This includes other things like SSL/TLS version, acceptable ciphers, etc
  3. The web server receives the CLIENT_HELLO request and sends a SERVER_HELLO back to the client. SERVER_HELLO contains SSL version, acceptable ciphers, and the server certificate.
  4. The client receives the servers certificate and it is verified against a list of known Certificate Authorities.
  5. If the certificate is proven to be in good standing, the client sends back a pre-master secret is encrypted inside the server’s certificate. Remember only the server can decrypt anything encrypted with it’s certificate because only the server has the decryption key. Server Certificate encrypts, Server Key decrypt’s.
  6. At this point both client and server have the pre-master secret and can calculate a master secret to use to symmetrically encrypt and decrypt data between them.

So as we can see from a traditional SSL handshake, the client is never verified as authentic. Now, in most situations this is fine, as most connect types of this nature only need to verify the server because that is where the content is coming from.

The difference: In a 2-way mutual authenticated SSL handshake, the server will ask the client to send its own certificate for verification. Just like the client asking for the server’s certificate in the 1-way SSL handshake above, the server will perform verification of the client certificate before continuing to the pre-master and master secret phase of the SSL handshake. If authenticity of the client cannot be verified the server closes the connection.

How is mutual trust obtained? Both the server and client must generate their own SSL certificate and keys, and both must be signed by the same Certificate Authority. This ensures that both the server and the client’s certificate are trusted. This allows authentication to remain asymmetrical, instead of symmetrical. For example, rather than have a shared password that 3 clients and the server use to encrypt and decrypt data. Each client and the server have their own certificates and keys that will be used for communication with the server. Asymmetrical authentication and encryption is better at enforcing authenticity because everyone has their own cert and key used to establish a secure connection with the server. Symmetrical authentication is faster at encrypting and decrypting but suffers from having every client use the same key.

What happens if a client key is compromised? In the symmetrical authentication scenario, mentioned previously, you would have a serious security issue on your hands. Each client would be at risk and the likely hood of eavesdropping would increase. An attacker only has to obtain one key to gain visibility into every connection. Asymmetrical on the other hand has a different way of handling this. Because each client has it’s own certificate and key pair, and the signing of each certificate is performed by a third-party Certificate Authority, one simply has to revoke the compromised client in the form of a CRL certificate(more on this later). Other client connections will not be compromised or have to be re-generated. The server verifying the client certificate will fail only for the revoked for the compromised client.

What happens if my Certificate Authority’s key is compromised? This is the worst case scenario that can happen in your PKI infrastructure.An attacker can impose and generate a new certificate authority certificate and start signing certificates that can be used to fake authenticity. In essence break the certificate authority’s trust.  Keep in mind a Certificate Authority key cannot decrypt your connections.

Let’s review….

  • Certificate Authority is a trustpoint used as a third-party between the parties trying to validate each other’s authenticity.
  • Asymmetrical encryption allows us to form a protected trust between two parties that do not need to know anything about each other.
  • SSL Certificates are used for authentication and for the remote party to use to encrypt it’s first message sent back
  • SSL CA Key is used to sign certificates authorized by a Certificate Authority
  • SSL Key used to decrypt data encrypted by the corresponding SSL Certificate
  • pre-master secret is used as a starting point in the calculation of the master secret
  • master secret is used as a symmetrical encryption/decryption key between both parties, making the process of encryption/decryption faster

I want to show a few scenarios on how to configure 2-way “Mutual” authentication. But first, we have to create our Certificate authority trust-point using openssl. There are otherways to do this, however for demonstration purposes of this post I will be using openssl.

Creating our Certificate Authority:

  1. Housekeeping, create a openssl-rootca.conf file with defaults in it so you don’t have to re-type them everytime you issue an openssl command.

    Create a openssl-rootca.conf file, vi /opt/openssl-rootca.conf

    NOTE: Most of these variables are the defaults pulled from the openssl.conf installed with my distribution.

  2. Creating our CA serial file, this is nothing more than an iteration number to start with when signing certificates.

      Making sure each signed certificate from the Certificate Authority has a unique serial number value. In the real world, a Certificate Authority would maintain a list of unique serial numbers for each Certificate it signs. It is only locally significant to the Certificate Authority, other CA’s will not recognize it. This may be useful to track certificates that you’ve signed with your Certificate Authority.

    • serial number file = iteration number of signed certificates, has to be an even number of characters (cannot be “101”, etc)
    • crlnumber file =  iteration number of the CRL certificate (more on this later)
    • index.sb file = This is a database file that contains information regarding the certificates that have been signed by the CA and their serial numbers
  3. Generate Certificate Authority’s key. (NOTE: Recommend 8192 key strength, I used 2048 for this demo to save space)

  4. Using the CA’s key, generate a CA certificate to be used for signing purposes in the next steps.

    NOTE: the -config openssl-rootca.conf uses our Housekeeping config file we created above to get it’s options from.

1-way “Standard” SSL Authentication

  1. Generate our web-server certificate and CSR for signing by our CA we created above

  2. Sign our web-server certificate with our MyRootAuthority CA from the previous section

  3. Check our web-server Certificate

  4.  Check the index.db file, So far so good!

    V = Valid, R = Revoked

  5. Configure our Apache2 Web-Server to use the certificate we just signed:

    • DocumentRoot = Where our webpage files are kept
    • SSLEngine = Enabled mod_ssl which is needed to have apache respond to SSL type requests
    • SSLCACertificateFile = The Location of our CA certificate
    • SSLCertificateFile = Location of the web-server.crt file
    • SSLCertificateKeyFile = Location of the web-server.key file
    • SSLOptions +stdEnvVars = This allows our index.php file to read from the Web-Server’s system variables, this is required because SSL information is happening at Layer 4, where HTTP is happening at Layer
    • See more Apache2.2 mod_ssl options here.
  6. Let’s create a index.php to help us check on the certificates used to connect to the web-server:

  7. Testing with Firefox


    N
    ote: “This Connection is Untrusted” makes sense, since Firefox has a list of Trusted Certificate Authorities and our MyRootAuthority we created is not one of them. We’ll add the MyRootAuthority in the next steps and re-check!

  8. Adding the rootCA certificate to Firefox’s trusted authorities.

    This is effectively the same as if you had GoDaddy or another CA sign your certificate since these third-parties root CA certificates are already loaded in your browser.

  9. Re-test


    A
    lrighty!! So our web-server certificate is now verified trusted by our MyRootAuthority in Firefox!! Remember, this is the same way a GoDaddy or VeriSign certificate would be verified, your browser actually has all those Trusted CA Certificates locally to use when connecting to servers.

2-way “Mutual” Authentication

Moving on to 2-way “Mutual” Authentication is actually fairly straight forward as well. We only have to keep in mind a couple of things along the way. First, both our Web-Server certificate and our Client certificates must be signed by the same Certificate Authority (If using GoDaddy or Verisign works as well). Second we must make sure our host acting as a server in this client/server relationship enforces client SSL authentication, which we will be done by our Web-Server running Apache2. Let’s get to it!

  1. Generate a few client certificates and CSR for signing by our CA.
    • Client1
    • Client2
  2. Sign our Client CSRs to obtain each client certificate.
    • Client1
    • Client2
  3. Check the database file, index.txt

    NOTE: See the list of certificates we just signed and their corresponding serial numbers (starting with 1001).

  4. Modify our Apache2.conf file to Enforce Client SSL Verification

    Let’s walk through what we changed.

    • SSLCACertficateFile = Only the rootCA.crt file from above is required, the rootCA.key is only used when signing certificates to be seen as valid.
    • SSLCARevocationFile = The location of the CRL certificate file denoting revoked certificates. (More on this later), it is commented out for now…
    • *SSLCARevocationPath = If we were not  using a browser as our client in this case and rather a server, such as Apache2-to-Apache2 communication, you can use this option to tell Apache to use this path as the CRL path of the far end.
    • SSLStrictSNIVHostCheck = Sets whether or not the client is allowed to access the VirtualHost if the name doesn’t match.
    • SSLVerifyClient = Does the client need to present a Certificate. Required, means certificate has to be validated.
    • SSLVerifyDepth = Tells Apache how deep it should verify before deciding if the client connection has a valid certificate. (In some scenarios you may have a Root CA, a Intermediate CA, a sub CA, etc)
    • SSLOptions +stdEnvVars = This allows our index.php file to read from the Web-Server’s system variables, this is required because SSL information is happening at Layer 4, where HTTP is happening at Layer 7.
    • More information, see http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
  5. Let’s do a quick test….

    O No!!! Our connection was reject because we didn’t supply a Cilent Certificate to the Web-Server

  6. Prepare our Client Certificates
    • Create a PKCS12 file containing both the client certificate and key to be imported into Firefox

    • Copy it and import it into Firefox, like this…

    • Refresh the Page and Choose the certificate we just imported
    • Success!!! and Success!!
    • Add the client2.pfx to Firefox
      • Using the same steps above convert the client2.crt and client2.key into a client.pfx file and copy it into Firefox.

      • Browse to the web-site again you will be prompted to choose which Client Certificate to authenticate with..(You may have to restart Firefox)


        NOTICE: As we can see from out PHP page, the server is receiving our Client #2 Certificate

Advanced SSL Authentication:

  •  Certificate Revocation List
    • So the last SSL Authentication item I wanted to go over is the generation and use of Certificate Revocation Lists(CRL). A CRL is used to provide either party a list of certificates that have been revoked by the Certificate Authority. As you can recall, once a certificate is signed by a Certificate Authority(CA) it is known to be trusted, and there is nothing stopping the information regarding a certificate and if it’s been revoked and shouldn’t be trusted. CRL to the rescue!!. There are several ways to make each party aware of the CRL, one can copy the file to both parties and when a new CRL is generated copy it to only the parties that are trusted(i.e. don’t copy it to a party you just revoked!). The other way we can distribute the CRL is make the CRL file publicially accessible via the web, such as http://web-server/crl.pem or something similar and have a manual download periodically. We also will have to regenerate our CRL everytime we want to revoke a certificate that has been signed by this Certificate Authority, regenerating our CRL “updates” our CRL file with the most current list of revoked certificates under this CA. As you might be thinking, this seems really labor intensive on Administrators…and you are right! Escpecially in scenarios with over 100 client certificates, etc. Later we will review two(2) common ways we can automatically distribute Revocation Lists, but for now let’s do it by hand.
    • Generating our CRL

      NOTE: Take a look at the Certificate(cat /opt/rootCRL.crl) and it is prefixed with BEGIN X509 CRL to tell us what type of certificate it is.

    • Activate CRL checking in Apache2 with the SSLCARevocationFile option

      NOTE: As of right now, you will still be able to connect with Firefox using either the client1.pfx or the client2.pfx.

    • Revoke the client2 Certificate

      We are not done yet, we can still access the web-server because a new CRL has not be generated.

      NOTE: See the Revoked Certificates section? That is where a list of Certificates with their Serial Number will be listed.

    • Reboot Apache2 to pick up the new CRL.pem, we must do this since we are using the SSLCARevocationFile option.

    • Browse back to the http://web-server page

      Sweet! We have been rejected because our client2 certificate has been revoked.
Publicizing Certificate Revocation Information:

There are two main distribution methods used when publicizing Certificate Revocation information. CRL Distribution Points(CDP) and Online Certificate Status Protocol(OCSP). Both are used to accomplish the same thing and allow each party to check the revocation of the other’s certificate. Both however work in completely different ways and are used/enforced differently depending on the application using them.

  • Certificate Revocation List(CRL) Distribution Point (CDP) relies on the x.509 extension crlDistirbutionPoint to be embedded into the certificate. CDPs use this crlDistirbutionPoint value as a target to query against asking for a CRL. Very simlilar to our local CRL above. The enforcement and checking of this x.509 extension is the applications responsibility, the application has to look for and check the target location for a CRL and act accordingly. All of these things must add up to accomplish the desired functionality of Certificate Revocation checking. Because of all these varilables that must be performed and exectued witout issues, many applications consider CDP optional, and in most cases if the CDP cannot be contacted, mark the certificate as valid!! I believe Internet Explorer is the only browser I could find that you could enforce CDP checking, and the inability to contact the CDP marks the certificate as untrusted. Both Chrome and Firefox did not even check with the CDP, and continued on in marking the certificate as valid
    • Let’s take a look at a CDP extension a well known server, like google.com

      Look for this section:

      We see the section is marked as X509v3 CRL Distribution Points…CDP!! Within the secion is the target to download the CRL file.
      Download the CRL and view it with openssl

    • As we can see there has been a revoked certificate within Google’s CRL with Serial Number: 377AE3B09D40E542. Pretty neat!
    • Creating our own CRL and publishing it requires a few steps
      • Adding crlDistributionPoint = URI:http://ocsp.thejimmahknows.com/rootCRL.crl to our x.509 extension server_req_ext, will add the extension to any new Certificates we sign with our Root Certificate Authority using openssl -config root_openssl.conf -extensions server_req_ext.
  • Online Certificate Status Protocol (OCSP) is another way of handling automatic Certificate Revocation. The main difference between CDP and OCSP is the way they perform both the accounting and client connections to query for revoked certificates. OCSP is protocol based and is simliar to HTTP in that it relies on requests/response method, similarly to many tcp service. A difference in accounting, OCSP will actually query the index.db file for the R/V flags rather than downloading a CRL from a distribution point. Another thing to keep in mind is compatibility as OCSP is not supported in all web browsers. Ricky Donato over at fir3net.com has a great write up and outline of the differences between CRL and OCSP, I suggest a read. And to his point I had to manually enable OCSP in Firefox, and even then there was compatablity issues. Here are some screenshots in getting OCSP enabled in Firefox:
     

    • Adding authorityInfoAccess = OCSP;URI:http://ocsp.thejimmahknows.com:8080 to our x.509 extensions, server_req_ext, will add the extension to any new Certificates we sign with our Root Certificate Authority using openssl -config rootca-openssl.conf -extensions server_req_ext.
    • OCSP Responder is the service that listens to OCSP requests coming in from clients.
      • Start it up
      • Check against it

    • Again this works in theory, however I was unable to get it to function properly with Firefox, even when enabling the OCSP config flags shown above. I continued to recieve and error message on the OCSP responded of “malformed request”. If any expters out there reading this arctile figure out a way to get OCSP working with Firefox, let me know n the comments please!
  • In summary, Automatic publication of revocation lists should work in theory, but there so many unknown variables that it tends to fall short. Does the client application support CDP or OCSP or neither? Will the client application enforce revoked certificates found via CDP or OCSP? What is the default behvior of an application that cannot reach either the CDP or OCSP? Turstwave has a tremendous write up going into more detail regarding CDP, OCSP, and EV. Both CRL and OCSP use a signed Certificate file from the Certificate Authority to prove their validity to the client as a revocation entity.

Concept review and thoughts…

  • SSL authentication is very powerful and versatile. We can verify the authenticity of a communication between two parties by issuing Certificates from a Trusted Certificate Authority. Whether that authority is publically known, such as GoDaddy, VeriSign, or Symantec, or a private Certificate Authority we set up using openssl.
  • Private CA: When setting up a private Certificate Authority using openssl, I would suggest thinking about who out of this relationship you want to manage and be the authoritative entity. Making the decisions on signing certificates as  trusted and in good standing.
    • Keep in mind when deciding who will be the Private Certificate Authority in this relationship and the concept of CRLs. Remember CRLs are published by the Certificate Authority, so understand that the Certificate Authority makes revocation decisions.
  • 2-Level CA: In a real world environment your Root Certificate Authority would be offline, meaning kept on a system that is not turned on. Root Certificate Authority’s certificates are usually in the span of 10-20 years. Hence the need for a subordinate root Certificate Authority with a shorter validity period that would perform actual signing of end-user certificates, such as our web-server, etc. This is commonly referred to as a 2-level Certificate Authority.
  • Trusting Public CA’s, if both parties of a communication use and trust Public CA’s, such as Godaddy or Verisign, then the client and server of a 2-way SSL handshake will be considered trusted and authenticate successfully.
    • With the above being true, consider an additional form of authentication before authorizing.
  • Authority Info Access(AIA) is an x.509 extension that provide\s details about how to access information regarding revocation extensions Certificate Authority.

 

Helpful links:

 

 

There are 3 comments left Go To Comment

  1. Pingback: Masking 2-Way “Mutual” SSL Authentication using F5 LTM or HAProxy | thejimmahknows /

  2. JR /

    “How is mutual trust obtained? Both the server and client must generate their own SSL certificate and keys, and both must be signed by the same Certificate Authority. This ensures that both the server and the client’s certificate are trusted.”

    As far as I’m aware, the only requirement is that each side trusts the other. I have never heard of the requirement that both certificates must come from the same CA. Is it the most common scenario? Yes, because in a 2-way authentication, the same entity is most likely creating the certificates for both sides of the connection. But I don’t know of any reason why the certificates can’t be created by two mutually trused CA’s.

    1. thejimmahknows / Post Author

      Hi JR,
      The scenario I mentioned with a third party CA signing both is when mutual trust has to be verified completely independent of the two parties asking for trust. This parent CA is trusted by both parties and can vouch for each party asking for authenticity. Hope that helps!

Leave a Reply

Time limit is exhausted. Please reload CAPTCHA.