Server Authentication in SSL Internet Security

Netscape’s SSL-enabled client software always requires server authentication, or cryptographic validation by a client of the server’s identity.

As explained in Step 2 of The SSL Handshake, the server sends the client a certificate to authenticate itself. The client uses the certificate in Step 3 to authenticate the identity the certificate claims to represent.

To authenticate the binding between a public key and the server identified by the certificate that contains the public key, an SSL-enabled client must receive a “yes” answer to the four questions shown in Figure 2.

Although the fourth question is not technically part of the SSL protocol,

it is the client’s responsibility to support this requirement,

which provides some assurance of the server’s identity and

thus helps protect against a form of security attack known as “man in the middle.”

Figure 2    How a Netscape server authenticates a client certificate  

An SSL-enabled client goes through these steps to authenticate a server’s identity:

Is today’s date within the validity period?

The client checks the server certificate’s validity period. If the current date and time are outside of that range, the authentication process won’t go any further. If the current date and time are within the certificate’s validity period, the client goes on to Step 2.

Is the issuing CA a trusted CA?

Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure 2. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to Step 3.

If the issuing CA is not on the list, the server will not be authenticated unless the client can verify a certificate chain ending in a CA that is on the list (see CA Hierarchies for details).

Does the issuing CA’s public key validate the issuer’s digital signature?

The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate being presented.

If the information in the server certificate has changed since it was signed by the CA or if the CA certificate’s public key doesn’t correspond to the private key used by the CA to sign the server certificate, the client won’t authenticate the server’s identity.

If the CA’s digital signature can be validated, the server treats the user’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point, the client has determined that the server certificate is valid. It is the client’s responsibility to take Step 4 before Step 5.

Does the domain name in the server’s certificate match the domain name of the server itself?

This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate.

Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don’t match.

If the server’s actual domain name matches the domain name in the server certificate, the client goes on to Step 5.

The server is authenticate.

The client proceeds with the SSL handshake. If the client doesn’t get to step 5 for any reason, the server identifies by the certificate cannot be authenticate, and the user will be warn of the problem and inform that an encrypt and authenticate connection cannot be established.

If the server requires client authentication, the server performs the steps described in Client Authentication.

After the steps described here, the server must successfully use its private key to decrypt the premaster secret the client sends in Step 4 of The SSL Handshake. Otherwise, the SSL session will be terminated. This provides additional assurance that the identity associated with the public key in the server’s certificate is in fact the server with which the client is connected.

Man-in-the-Middle Attack

As suggested in Step 4 above, the client application must check the server domain name specified in the server certificate against the actual domain name of the server with which the client is attempting to communicate. This step is necessary to protect against a man-in the middle attack, which works as follows.

The “man in the middle” is a rogue program that intercepts all communication between the client and a server with which the client is attempting to communicate via SSL.

The rogue program intercepts the legitimate keys that are pass back and forth during the SSL handshake, substitutes its own,

and makes it appear to the client that it is the server, and to the server that it is the client.

The encrypt information exchang at the beginning of the SSL handshake is actually encrypt with the rogue program’s public key or private key,

rather than the client’s or server’s real keys.

The rogue program ends up establishing one set of session keys for use with the real server,

and a different set of session keys for use with the client. This allows the rogue program not only to read all the data that flows between the client and the real server,

but also to change the data without being detect.

Therefore, it is extremely important for the client to check that the domain name in the server certificate corresponds to the domain name of the server with which a client is attempting to communicate–in addition to checking the validity of the certificate by performing the other steps described in Server Authentication.

Client Authentication

SSL-enabled servers can be configured to require client authentication, or cryptographic validation by the server of the client’s identity. When a server configured this way requests client authentication (see Step 6 of The SSL Handshake), the client sends the server both a certificate and a separate piece of digitally signed data to authenticate itself. The server uses the digitally signed data to validate the public key in the certificate and

to authenticate the identity the certificate claims to represent.

The SSL protocol requires the client to create a digital signature by creating a one-way hash

from data generated randomly during the handshake and known only to the client and server.

The hash of the data is then encrypt with the private key

that corresponds to the public key in the certificate being present to the server.

To authenticate the binding between the public key and the person or

other entity identified by the certificate that contains the public key,

an SSL-enabled server must receive a “yes” answer to the first four questions shown in Figure 3.

Although the fifth question is not part of the SSL protocol,

Netscape servers can be configured to support this requirement

to take advantage of the user’s entry in an LDAP directory as part of the authentication process.

Figure 3    How a Netscape server authenticates a client certificate 

An SSL-enabled server goes through these steps to authenticate a user’s identity:

Does the user’s public key validate the user’s digital signature?

The server checks that the user’s digital signature can be validate with the public key in the certificate. If so,

the server has established that the public key asserted to belong to John Doe matches the private key used

to create the signature and that the data has not been tamper with since it was sign.

At this point, however,

the binding between the public key and the DN specified in the certificate has not yet been established. The certificate might have been create by someone attempting to impersonate the user. To validate the binding between the public key and the DN, the server must also complete Step 3 and Step 4.

Is today’s date within the validity period?

The server checks the certificate’s validity period. If the current date and time are outside of that range, the authentication process won’t go any further. If the current date and time are within the certificate’s validity period, the server goes on to Step 3.

Is the issuing CA a trusted CA?

Each SSL-enabled server maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure 3. This list determines which certificates the server will accept. If the DN of the issuing CA matches the DN of a CA on the server’s list of trusted CAs, the answer to this question is yes, and the server goes on to Step 4.

If the issuing CA is not on the list, the client will not be authenticated unless the server can verify a certificate chain ending in a CA that is on the list (see CA Hierarchies for details). Administrators can control which certificates are trust or not trust within their organizations

by controlling the lists of CA certificates maintained by clients and servers.

Does the issuing CA’s public key validate the issuer’s digital signature?

The server uses the public key from the CA’s certificate (which it found in its list of trusted CAs in Step 3) to validate the CA’s digital signature on the certificate being presented. If the information in the certificate has changed since it

was sign by the CA or if the public key in the CA certificate

doesn’t correspond to the private key used by the CA to sign the certificate,

the server won’t authenticate the user’s identity.

If the CA’s digital signature can be validate,

the server treats the user’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point,

the SSL protocol allows the server to consider the client authenticated and proceed with the connection as described in Step 6. Netscape servers may optionally be configured to take Step 5 before Step 6.

Is the user’s certificate list in the LDAP entry for the user?

This optional step provides one way for a system administrator to revoke a user’s certificate even

if it passes the tests in all the other steps. The Netscape Certificate Server can automatically remove a revoked certificate from the user’s entry in the LDAP directory.

All servers that are set up to perform this step will then refuse to

authenticate that certificate or establish a connection.

If the user’s certificate in the directory is identical to the user’s certificate presented in the SSL handshake,

the server goes on to step 6.

Is the authenticate client authorize to access the request resources?

The server checks what resources the client is permit to access according to the server’s access control lists (ACLs)

and establishes a connection with appropriate access. If the server doesn’t get to step 6 for any reason,

the user identify by the certificate cannot be authenticate,

and the user is not allow to access any server resources that require authentication.


Leave a Reply

Your email address will not be published. Required fields are marked *