Security

Web application security frameworks, part 4: Digital certificates

Often you will want parts of your Web application to be exclusive to certain users. This access distinction requires the use of Web application security frameworks. We explore digital certificate authentication in this continuing series.


In a previous article, we covered the second Web application security framework (WASF), operating system level authentication, which is primarily used within corporations for internal applications. This is because it is dependent on an existing network infrastructure, where administrators are already setting up user accounts and managing security settings. After a user logs onto the network, the user's browser will supply their network credentials to the Web server. The Web server will then check to see if the user does or does not have rights to view that particular requested page and respond accordingly.

In this article we'll take a look at the third WASF, digital certificates. As you'll see, this model is the costliest method because it requires purchasing digital certificates for both the servers and the clients. However, this model more than makes up for its cost in the security it provides.

What is it?
This framework is a method for authenticating and authorizing a user by digital certificates on both the Web server and the user's machine. This methodology is primarily used for applications that contain the most stringent security requirements.

The goal of this system is absolute security. With the database lookup and OS level authentication frameworks, we required the users to log in to the Web site by supplying their usernames and passwords. In one example, the login page was a Web page, and in the other example, the login took place at the time you logged in to the network. These two methods took these logins and passwords and verified them against a repository of data. There was no third party involved. If the data matched, then you were accepted to be who you said you were.

With digital certificates, things are a bit more complex. You must obtain a digital certificate from a third-party source. This third party certifies that you are who you say you are by verifying your identity.

The obvious benefit of this is the elimination of mistaken identities. Whether or not a person has a proper username or password, without a digital certificate from a trusted source verifying their identity, the user is denied access to the Web server.

Digital certificates are not cheap, and so their implementations are limited for two-way communication. However, in extremely secure environments where authentication and identification is imperative, these certificates are very helpful. When sensitive or valuable data must be passed back and forth between a user and a Web server, an exchange via digital certificates is a must.

How does it work?
To help you understand this framework, here's a brief overview of Secure Socket Layer (SSL) technology. SSL calls utilize a one-way implementation of this framework. When you initialize an SSL session, your browser (the client) has several "handshakes" (mini-exchanges) with the Web server. The handshakes are as follows:
  • The client hello: The client sends the server a challenge and what type of encryption it supports.
  • The server hello: The server responds with a connection ID, certificate info, and what type of encryption it supports.
  • The master key: The client verifies the certificate, sets up a master key, and encrypts it.
  • The connection ID: The client sends back the connection ID encrypted.
  • The challenge: The server sends back the client's challenge encrypted.
  • The session ID: The server and client establish an encrypted Session ID.

The above is just a rough run-through on what happens when utilizing SSL. I've left out the parts about public/private key encryption and the details about bit length. The important thing to understand is that SSL is a conversation between the server and the client.

Two-way SSL is what we're describing in this article. The main difference between standard SSL and two-way SSL is the number of digital certificates. In the standard SSL, only the server has the certificate. The client is more concerned with verifying the server is who it claims to be, whereas the server doesn't really care if the client is absolutely who they say they are. This is the case for e-commerce, Web-based mail, etc. In two-way SSL, the server is concerned that the client truly is who it claims to be.

How secure is this model? By definition, it is the most secure. With digital certificates, there is inherently more security due to the encryption schema, whether it is 40-bit, 128-bit, or higher. Having two certificates makes it even safer, because an outside authority can not only vouch for the server's identity but also for the client's identity, which must be confirmed before the certificate is authorized.

How is it implemented?
The primary method for implementing this security framework is a multi-step process involving both the client and the user. First, the digital certificates will need to be requested from an authorized Certificate Authority (CA). The CA will verify you are who you say you are and that you have the authority to purchase the certificate. Once you are authorized, you will then have to purchase the certificates from the CA. The certificates will need to be installed and configured on both the client's machine and the Web server.

Because each digital certificate can cost a few hundred dollars, you can see how this solution can get very expensive, very quickly since each client must purchase a certificate.

As we pointed out earlier, this type of implementation is not for everyday situations. Rather, the primary users of this WASF model would be government or research institutes. These groups have small select groups of users who have to share a lot of similar, sensitive data, but may not always be located within close proximity.

Secure, yet simple
Digital certificates were primarily created to ease people's fears about passing sensitive data across the Internet. The way it achieved its goal of easing fears was by providing a secure, yet simple, way to verify that machines on the Internet really were what they claimed to be and to ensure that no one could eavesdrop on private Internet exchanges. As with most things created to ease people's fears, that comfort comes at a price. Primarily, only Web servers have these costly digital certificates configured. However, when absolute security is required, these digital certificates can also be installed on the clients for even greater assurance that the conversation taking place is between two authorized sources.

Next in the series
The next article in the series is a wrap-up of all three WASFs. We'll briefly describe each type and then review its pros and cons. As you can see, the type of environment and the level of security have a big influence on those decisions.


Editor's Picks

Free Newsletters, In your Inbox