An Introduction to SSL

Environment: Platform independent

The Problem

Everybody uses a network to transfer data; this is obvious. Less obvious is the fact that the data has value (and cost), and so it is a subject to theft.

Types of information that are stolen include a user’s personal information, commercial or technical data (including commercial secrets and intellectual property), or even security and military information. Leaking such information can stay undiscovered for months, if not years, doing damage to people who sent information, and also to third parties.

Information theft is possible in two places:

  1. On the remote side itself.
  2. In the middle of network conversation; in other words, on the way from the user’s computer to the remote side.

If the remote side is supposed to be a secure place (as in an e-commerce merchant with a good reputation), theft is still possible. How can this happen? Suppose you are calling somebody using the phone and the person on 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 other authentication and can possibly tell him some secrets. Sounds strange? This is quote a common situation in real life.

The situation regarding network servers is no better. When the user expects to see an often-used Web page, it is relatively easy to create a similar-looking page on the other (“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 info with the unknown thief. So, the first problem with network security is remote side identification.

Even when the remote side can be identified for sure, we are still not safe. 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 to capture, record, or even modify the information being sent. Of course, this is a serious threat to data security. The 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.

So, two main tasks of any network security solution is to:

  1. Provide correct identification of the remote side in the network conversation.
  2. Prevent third parties that have a possibility 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 network communication session, but is not known to other parties. A strong encryption algorithm would work fine, but only if both sides know the password (some data sequence), which 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 that lets the client and the server securely exchange the passwords and still minimize the chance for attack.


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” 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.


As mentioned, only a properly authenticated server (and, in some cases, the 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 on the SecureBlackbox site.

Briefly speaking, the certificate is a secure replacement for a 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.


The best-known application for SSL protocol is securing commercial Internet communications. Most commercial Web sites offer an option (or even force) for use of SSL, which is used for HTTPS protocol. This is, however, not the only protocol to use SSL. Actually, most TCP-based protocols (such as POP3 and IMAP for mail, NNTP for news, and so forth) can work over SSL. SSH is also used to provide security for 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 people to the 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 private user’s information
  • Ease logging and security audits
  • Unify security management procedures

How SSL Works

SSL provides identification of the server, optional identification of the client, and also provides encryption and compression to the data being transferred.

An SSL description uses the following terms:

  • Cipher suite—set of encryption and digest (hash) algorithms, which are used together during SSL session.
  • Asymmetric encryption algorithm—encryption algorithm, based on a pair of keys, one of which is private (secret) and the other one is public (known to everybody)
  • Symmetric encryption algorithm—encryption algorithm that uses one secret key.
  • Random data—(here) some data that is used to create common secret values used during SSL session.
  • Certificates—blocks of data, used to identify the parties and for encryption information. There’s a separate article about certificates, their creation, use, and validation in the article about Certificates.

When the socket connection is established, an SSL handshake should be carried out. The handshake lets the parties define the version of SSL protocol they use, select cipher suites and (optionally) compression methods, (optionally) authenticate each other, and use asymmetric encryption algorithms to exchange random data.

  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 SSL/TLS protocol supported by the client
    • Random data, which consists of a date/time stamp and some random bytes
    • Session ID (can be omitted if new session is started)—SecureBlackbox supports session management
    • Supported cipher suites that define which encryption algorithms are supported by the client
    • Supported compression. Current protocol implementations don’t use this field
  2. The server sends either a greeting packet or error message. A handshake packet sent by the server contains:
    • Server version—the version of SSL/TLS that was selected for use by the server
    • Random data block, independent from client random data
    • Session ID. If the client-specified session ID and this ID were found by the server (and is valid—not expired, security was not compromised, and so forth), the value supplied by the client is put to the server greeting packet. Otherwise, the server sends the ID of the newly created session.
    • Cipher suite field—the cipher suite that was selected by the server from the list of supported cipher suites, supplied by the client
    • Compression method—the ID of compression type selected by the server from the list of supported compression types, supplied by the client
  3. Right after the server greeting message, the server sends a certificate or a sequence of certificates. A certificate is sent to the client always unless an anonymous Diffie-Hellman algorithm is used. Among other things, the certificate contains a public key, which is later used by the client to sign a session key.
  4. If there was no certificate sent or the certificate is used only for signing the data (not for encryption), the server sends the client a so-called server key exchange packet. The values sent depend on the cipher suite, which was selected by the server.
  5. Depending on the cipher suite, the server may request a certificate from the client.
  6. The server sends the client a greeting completion message and expects the response from the client.
  7. If the client was asked for a certificate, it sends the requested certificate to the server. It can also sent a “no certificate” message; but, in this case, the server may stop the handshake.
  8. The client sends a client key exchange packet to the server. This packet contains information necessary to encrypt the data with a symmetric algorithm.
  9. A certificate validation packet is sent to the server. This packet is used by the server to identify the client.
  10. The client sends an algorithm-specification change packet, followed by a completion message. The completion message is encrypted using parameters, which were defined during the handshake. After completion, the message is sent so that the client can start sending data.
  11. The server sends an algorithm-specification change packet, followed by a completion message to the client. The completion message is also encrypted using parameters, which were defined during the handshake. After completion, the message is sent so that the server can start sending data.
  12. Data transfer follows.
  13. After all data is transferred, one of the sides sends the close_notify message to the other side. The other side replies with its own close_notify message and closes the connection.

SSL Sessions

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

Only a properly closed session can be resumed.


Taking into account the growing value of information in distributed systems, each developer must pay special attention to the services, which are provided by SSL and certificates. SecureBlackbox can be a good assistant in achieving ultimate security in your solutions.


Download demo project -723 Kb

More by Author

Must Read