I'm trying to wrap my head around the Application Data record that carries secured traffic. I understand TLS/SSL is a "authenticate-then-encrypt" protocol, which means an HMAC is calculated over the Plain text, and the resulting digest is appended to the message. Finally, the whole packet is encrypted using the negotiated cipher.

I also know that the first three fields of an "Application Data" record are:

  • Content Type (0x17 to indicate Application Data)
  • Protocol Version (0x0301 for TLS1.0, et al)
  • Record Length (length in Bytes of encrypted content)

Given the following (simplified) "Data"

GET /index.html HTTP/1.1
Host: helpme.com

What would the resulting encrypted packet look like, and what parts would be encrypted, and what part would be Hashed?

Please use the following (again, simplified) illustration to make answering this easier:

01   |  ContentType  |  ProtocolVersion  |  RecordLength  |
02    GET /index.html HTTP/1.1
03    Host: helpme.com
04   |  HMAC  |  Padding  |

My best guest from reading through RFC 5246:

Lines 01-03 are included in HMAC
Lines 02-04 are included in Encryption

Any help is appreciated.

  • For TLS 1.0, this is correct. In TLS 1.1 (and later) you will also get an explicit IV between line 01 and 02 if a CBC mode cipher is negotiated. In TLS 1.2 an AEAD cipher might be negotiated, which means line 04 will depend on the cipher. Mar 29, 2014 at 8:41
  • Could you tell me where in the RFC the changes to line 4 if an AEAD cipher is negotiated exist? I'd like to do some further reading. As for the IV, since a CBC cipher repeatedly performs an encryption computation using data from the last computation to 'seed' the current one, the IV simply provides a 'starting point' for that first computation. Would that suffice as a layman's explanation of why the IV is needed?
    – Eddie
    Mar 29, 2014 at 14:21
  • AEAD datatracker.ietf.org/doc/rfc5246/?include_text=1 section Your IV explanation seems adequate enough, but it depends on the context of course. Mar 29, 2014 at 14:28
  • Henrick, would you care to post an answer so I can mark yours as the right answer? I can't do that to a comment. (even if its just a copy and paste from your comment, so you can at least get the credit).
    – Eddie
    Apr 3, 2014 at 15:01

1 Answer 1



In the case of HTTPS, any data that would have been sent had the connection not been secure, will be sent as encrypted application data. Additionally, for historical reasons, the MAC and Padding will also be encrypted. In SSL 3.0 and TLS 1.0, this means that the layout will be as follows:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (encrypted)    GET /index.html HTTP/1.1
03 (encrypted)    Host: helpme.com
04 (encrypted)    |  MAC  |  Padding  |

Note that, strictly speaking, the MAC is only a HMAC in TLS 1.0 and up. In SSL 3.0 it was a special mode used only in this protocol.


Starting with TLS 1.1, if a block cipher in CBC mode has been negotiated, an explicit IV will be inserted at the start of the encrypted data:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02                IV
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com
05 (encrypted)    |  HMAC  |  Padding  |

The IV is there to make the cipher text unpredictable and less susceptible to certain cryptographic attacks. Implementations might treat it differently both at encryption and at decryption. Some implementations might generate it from random, while others might generate it as the cipher text of the last block of the previous fragment XORed with a constant value. Conversely, at decryption, implementations might treat it as either an independent field or as the first block of cipher text (and discard the corresponding decrypted block before outputting the decrypted plain text fragment, just as the HMAC and Padding is discarded).

Starting with TLS 1.2, an AEAD cipher might be negotiated, which means that the MAC mechanism is integrated into the cipher mode and no HMAC will be required. In this case the layout will be as follows:

01 (plain)        |  ContentType  |  ProtocolVersion  |  RecordLength  |
02 (plain)        Nonce 
03 (encrypted)    GET /index.html HTTP/1.1
04 (encrypted)    Host: helpme.com

Note that the length of the cipher text corresponding to field 03 and 04 will be longer than the length of the corresponding plain text. The exact layout will depend on the details of the AEAD cipher mode. Normally, it will just end with a MAC.

Now, to complicate things further, in all protocol versions and cipher modes the MAC will be calculated over data that differs from both the plain text (optionally compressed) fragment and from the encrypted fragment. In particular, the RecordLength field will have the plain text / compressed value (not the encrypted value) and a Sequence Number will be inserted to prevent replay attacks. The MAC itself is obviously not included in the data the MAC is calculated over, and neither is the padding. The last part, the MAC not being calculated over the padding, is the reason some of the attacks against SSL/TLS are possible.


HTTPS is an instance of Implicit SSL, which roughly means that SSL/TLS will be the outer most protocol layer of the connection. The first thing to be sent over the connection is a SSL/TLS handshake, and all application data will be sent encrypted. HTTPS will always be Implicit SSL.

By contrast, Explicit TLS means that SSL/TLS will be negotiated explicitly as part of the underlying application protocol. This is common e.g. in the case of application protocols such as SMTP, POP3 and FTP. When Explicit TLS is used, the first data sent over the connection will be the opening protocol messages of the application protocol.

Note that the "SSL" and "TLS" part of Implicit SSL and Explicit TLS is a misnomer, in the sense that it is perfectly possible for a client and server to negotiate TLS 1.0 or higher over an Implicit SSL connection, and conversely to negotiate SSL 3.0 over an Explicit TLS connection.


To complicate things further, it should be remembered that encrypting something for someone, doesn't guarantee that entity will be the only one reading the encrypted data, because there is never possible to prevent the recipient from simply forwarding the decrypted plain text to a third party. This is in particular important in the case of SSL/TLS, because authentication normally only goes one way (the server authenticates itself to the client) and a special handshake is required to authenticate the client to the server.

This attack demonstrates how this fact can be exploited with current protocols and some cryptographic primitives. There are however a few things that can be done to prevent this from happening. For instance, the following rules will prevent the attack, but might break compatibility with existing implementations:

  1. When the server requires client authentication, either: a. Send a hello_request first thing after the initial handshake has finished and request client authentication for this second handshake, or b. implement the application protocol (or the application using the application protocol) in such way that no data sent prior to client authentication will be treated as authenticated by the client, e.g. by internally starting a completely new application session and having the client resend anything it sent prior to the authenticated handshake.
  2. When a connection has been initiated with a resumption (abbreviated handshake) treat any hello_request or client_hello messages over that connection as errors.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .