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.