0

i wanted to understand difference in the "Finished message" when different cipher site selected with encryption and with out encryption.

I am able to find the format of Finished message when the selected cipher suite includes encryption as below.

when the selected cipher suite is :-"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"

Finished message:- Record layer header+Encryption initialization vector+Encrypted data+Handshake header+Verify data

when the selected cipher suite doesn't have encryption involved :-"TLS_ECDH_ECDSA_WITH_NULL_SHA". Finished message:- Record layer header+Handshake header+Verify data

please let me know if my understanding is correct ? if not please let me know how the format looks like.

1

The format of an encrypted record in TLS can depend on the protocol version and (part of) the ciphersuite selected.

Even a null-encryption suite (which only exists through 1.2) still does MAC for message integrity (aka data authentication); for your example this is HMAC-SHA1. See rfc5246 6.2.3.1 (this one is the same in earlier versions); the record consists of: record header 5 bytes specifying handshake, 'content', and MAC (for HMAC-SHA1 20 bytes), where 'content' consists of handshake header 4 bytes specifying finished and verify_data 12 bytes.

The same format is used for stream cipher, except that the content and MAC are (together) encrypted by the configured cipher. However the only stream cipher in TLS was RC4, which is prohibited by rfc 7465 since 2015, so you shouldn't see this format in use. (Some implementations still can support RC4, so you might be able to use it in a test environment.)

For block ciphers using CBC mode in TLS 1.2 and 1.1, see rfc5246 6.2.3.2; the record format is record header followed by an IV and then encryption of the contents (as above) plus HMAC plus padding. In TLS 1.0 (and SSL3) this is different, see rfc2246 6.2.3.2; instead of the IV being chosen and sent with the message, the initial IV (for the first message) is created in the key derivation, and subsequent messages are chained: the last ciphertext block of one message is used as the IV for the next message. Since the prior message can be seen on the wire, this allows a chosen-plaintext attack originally identified by Rogaway in 2002 and popularized by the 'BEAST' attack in 2011, about which this and related Stacks have numerous Qs. Note the order used in standard TLS, MAC-then-encrypt, is less secure with CBC because it allows a padding oracle, which was very severe in SSL3 (POODLE) and is less so in TLS1.0-1.2 (Lucky13). There is a recent option for 1.2 to use Encrypt-then-MAC, see rfc7366 -- but the easier and more common solution in 1.2 (and the only one in 1.3) is to use AEAD instead.

For AEAD ciphers, new in 1.2, see rfc5246 sec 6.2.3.3; this has the record header, 'explicit' part of the nonce (which in turn depends on the ciphersuite), and the authenticated encryption of content. All currently defined authenticated encryption schemes consist of encrypting content with a stream cipher (AES-CTR or ChaCha20) and appending a MAC (GMAC, CMAC, or Poly1305).

TLS 1.3 changes things. It no longer has ciphersuites of the form you reference; instead the ciphersuite specifies only the data cipher, which is always an AEAD cipher, and the hash used in key-derivation (what earlier versions called PRF); the key-exchange and entity authentication methods are selected separately. Thus 1.3 never has Finished (or anything else after CCS) in a null-encrypted record, nor a stream cipher, nor a CBC cipher. See rfc8446 5.2; now we have record header 5 bytes always specifying 'application data' (23) even for an actual handshake record, followed by the authenticated encryption (as above) of content, the real aka 'inner' record type, and optional/variable padding. In 1.3 the nonce for the AEAD cipher is (always) the record sequence number masked by a value from the key derivation, and is not sent; this is described in 5.3. Also for Finished in particular, in 1.3 verify_data is now a single HMAC (instead of the PRF in 1.0-1.2) of a very similar transcript hash, but is no longer truncated to 12 bytes and now varies with the derivation hash.

  • Thanks for the huge details ..But can you brief how exactly the format would like when the protocol version is TLS 1.2.(eg:- Record header+...+Handshake header+..... – kumar s Oct 21 '19 at 8:30
  • kumar: the handshake header (and also body) is visible in the record only for the null-encryption case; see the second sentence of my second paragraph. For all other cases the record contains ciphertext (and sometimes other things, as I described for each case) and it is the plaintext that consists of the handshake header plus body (plus more for 1.3). – dave_thompson_085 Oct 21 '19 at 17:38
  • thank you very much – kumar s Oct 21 '19 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.