Contents

• The Problem
• Protocols
• Certificates
• Applications
• How SSL Works
• SSL Sessions
• Conclusions

The Problem

Everybody uses the network to transfer data that is valuable and vulnerable to theft -- from a user's personal information, to commercial or technical data (including commercial secrets and intellectual property), to national-security and military secrets. Exacerbating the damage, the leak of such information can stay undiscovered for months, if not years.

Information theft is possible in two places:

1. On the remote side itself
2. In the middle of the network conversation, on the way from the user's computer to the remote side

If the remote side is supposed to be a secure place (e.g., an e-commerce merchant that has a good reputation), theft on the remote side is still possible. How is this possible? Suppose you are calling somebody using the phone and the person on the other side answers you. If the voice of the respondent sounds similar to the one you expect, it is possible that you will not perform any other authentication and share some secrets.

The situation regarding network servers is not much better. When the user expects to see an often-used web page, it is relatively easy to create a similar-looking page on a fraudulent server and attempt to direct the user to that server. Chances are that the user will share his login/password information or even credit card information with the unknown thief. So, the first problem of network security is the identification of the remote side.

Even when the remote side can be identified for sure, we are still not in safety. As we know, information doesn't reach the remote side directly. Instead it travels through 5-20 (on average) network nodes to get to the server. Each of these nodes is technically capable of capturing, recording, or even modifying the information being sent. Of course, this is a serious threat to data security.

This second problem is tolerance to so-called man-in-the-middle attacks. There are many types of man-in-the-middle attacks; they differ in the goal of their initiator and in the way they are carried out.

So the two main tasks of any network security solution are to do the following:

1. Provide correct identification of the remote side in the network conversation.
2. Prevent third parties that have the opportunity to access the network over which the data is transmitted from accessing the data being sent.

The most obvious way is to encrypt the data in the way that is known to both sides of the network communication session, but not known to other parties. A strong encryption algorithm would work fine, but only if both sides knew the password (some data sequence) that is used during encryption. Such an approach can be used in some cases, but certainly it is not usable on the internet, where thousands of client devices connect to servers for information and services. Of course, the server could transfer the password to the client during the conversation, but the obvious drawback is that the third party in the middle can get the password too, effectively making such "security" useless.

So it is necessary to utilize some more advanced scheme, which lets the client and the server securely exchange passwords and still minimize the chance for attack.

Protocols

Nowadays there are several widely used schemes available. They are SSH (Secure Shell) and SSL (Secure Socket Layer/Transport Level Security). Both protocols work on the transport network level ("above" the TCP protocol) and utilize similar schemes. SSL is more widely used because of its adoption for secure WWW data transfer.

Both protocols provide transparent security; this allows the use of standard internet protocols over SSL or SSH.

Certificates

As mentioned, only a properly authenticated server (and, in some cases, client) can be treated as secure. SSL utilizes certificates to authenticate the parties and also to encrypt the data being transferred. You will find more information about certificates in Introduction to Certificates.

In brief, the certificate is a secure replacement for the common username/password pair, with enhanced functionality and strengthened security. By utilizing asynchronous algorithms, the certificate approach provides more features than other authentication systems; for example, certificates have a predefined lifetime and range of use.

Also, there exist standard approaches to centralized certificate management, backup, and recovery.

Applications

The most well-known application for the SSL protocol is securing commercial internet communications. Most commercial websites offer an option for (or even force) the use of SSL, which is used for the HTTPS protocol. This is however not the only protocol to use SSL. Actually, most TCP-based protocols (like POP3 and IMAP for mail, NNTP for news, etc.) can work over SSL. SSH is also used to provide security for the FTP and shell protocols.

SSL is useful in public operations; due to its perfect authentication capabilities, SSL is indispensable in distributed and n-tier applications, in providing authorization in heterogeneous environments, and in securing data transactions and remote operation control.

For example, certificates and SSL are the optimal way of controlling the access of multiple users to a database. Certificates in this scenario provide the following features:

• Authenticate the user.
• Check whether the user is authorized to access the resource.
• Apply the necessary access restrictions.
• Encrypt the user's private information.
• Enable logging and security audits.
• Unify security management procedures.

How SSL Works

SSL provides identification of the server, optional identification of the client, and also encryption and compression of the data being transferred. Below are the key terms used in SSL:

• Cipher suite: A set of encryption, key exchange, and digest (hash) algorithms, which are used together during the SSL session to provide data security.
• Asymmetric encryption algorithm: A cryptographic algorithm based on a pair of keys, one of which is private (secret) and another one is public (known to everybody). Asymmetric algorithms are typically used for one-way encryption, digital signing, and key exchange operations.
• Symmetric encryption algorithm: A cryptographic encryption algorithm based on one secret key, shared secretly by both parties.
• Random data: Here, arbitrary, randomly chosen data that is used to create secret values shared by the parties for use as secret key material.
• Certificates: Digitally signed data structures used for the identification of the parties by binding cryptographic keys to physical or legal entities. See Introduction to Certificates for more information on certificates, their creation, use, and validation.

Once a socket connection has been established, the SSL handshake is initiated. The handshake lets the parties define the version of the SSL protocol to use, select cipher suites and a compression method, optionally authenticate each other, and negotiate a shared encryption key.

1. The handshake is started by the client, which sends an SSL greeting packet to the server. The client's greeting packet contains:


• Client version: The highest version of the SSL/TLS protocol supported by the client
• Random data: This consists of the date/time stamp and some random bytes
• Session ID (can be omitted if a new session is started). SecureBlackbox supports session management.
• A list of cipher suites supported by the client.
• A list of compression algorithms supported by the client.
2. The server sends either a greeting packet or an error message if it cannot negotiate the encryption parameters provided by the client. The handshake packet sent by the server contains:
• Server version: The version of the SSL/TLS protocol that was selected by the server. This is normally the highest version supported by both the client and the server.
• A random data block, chosen independently from the client’s random data.
• A Session ID. If the client specified a valid session ID in its greeting message and this ID is recognized by the server (and is valid, has not expired, with no compromise of its security, etc.), the session ID is returned back to the client in the server’s greeting packet. Otherwise, the server creates a new logical session and includes the new ID in its greeting packet instead.
• A cipher suite identifier indicating the cipher suite that was selected by the server from the list of the cipher suites supplied by the client. This is normally the strongest cipher suite supported by both the client and the server. Note that different cipher suites require different conditions to be met to be usable -- for instance, the DHE-DSS-3DES-SHA cipher suite can only be used together with a server-side certificate that carries a DSS public key, so a server only having an RSA certificate will not be able to use this cipher suite.
• Compression method: The ID of the compression type selected by the server from the list of compression types supported by the client.

3. After sending the greeting message, the server sends its certificate or, in some cases, a chain of certificates. The certificate is always sent to the client unless an anonymous Diffie-Hellman key exchange algorithm is used.

   Among other things, typically a server IP address or a domain name, the certificate contains a public key, which is later used by the client to authenticate the server’s key exchange packet or to encrypt a so-called pre-master-secret value (a random value computed by the client), depending on the cipher suite. The client validates the certificate and either goes on with the negotiation if the server’s identity was verified successfully or terminates the connection if it was not.

4. If no certificate was provided by the server (the anonymous DH case), or if the negotiated cipher suite rules that a different public key should be used for agreeing on the shared key, the server additionally sends a server key exchange packet.

   In most cases, this packet contains a public value of an asymmetric algorithm (such as DH or ECDH) signed with the server’s private key. Upon receiving the packet, the client verifies the integrity of the public value by using the public key from the server’s certificate, and if the signature proves to be OK, proceeds with the negotiation.

5. The server may optionally request that the client authenticate themselves with their certificate by sending a "certificate request" packet.
6. The server completes a batch of greeting messages with a "hello end" packet and waits for the client to proceed with the next stage of negotiation.
7. If the client was asked for a certificate, it sends its certificate to the server. Alternatively, the client may send a "no certificate" message, indicating that it does not have a certificate suitable for authentication. In the latter case, the server has an option of aborting the handshake.
8. The client sends its key exchange packet to the server. Depending on the negotiated cipher suite, the packet contains the client’s public value of an asymmetric algorithm, or a pre-master-secret value encrypted with the server’s public key.
9. If the client sent its certificate on step 7, it completes the batch by sending a "certificate verify" message. This message contains a client’s digital signature over the handshake data to prove the fact of possession of the private key.
10. The client combines its private key with information contained in the server certificate and server key exchange packet to derive the shared secrets. After that it sends a "change cipher spec" packet to indicate that the newly negotiated encryption parameters have come into force. This packet is immediately followed by the ‘handshake finished’ message, which is protected with the new encryption parameters. The client is now able to send and receive application data protected with the negotiated keys.
11. The server combines its private key with information contained in the client key exchange packet to derive the shared secrets. After that it sends a ‘change cipher spec’ packet to indicate that the newly negotiated encryption parameters have come into force. This packet is immediately followed by the ‘handshake finished’ message, which is protected with the new encryption parameters. The server is now able to send and receive application data protected with the negotiated keys.
12. Application data is transferred in both directions. During the transfer, either party may initiate a rehandshake procedure to refresh the key material.
13. Once the data transfer is completed, one of the parties initiates a session shutdown by sending a ‘close notify’ message to the other. The other party replies with its own ‘close notify’ message, and both parties shut down the network connection. Both parties may choose to preserve the session ID to be able to resume the closed session in the future.

SSL Sessions

As the generation of the keys is quite a slow operation, the SSL protocol supports sessions. A session is defined as a set of information necessary for the reuse of already exchanged information for another SSL-secured data exchange. Session data includes the cipher suites and keys used. Support for sessions in your application can increase the efficiency of the SSL protocol if more than one connection is opened from the client to the server.

Only a properly closed session can be resumed.

Conclusions

Taking into account the growing value of information in distributed systems, each developer must pay special attention to the services that are provided by SSL and certificates.