TLS provides the following security for communications across TCP/IP connections:
TLS uses Rivest Shamir Adleman (RSA) public key cryptography for authentication. In public key cryptography, each application has an associated public key and private key. Data encrypted with the public key can be decrypted only with the private key. Data encrypted with the private key can be decrypted only with the public key.
Public key cryptography allows an application to prove its identity by encoding data with its private key. As no other application has access to this key, the encoded data must derive from the true application. Any application can check the content of the encoded data by decoding it with the application's public key.
The TLS Handshake Protocol
Consider the example of two applications, a client and a server. The client connects to the server and wishes to send some confidential data. Before sending application data, the client must ensure that it is connected to the required server and not to an impostor.
When the client connects to the server, it confirms the server identity using the TLS handshake protocol. A simplified explanation of how the client executes this handshake in order to authenticate the server is as follows:
The client initiates the TLS handshake by sending the initial TLS handshake message to the server.
The server responds by sending its certificate to the client. This certificate verifies the server's identity and contains its public key.
The client extracts the public key from the certificate and encrypts a symmetric encryption algorithm session key with the extracted public key.
The server uses its private key to decrypt the encrypted session key which it will use to encrypt and decrypt application data passing to and from the client. The client will also use the shared session key to encrypt and decrypt messages passing to and from the server.
The TLS protocol permits a special optimized handshake in which a previously established session can be resumed. This has the advantage of not needing expensive private key computations. The TLS handshake also facilitates the negotiation of ciphers to be used in a connection.
The TLS protocol also allow the server to authenticate the client. Client authentication, which is supported by Orbix 2000 SSL/TLS, is optional in TLS communications.
As any application can have a public and private key pair, the transfer of the public key must be accompanied by additional information that proves the key is associated with the true server and not some other application. For this reason, the key is transmitted as part of a certificate.
Certificates in TLS Authentication
The public key is transmitted as part of a certificate. A certificate is used to ensure that the public key submitted is in fact the public key which belongs to the submitter. For the certificate to be acceptable to the client, it must have been digitally signed by a certification authority (CA) that the client explicitly trusts.
The International Telecommunications Union (ITU) recommendation X.509 defines a standard format for certificates. TLS authentication uses X.509 certificates to transfer information about an application's public key.
An X.509 certificate includes the following data:
The name of the entity identified by the certificate.
The public key of the entity.
The name of the certification authority that issued the certificate.
The role of a certificate is to match an entity name to a public key. A CA is a trusted authority that verifies the validity of the combination of entity name and public key in a certificate. You must specify trusted CAs in order to use Orbix 2000 SSL/TLS.
According to the TLS protocol, it is unnecessary for applications to have access to all certificates. Generally, each application only needs to access its own certificate and the corresponding issuing certificates. Clients and servers supply their certificates to applications that they want to contact during the TLS handshake. The nature of the TLS handshake is such that there is nothing insecure in receiving the certificate from an as yet untrusted peer. The certificate will be checked to make sure that it has been digitally signed by a trusted CA and the peer will have to prove its identity during the handshake.
When a client authenticates a server, confidential data sent by the client can be encoded by the server's public key. It is only the actual server application that will be able to decode this data, using the corresponding private key.
Immediately after authentication, an TLS client application sends an encoded data value to the server. This unique session encoded value is a key to a symmetric cryptographic algorithm.
A symmetric cryptographic algorithm is an algorithm in which a single key is used to encode and decode data. Once the server has received such a key from the client, all subsequent communications between the applications can be encoded using the agreed symmetric cryptographic algorithm. This feature strengthens TLS security.
Examples of symmetric cryptographic algorithms used to maintain privacy in TLS communications are the Data Encryption Standard (DES) and RC4.
The authentication and privacy features of TLS ensure that applications can exchange confidential data that cannot be understood by an intermediary. However, these features do not protect against the modification of encrypted messages transmitted between applications.
To detect if an application has received data modified by an intermediary, TLS adds a message authentication code (MAC) to each message. This code is computed by applying a function to the message content and the secret key used in the symmetric cryptographic algorithm.
An intermediary cannot compute the MAC for a message without knowing the secret key used to encrypt it. If the message is corrupted or modified during transmission, the message content will not match the MAC. TLS automatically detects this error and rejects corrupted messages.