SHORT ANSWER
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.
SLIGHTLY LONGER ANSWER
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.
IMPLICIT SSL / EXPLICIT TLS
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.
CAN CLIENT AUTHENTICATION AND SESSION RESUMPTION BE TRUSTED?
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:
- 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.
- When a connection has been initiated with a resumption (abbreviated handshake) treat any hello_request or client_hello messages over that connection as errors.
