Server authentication

When you define a secure connection, Z and I Emulator for Web offers three options on the Security tab: Enable Security, Security Protocol, and Send a Certificate ( client authentication). 

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.

Server Authentication (SSL)

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 (zie.S1.com) and Server2 (zie.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 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 certificate and checks its list of trusted CAs 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.
Server requests and creates its own SSL session 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:

Client sends a request for an SSL session 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.
Client receives certificate and checks its list of trusted CAs 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.
Client compares the internet name in the certificate with the name of the server 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 (zie.S2.com) with the name of the server it wants to talk to (zie.S1.com). Since they do not match, Client knows that the connection should not continue and disconnects it.

Related topics