SSL reconstruction with missing part

Question

I know that it's possible to decrypt a sniffed SSL session even when some packets were lost during the capture. I run some tests with wireshark and I saw that it's still able to decrypt part of the session.

I'd like to understand better how this works. My guess is that each SSL record is encrypted separately, therefore losing a piece of a record would make the rest of the record unusable, but losing a record would not affect the decryption of following records. Of course you will end up having a hole int the reconstructed tcp segment, but at least you would be able to move on and decrypt the rest of the capture. My guess is that it's also depends by the cypher used.

Any reference about this would be appreciated. Thanks

Answer 1

SSL data is indeed split in records, each record beginning with a recognizable 5-byte header, and containing up to 16384 bytes worth of application data. What happens when records are missing depends on the negotiated algorithms.

Important note: SSL, by definition, is meant to ensure confidentiality of data. You should not be able, from the outside (i.e. with Wireshark), to decrypt the data, unless you have a privilege access to secret values known to the client or the server (e.g. you have a copy of the server's private key). I assume here that you have, indeed, such an access. From that access, you could obtain the "master secret" (the main shared secret resulting from the handshake) and then the encryption keys used for application data in both directions.

If the encryption algorithm is a block cipher (3DES, AES...) in CBC mode, then each record can be decrypted separately:

• If the protocol version is TLS 1.1 or TLS 1.2, then the IV for the record is also embedded in the record itself, so the complete record data is recoverable.
• If the protocol version is older (SSL 3.0 or TLS 1.0), then the IV is the last encryption block from the previous record; if you missed that previous record, then you don't have the IV... so you won't be able to obtain the first 8 or 16 bytes of the cleartext data of the record you have. The rest of the record contents will still be available.

If the encryption algorithm is RC4, then things are a bit more complex. RC4 is a stream cipher with a running state. The computed encryption keys are, really, the initial state of the algorithm for the first encrypted record. Each subsequent record is encrypted using the internal state that RC4 reached at the end of the previous record. For successful decryption, you must maintain that state in synch with what the client and server do.

It so happens that RC4 works by generating a long stream of key-dependent pseudo-random bytes, which are XORed with the data to encrypt (or decrypt). This means that the internal state reached by RC4 depends on the number of bytes encrypted so far, but not on the values of these bytes. Therefore, the eavesdropper (you) may recover from a "hole" by guessing how many bytes you missed. Decryption over a hole would then look like this: from the last known RC4 internal state (the one reached at the end of the decryption of the last observed record), loop over possible lengths for the missing record(s), and for each of them, work out the RC4 state at the start of the next observed record, and see if that yields a "meaningful decryption". Since SSL records also embed a MAC value, verifying decryption success can be done reliably (since the MAC key comes from the same source as the encryption key, I suppose that you also got that one). The process can be computationally expensive if the hole is big (e.g. if you missed up to one full megabyte of data, then you have to try a million "missed length" values, which will take a few seconds or even minutes of computations if the next record is big and you need to recompute the MAC to know whether decryption is successful).

Compression can make your task harder, too. Usual SSL clients and servers tend not to use compression, because compression leaks information on the compressed data (encryption hides data contents, not data length, and compression makes data length dependent on data contents -- in HTTPS contexts, this is called the CRIME attack). But if they do, then the "normal" compression algorithm for SSL is DEFLATE, which is stateful: the contents of each record will depend on the contents of previous records. Coping with a "hole" will be harder, just like bad sectors on a harddisk can kill a complete compressed archive.

An interesting comparison point is DTLS. This is "TLS for datagrams", i.e. TLS ported to packet-based transport mediums where packets can be lost (in simple terms, DTLS is "TLS over UDP instead of TCP"). Packet loss will imply the same issues than the ones you face, for the normal client and server this time. DTLS works around them by using the following:

• RC4 is not allowed in DTLS.
• The IV is explicit in each record (DTLS reuses the record format from TLS 1.1 and 1.2).
• DTLS is silent on the subject of compression. One has to assume that if compression is used, then the sender shall arrange for stateless compression, which is still possible with DEFLATE but requires a "full flush" at the start of each record (see this on DEFLATE flushes). This decreases compression efficiency, since it prevents (by construction) cross-record data redundancy elimination.

Answer 2

In ssl, all data sent is encapsulated in a ssl record header. Since all data part is encrypted using the same key, so if you are losing some record you still be able decrypt the some part of data and you will get the partial plain text message. There are two things in ssl record header to identify the record type. The record header would be 2bytes or 3bytes long. When the most significant bit set in the record length then there is no padding, so the header length will be 2bytes otherwise it is 3bytes long. When it is of size 3bytes then if second most significant bit is zero then the record being sent is data record. If it is set to one then the record will be security escape. For decrypting the data you need private key. In wireshark you have to set the path for the keys, that will be used by the wireshark to decrypt the cipher.