Server authentication & Client authentication

Server authentication

When you define a secure connection, Host On-Demand offers three options on the Security tab: Enable Security, Security Protocol, and Send a Certificate (). 

Enable Security

Click Enable Security to enable server and client authentication.

Security Protocol

Security Protocol specifies the method used for client and server authentication.   Select one of the following options:

TLS

Transparent Layer Security (TLS) protocol.  The TLS option creates a standard TLS connection between the client and the server.  The client contacts the server by sending a communication known as a handshake, which enables the client and server to authenticate to each other and specify the type of encryption that is used during the session.  All data exchanged between the client and server during the session is encrypted and cannot be read by a third party.  In addition, the protocol includes a message integrity check to ensure the integrity and reliability of transmitted data.

SSL

Secure Sockets Layer (SSL) protocol.  The SSL option creates a standard SSL connection between the client and the server.  The client contacts the server and checks to make sure that the server has a valid certificate. This type of connection ensures that all data exchanged between client and server is encrypted, and is therefore not readable by a third party on the Internet.

SSL by itself does not guarantee that the client is communicating with the correct server.  To illustrate the risks involved with this protocol, consider the following scenario. There are two servers, Server1 (hod.S1.com) and Server2 (hod.S2.com), and one client, Client. Both servers have valid certificates from a CA that the client trusts. Client wants a secure session with Server1, but Server2 wants to eavesdrop on their communication, and is physically located in such a place that it can do so. The scenario goes as follows:

	Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to the request by sending its own certificate to Client.
	Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.
	Having completed the secure session with Client, Server2 requests and creates its own SSL session with Server1. From this point, Client sends encrypted information to Server2. Server2 decrypts the information, re-encrypts it, then sends it to Server1. It does the same for information flowing in the opposite direction. The result is that, although all data is encrypted when it flows over the Internet, Server2 is able to read it, and even change it.

To help avoid this danger, the Server Authentication (SSL) option is provided. When this is switched on, the client, after making sure that the server's certificate can be trusted, checks whether the Internet name in the certificate matches the Internet name of the server. If they match, the SSL negotiation will continue. If not, the connection ends immediately.

For this check to be valid and give a positive result, two conditions must be met:

1. The client must be locally-installed. A client downloaded using http cannot be trusted for server authentication. If server authentication is of vital importance, you should use only locally-installed clients or use https on your Web server.
2. The common name in the server's certificate must match its Internet name.

With Server Authentication (SSL) enabled, the security scenario would proceed as follows:

	1. Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to Client's request by sending its own certificate to Client.
	2. Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.
	3. After the secure session has been completed, but before any real data has been sent or received, Client compares the Internet name in the certificate it received (hod.S2.com) with the name of the server it wants to talk to (hod.S1.com). Since they do not match, Client knows that the connection should not continue and disconnects it.

 

 

Client authentication

Client authentication is similar to except that the telnet server requests a certificate from the client to verify that the client is who it claims to be. The certificate must be an X.509 certificate and signed by a certificate authority (CA) trusted by the server. You can only use client authentication when a server requests a certificate from a client. Not all servers support client authentication, including the Host On-Demand Redirector. The later versions of the IBM Communications Servers (CS/NT, CS/AIX, etc.) all support client authentication.

When a server requests a certificate, the client has the option to send a certificate or attempt to connect without it. The server allows the connection if the client's certificate can be trusted. When a client attempts to connect without a certificate, the server might give the client access but at a lower security level.

	Client sends a request for an SSL session to Server.
	Client receives Server's certificate and checks its list of trusted CAs. Since Server's certificate is signed by a trusted CA, Client accepts the certificate. Server asks Client for a certificate that will identify the Client.
	Client sends a certificate or tries to establish a session without one.
	If Client sends a certificate, Server checks its list of trusted certificates. If the Client can be trusted, the secure session is established. If Client does not send a certificate, Server establishes a secure connection at a lower level of security.