The Secure Sockets Layer, abbreviated by SSL, was developed by Netscape to provide a secure protocol for exchanging data on a client-server basis. Secure in this context means that you want to ensure
That means: you neither want your data to be read by anyone else than the people you intend to, nor do you want people to pretend that they are intended to read your data.
SSL is a way of negotiating the right tools to do this. These tools are
The first make sure that you achieve authentication, the latter provide confidentiality for your data. Note that these features are not part of SSL, SSL is just used to negotiate which of them will be used for secure data exchange.
Transport Layer Security (TLS) serves the same purpose, but on a different level. It was introduced by the IPSEC working group of the IETF, to provide the same security features for the internet transport layer. Since each technology does the same on a different level, it is not necessary to use both of them at the same time.
So how does SSL work? Normally, in two phases: a handshake phase and a data exchange phase. Though it should not happen in regular communication, a third stage is also possible: if client or server detect something which can cause a lack in security, or if they were not able to agree on a common set of security options to use, there will be an alert. This either causes communication to be canceled, in case the alert was fatal, or communication goes on with both sides knowing that there is a security threat. At this moment, this is only done in case there has been a problem with either the server or the client's certificate.
But let us deal with the first phase of SSL communication now, which is where security options are negotiated, the initialisation phase of the protocol.
SSL uses a special protocol to negotiate security options and exchange keys. It impairs a rather short exchange of two data structures, leaving no big space for graceful degradation. If one of the structures exchanged describes a security threat, then the other side will likely immediately terminate the connection. There won't be any further steps in the handshake protocol which could handle exceptional events.
The handshake itself happens in three stages, which form a "bootstrapping" process to establish a secure channel. Here we go:
Client and server exchange two messages in which they tell each other which cryptography and compression features they support, and which SSL version they are going to use. They also exchange "pseudo"-nounces to avoid replay-attacks, and a session ID.
The server decides upon the list of cryptography and compression algorithms sent by the client wether to continue or cancel the session. There must be at least one match in both lists, otherwise the session will fail. The cipher combination which took the highest place in the client's list will be used for future communication.
The nounces are not really random (but fresh!), as this is usual on current computing systems.
The session ID can be used to recover a previously used session. If the client wants to reuse a session already established, it sends its ID. The server will then recover this session from its cache. If the client wants to establish a new session, it sends a 0 instead of a session ID.
The next stage of handshake involves authentication and key exchange between both parties.
Authentication and key exchange are both done by sending certificates, as long as both sides can provide them. If not, it is possible to transfer public keys without transferring certificates. This will ensure that the client will end up with a public key in each case, wether it got it from the server's certificate or wether it got it directly. It will use this public key to encrypt a premaster secret and send it to the server. The premaster secret is used to generate a master secret which in turn will be used to generate symmetric keys for data exchange.
Depending on if there were certificates send, and depending on the type of these certificates, both sides may be able to verify eachother's identity by checking the validity of these certificates. This validity check is the only part of SSL which may fail without SSL aborting the connection immediately. This is understandable, since otherwise, many people simply wouldn't be able to set up a secure website! Consider the school information system, and other web sites which have to sign their own certificates because they cannot afford a VeriSign™ signature.
Let's have a look at the handshake's final stage.
The change cipher spec message is simply a byte with value 1 which tells the other side to set up the cipher suite agreed on in the first stage (one for data encryption and one for subsequent key exchanges). The notification at the end marks the completion of the handshake. It is already encrypted using the agreed-on algorithms, and it contains a message authentication code derived from the preceding handshake.
Client and Server have now authenticated eachother's identity, and they have set up an encrypted communication channel. Now will follow the data exchange phase of the SSL protocol, which itself involves several stages.
It's going to get a little bit more technical now. If you want, you can skip some parts, but please read the MAC part, since it is an important security feature about SSL.
SSL works as an interface between the application and the transport network layers. On the sending side, it receives data from the application, tranforms it through several steps and then passes it on to the transport layer, which is usually implemented by the TCP protocol. The receiving side just reverses the whole procedure.
Data is passed to TCP in records of a size up to 18 kB. That means, data to send, which can have an arbritrary length, has to be divided into manageable pieces before the protocol starts operating on it. These pieces should be small enough such that the final record will not be bigger than 18 kB after it has past the SSL. Therefore, as the first step, data is padded and split into blocks of equal size, which is called fragmentation.
In the next step, the data usually is compressed using the negotiated method. It is also possible to leave the data uncompressed, e.g. if the application already compressed it. Normally one would expect the compressed data to be smaller than the uncompressed data. But this is not always the case, as it may be possible that data had already been compressed to a maximal ratio before. In this case, SSL ensures that the compressed block is not more than 1024 bytes bigger than the uncompressed one. (The final SSL record would possibly become bigger than 18 kB otherwise.)
After compression, SSL appends a message authentication code (MAC) to the compressed data. This achieves SSL's goal to authenticate the data. The MAC is generated using a double iteration of a collision-resistant hash function. The authentication is done by concatenating a secret key to the first iteration of the hash function before passing it to the second iteration. It generally looks like this:
MAC(data) = hash( secret_key + hash( secret_key + data + time_stamp ) )
The + stands for concatenation. As a hash function, SSL can use MD5 or SHA-1, depending on what client and server agreed on in the initialisation phase.
Next follows the encryption. It is done via one of six ciphers which is selected at the initialisation phase. The way data and its MAC are encrypted strongly affects how secure the SSL message will be afterwards. If you (or your application) choose 40-bit DES for example, you don't have as much security as with a 56-bit DES or a Triple DES.
The next phase is the addition of headers. As it is the case with any network layer, SSL needs to add its own specific information to every data unit is send, and thus, a 40-bit informational header is appended in front of every SSL record. This header gives information about the content included in this record, as well as information about the SSL version used, and 16 bits which tell you how long the record's content will be.
If this is done, the record is passed to the TCP layer and then sent over the network. Once received, the whole procedure described above will happen again, but reversed. The SSL on the other side of the internet will remove the header, decrypt the record (using the same key), check the MAC, and if this was correct, decompress the message and finally pass it on to the application.
As already said, SSL is not the way of securing data, it is a way of negotiating the right security tools. This means SSLs security not only depends on the actual SSL specification or implementation, but also on the encryption and authentication algorithms in use. Several attacks are proposed in [Wag], some of which I want to introduce here. Most of them are pretty theoretical and do not succeed. (Do they prove that SSL itself is secure?) Other attacks succeed, in theory. They have not been implemented. One of them seems to be implementable, but it reveals a threat against privacy, opposed to confidentiality and authentication, which are SSL's primary aims.
As we saw before, when finishing the handshake, client and server exchange change cipher spec messages to signal the other side to switch their security options. Both sides will from then on only communicate using the security features agreed on. But: before the change cipher spec message is sent by each side, a man in the middle can already send a "finished" notification, which will cause both sides to begin confidential communication without changing to their agreed-on cipher specification before. This is possible since there is no check in SSL, wether a change cipher spec has been sent before the finished message in question. Also the change cipher spec message is not authenticated like all the other handshake data (for some practical reasons).
So it is pretty easy for Mallory to get both sides to exchange their confidential information unencrypted, isn't it? It is not this easy. Since, without a change cipher spec, the server believes that no encryption will be used, it also expects the client to do so. This means, it expects an unencrypted "finished" notification from the client. The client on the other hand, will send an encrypted notification, which Mallory would have to decrypt, before sending it to the server. It would do so, because, at the time when Mallory intercepted its change cipher spec, it already would have received the servers public key. And Mallory can't decrypt the "finished" notification because it doesn't have the server's private key.
So there is no way for Mallory to force client and server to use no encryption at all (in order to read messages). But there is still a special case, in which she may be able to forge messages. If client and server agree on no encryption at all, the crucial "finished" notification which the server expects to be unencrypted, would also be sent unencrypted by the client. So Mallory would not have to decrypt this "finished" notification. She would simply have to delete the message authentication part from this notification and hand it through to the server. Why delete the MAC? Because the server didn't receive a change cipher spec, and so it doesn't expect incoming messages to be authenticated. The client on the other side will obiously (according to the specification; see also [Wag]) already use message authentication and encryption. Nevertheless, once the handshake is done, Mallory will be able to change incoming messages from the client and to make the server believe they came from the client.
Closely related to this is the idea of forcing client and server to use two different key-exchange algorithms which the attacker specifies. It presumes that it is possible to perform a ciphersuite rollback attack.
The attack works as follows: The attacker forces the server into using ephemeral Diffie-Hellman key exchange and the client into using ephemeral RSA key exchange. This leads to a situation where the client interprets Diffie-Hellman parameters as exponents and modulus' for RSA encryption. Because of the data structures used, the RSA modulus received by the client will be a prime number, the Diffie-Hellman prime modulus.Recall how RSA works:, where e is the public encryption key and n is a 1024 bit number. Normally, it is not possible to compute in mod n as if it where n. But if n is prime, it holds that , meaning that we can compute the root of a value as well in "mod n" number space and yield the same value as in "n" space. (See "Elements of Number Theory", Euklid's Theorem in [Pie])
Back to the attack: After performing the ciphersuite rollback, the attacker has to intercept the Diffie-Hellman parameters the server sends to the client in the server's authentication phase. This will be the pair (g, p), where p is the DH prime modulus. The attacker now has to wait for the client's pre_master_secret which will be encoded with RSA using these parameters. Because of what we saw above, all he has to do is to take the g-th root of this value. He now knows the pre_master_secret and can derive everything he needs to decrypt future SSL communication between client and server.
This attack seems pretty tough. But the problem lies elsewhere: to implement a ciphersuite rollback attack. As we saw already above, they are not possible anymore since SSL version 3.0.
The next attack is the one which I find most promising, since it is easily implementable. It seems to be a serious threat, if you consider also privacy as much as confidentiality and authentication.
Traffic analyis is a passive attack which tries to identify data by analysing network traffic. Considering SSL, this means to act as a man-in-the-middle and monitoring activity between server and client. Alltough you may not be able to decrypt the data packets send, you are still able to determine its size, and also its source and its destination, since they are part of the underlying transport layer. Tools for hijacking TCP connections or IP spoofing are available, and get easier and easier to use. So what do you do? Suppose you want to find out about which webpages a given user visits. You take a monitoring program and intercept TCP data between client and server. You intercept data which goes out at port 80 on the client, knowing that those will be URL requests from the client's browser. You also intercept the server's response, especially its size. You employ web mining technology like the one search engines like Google use, to find out which URLs of the intercepted length on the server return web pages of the intercepted size.
One has to admit, that not everyone can use this technology, since it takes a reasonable amount of memory and computation power. But one also has to admit that monitoring other's people web traffic is already an intrusion into someone's privacy, retrieving information about visited webpages is even a bigger one. The fact that SSL doesn't deal with it doesn't make SSL better. A reason for this is certainly that privacy simply was no general aim when the standard was developed. But consider how easy it would be to change this: All an implementation would have to do is to add padding bits of a random length into the content of an SSL record. For block ciphers, which can be used on top of datagrams, this is already done. For stream ciphers, as they are used on top of stream connections such as TCP (to send web traffic), it is not. So some change in the SSL specification would be desirable. By the way, attacks based on padding, like the one described in the previous section, could be avoided easily by doing that.
[Vau] describes an attack against the padding scheme used by CBC (cipher block chaining) mode which is used to apply fixed-length ciphers on inputs of variable length. CBC basically works by padding the input and dividing it into blocks of the same length. The crucial thing about it is the chaining, namely that the encryption of block n depends on the encrypted block n-1. Vaudenay's attack exploits the fact that servers send back error messages if decryption of a cipher text did not yield the right padding. In case of an SSL server, which always terminates the connection, if a malformed message of any kind was received, Vaudenay states that the last n bytes of a message can be revealed with a probability of 1/256n using his method. That is an average case time complexity of O(256n), a best case complexity of O(1), and a worst case complexity of O(256n) to decode the last n bytes. That means the success of this method mainly depends on if you are lucky or not.
But there is also some hope. TLS servers do hold the connection if they receive a cipher text whose decryption yields incorrect padding. For those cases [Vau] offers a method to decrypt a message with a time complexity of O(NbW), where N is the message length, b is the block size and W is the number of possible values a unit of data (usually a byte) can take. The problem with this is that, TLS does not always pad to the next multiple of the block size, but sometimes also to the multiple after the next multiple, or the r-th multiple after the next multiple, in other words, to (n + r)b, where r is a random natural number and the message spans n blocks. In order for the linear-time method to work, you need to know how many bytes have been padded, which you don't, since they have been padded randomly.
But there is a way of finding out the padding length of a message. It works the following way. The padding in CBC mode has the form . Since the values mi and the ps are stored as byte values, p, which is the padding length, must be smaller than 256. It is possible to find out if the padding length of plain text was n by modifiying its cipher text in a specific way and sending it to the server (see [Vau]). If the server accepts the message, padding length was n, if not, it wasn't. In the worst case, you have to try 256 values for n.
Thus, you can decrypt a CBC-encoded TLS packet in linear time. But note that you have to constantly query the server. If there is any flood protection or any check against brute force attacks, the attack will not work.
Attacking SSL is not very easy. As I started with the topic, it was pretty straight forward, since all you have to care about is the specification itself. But as you move into it, you realize that computer security has made great advances since the first hackers tried to break into computers using brute force attacks.
Among the proposed attacks against SSL which I read about in the papers, there was none which could efficiently use the protocols weaknesses to decrypt data. The situation is different for TLS, since TLS can be attacked via the attack against CBC padding. But this does not give a huge reason to worry: If it would be possible to crack SSL, a lot of real world problems would arise since it is already used in a wide field of applications: online banking and shopping, secure web-mail or the school information system. TLS is not as wide-spread. Its version is 1.0 and there is still some time left to adapt the specification. Additionally, the mentioned attack only applies to block ciphering modes, which are not used by default by both TLS and SSL.
If one of the underlying cryptographies, either symmetric or an assymetric is cracked, SSL will be left empty with no technology left to rely on. But this also would require either a great advance or change in computing technology (quantum computing) or on the other side mathematical results about prime numbers and modulus n computation. This is what I would expect to happen first. (Perhaps both of it will happen at the same time?)
What is for sure, is that the cracking of SSL must almost certainly take place at the time of the handshake, since this is the vulnerable part where unencrypted communication takes place.
[Pie] Josef Pieprzyk, Thomas Hardjono, Jennifer Seberry. Fundamentals of Computer Security. Springer, 2003.
[Wag] David Wagner, Bruce Schneier. Analysis of the SSL 3.0 protocol. http://www.citeseer.net, February 2004
[Vau] Serge Vaudenay. Security Flaws Induced by CBC Padding. http://www.citeseer.net, February 2004