Join Log in
Score:1
avatar Crypto

TLS 1.2 client finish message

pk flag
Aiin Zul

Im working on TLS1.2 on cipher suite ECDHE_ECDSA_AES_128_CBC_SHA256. Im currently at the stage of client encrypted message where I always got error on wireshark from the server saying that Fatal, Description : Handshake Failure. So from what I have done my research, the contain for this client finish message suppose to go through these steps :

  1. 1 byte of handshake type : finish = 0x14
  2. 3 bytes of data_verify_length = 12
  3. 12 bytes of verify_data
  4. These 16 bytes from steps 1),2) and 3) are passed through hmac_sha256 and gives and produces 32 hash bytes. Can someone confirm me the inputs? 5)The 32 bytes are preceded with 16 bytes from steps 1),2) and 3) and gives a total of 48 bytes before padding
  5. We added 1 byte length of padding and 15 bytes of padding of 0x0F and gives a total of 64 bytes
  6. The 64 bytes are then encrypted with client IV and client encryption key
  7. The 64 bytes are preceded with 16 bytes of IV before sending to server

Could someone verify all the steps and corrected me if I'm wrong because I kept getting handshake failure at this point.

Thank you in advance!

60
0 + 0
aes
tls
Score:2
dave_thompson_085 avatar Crypto
cn flag
dave_thompson_085

As stated in this 2015 question plus my answer which you apparently didn't read even while commenting on the other answer, TLS <=1.2 HMAC is calculated over:

  • the record seqnum, type, version, and length: hex 00 00 00 00 00 00 00 00 16 03 03 00 10

  • plus the Finished message which you correctly have as 1 byte type = 14, 3 bytes length = 00 00 0C, and 12 bytes 'verify_data'

using the client MAC key (from the key derivation process).

You have the subsequent part correct: you CBC-encrypt the record body (which is exactly the handshake message) plus HMAC plus padding (16 times 0F), and prepend the 16-byte IV used (which should be unpredictable, normally random). And prepend to that the record header of type = 16, version = 03 03, length = 00 50.

Note that in addition to the record being formatted, HMACed, and encrypted correctly, the verify_data in the message must be correct, and IME most people have more trouble getting that right than the record processing.

Reference: RFC5246 6.2.3.1 (and 6.2.3.2 for CBC encryption)

0 + 0
pk flag
Aiin Zul
Does the total number of input bytes for hmac is 29 bytes according to your post : hex 00 00 00 00 00 00 00 00 16 03 03 00 10 + 16 bytes (1 byte type + 3 bytes length + 12bytes verify data) ?
0
Reply
pk flag
Aiin Zul
I have corrected my input hmac accroding to your post. But I still have handshake failure problem. Well let's start from how I did to produce the verify_data : 1) hash of all previous handshake message : SHA256(all_handshake_messages) 2)Then I did prf(maseter_secret, "client_finished", SHA256(all_handshake_messages)) These produces 12 bytes of verify_data Then I concatenate the data in step 3) with the data in step 1) and 2) in my very first post I did rest of the steps. What could have cause the Handshake failure ?
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.