I was recently working on a project for a customer that involved setting up communications between EXTOL’s EBI product and a third-party electronic invoicing provider. At the outset of this project, looking over the communications requirements, most seemed very typical and straightforward. However, one of the requirements took things a step further: the SSL communication will include two-way authentication. Using two-way authentication in SSL is just becoming more prevalent as security issues are becoming a higher priority and security requirements are becoming increasingly more stringent.
Let’s start with an explanation of two-way authentication, which involves three things — SSL, server authentication and client authentication.
SSL, or Secure Sockets Layer, is a means of securing communications over a network so that only the sender and receiver have access to the sensitive data that is contained within. Even if you’re not familiar with the technical details of how SSL works, chances are you’ve used it. If you’ve ever bought a book from Amazon or won an auction on eBay, you’ve used SSL. During the checkout process, you may have noticed the little padlock icon in the status bar of your web browser, or that the URL field of your browser begins with “https.” This is indicating that your web browser is communicating with the website’s server via SSL as a means of securing your personal information, your credit card number, etc. This type of SSL between an ‘anonymous’ web browser and a website server includes what is commonly referred to as Server Authentication.1
Now let’s talk about server authentication. SSL server authentication consists of two components:
1. A server certificate is a required part of any SSL communication. The server certificate is a digital certificate that contains basic information and a digital signature that properly identifies the server that it is associated with. It is the means by which a client is assured of the identity and authenticity of the server with which it is communicating.
2. Server address validation is an optional part of SSL server authentication that adds an extra layer of security and server address checking. Server address validation simply means that the client validates that the URL that is contained in the server certificate and the URL of the server with which the client is attempting to communicate are in fact identical.
These two components, server certificate and server address validation, work together to establish trust between the client and the server so that the client is assured that it is indeed communicating with the proper server and not with some other potentially malicious server.2
Now that we’ve established what we mean by server authentication, let’s move on to client authentication. Essentially, client authentication is the same as server authentication, only this time it is a means of authenticating and identifying the client to the server. One thing to note is that whether client authentication is required or not for a particular server is something that is specified by that server. A server can be configured to allow connections from any client, or it can be configured to require any clients that attempt to connect to it to be authenticated. So, for a client to authenticate, it involves a client certificate and optionally client address validation.
Just like a server certificate, a client certificate contains basic information about the client’s identity, and the digital signature on this certificate verifies that this information is authentic. Client address validation, like its server counterpart, validates the URL from which the client is communicating and validates that it matches the URL contained in the client certificate. These aspects of client authentication protect a server by ensuring that it is accepting a communication from a known client instead of from an unknown and potentially malicious entity.3
The use of client authentication is appropriate for a scenario where the server should only accept connections from a specific limited group of authorized/allowed clients. An example of such a scenario would be where a company wants to limit connections to its server to only be coming from the company’s legitimate business partners. Client authentication lends itself quite well to this type of scenario.
We’ve briefly talked about server authentication and client authentication, but at the beginning of this blog entry I said that we would be discussing two-way authentication. So when am I finally going to get around to talking about that? Well, actually, we already have. Two-way authentication, also commonly referred to as mutual authentication, is a term used to refer to the combination of server and client authentication. The authentication that is occurring is mutual, or two-way, because the server is authenticating itself to the client, and the client is authenticating itself to the server.
One thing to note in all of this is that in an SSL communication, client authentication never occurs alone. As I said above, at the bare minimum an SSL communication requires server certificate authentication. So an SSL communication can either have server authentication only, or it can have two-way authentication.
Visit extol.com/webservices to learn more about Two-way SSL authentication using EXTOL Business Integrator.
In my next posting, I will be discussing a recent customer implementation that involved SSL two-way authentication, specifically focusing on the authentication issue that we encountered and how we got the issue resolved.
1 I refer to the web browser as being ‘anonymous’ simply in the sense that in a typical base SSL communication session that only includes server authentication, there is no identification or authentication being performed on the client.
2 Going back to the example of your web browser and the online store’s website, you can see that this establishment of identity and trust is critical so that you can be confident that when you’re submitting your credit card number for payment it is indeed being submitted to the online store that you intended it for and not instead to some malicious third-party hacker.
3 Thinking about our web browser and online store website example again, I’d like to point out that this sort of scenario is not well-suited for the use of client authentication, because online store websites would like to be able to accept orders from everyone (well, everyone that has valid credit card info).