Introduction to SSL


The problem

Everybody uses 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 personal user's information, commercial or technical data (including commercial secrets and intellectual property), or even security and military information. Leaking of such information can stay undiscovered for months, if not year, doing damage to people that 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, i.e. on the way from the user's computer to remote side.

If the remote side is supposed to be a secure place (i.e. e-commerce merchant which has 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 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? However this is quote a common situation in the real life.

Situation regarding network servers is not better. When the user expects to see often-used web page, it is relatively easy to create a similarly 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 in safety. As we know, information doesn't reach the remote side directly. Instead it travels through 5-20 (in 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 network conversation
  2. Prevent third parties that have 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. Strong encryption algorithm would work fine: but only if both sides know the password (some data sequence), which is used during encryption. Such approach can be used in some cases, but certainly it is not usable in 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 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 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 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 use of standard Internet protocols over SSL or SSH.


As mentioned, only 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 on SecureBlackbox site.

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

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


The most well known application for SSL protocol is securing commercial Internet communications. Most of 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 (like POP3 and IMAP for mail, NNTP for news etc.) 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 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 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.

SSL description uses the following terms:

  • Cipher suite - a set of encryption, key exchange and digest (hash) algorithms, which are used together during 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) an 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 identification of the parties by binding cryptographic keys to physical or legal entities. There's a separate article about certificates, their creation, use and validation, in the article about Certificates.

Once a socket connection is established, SSL handshake is initiated. Handshake lets the parties define the version of 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 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 date/time stamp and some random bytes
    • Session ID (can be omitted if 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 is not happy with the encryption parameters provided by the client. The handshake packet sent by the server contains:

    • A server version - the version of 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, not expired, its security has not been compromised 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 to 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, 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 compression type selected by the server from the list of compression types supported by the client.

  3. Right 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, 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, 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 (anonymous DH case), or if the negotiated cipher suite rules that a different public key should be used for agreeing 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 the client to 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 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 (random value computed by the client) encrypted with the server’s public key.

  9. If the client had 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 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 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 are transferred in both directions. During the transfer, either party may initiate a re-handshake procedure to refresh the key material.

  13. Once the data transfer is completed, one of the parties initiates 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 future.

SSL sessions

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

Only 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. And SecureBlackbox can be a good assistant in achieving ultimate security in your solutions.

Ready to get started?

Learn more about SecureBlackbox or download a free trial.

Download Now