Introduction to SSL

 

1. 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: On the remote side itself 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 Provide correct identification of the remote side in network conversation 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. 2. 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 transport network level ("above" TCP protocol) and utilize similar schemes. SSL is more widely used because of it's adoption for secure WWW data transfer. Both protocols provide transparent security; this allows use of standard Internet protocols over SSL or SSH. 3. Certificates 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. 4. Applications 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 5. 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 - 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 another 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 for identification of 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, SSL handshake should be carried. Handshake lets the parties to 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. 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. Supported cipher suites that define, which encryption algorithms are supported by the client Supported compression. Current protocol implementations don't use this field The server sends either a greeting packet or error message. 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 was found by the server (and is valid, i.e. not expired, security was not compromised etc.), the value supplied by the client is put to 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 Right after the server greeting message the server sends a certificate or a sequence of certificates. Certificate is sent to the client always unless anonymous Diffie-Hellman algorithm is used. Among other things certificate contains a public key, which is later used by the client to sign a session key. If there was no certificate sent or the certificate is used only for signing the data (not for encryption), the server sends to the client a so-called server key exchange packet. The values sent depend on the cipher suite, which was selected by the server. Depending on the cipher suite, the server may request a certificate from the client. Server sends the client a greeting completion message and expects the response from the client. 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. Client sends a client key exchange packet to the server. This packet contains information necessary for encryption of the data with symmetric algorithm. Certificate validation packet is sent to the server. This packet is used by the server to identify the client. The client sends algorithm specification change packet followed by completion message. The completion message is encrypted using parameters, which were defined during handshake. After completion message is sent the client can start sending data. Server sends algorithm specification change packet followed by completion message to the client. Completion message is also encrypted using parameters, which were defined during handshake. After completion message is sent the server can start sending data. Data transfer follows. After all data is transferred, one of the sides sends the close_notify message to the other side. Other side replies with it's own close_notify message and closes connection. 6. 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. Conclusions 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.