Cryptography Reference
In-Depth Information
Armed with the keys and initialization vectors, you can go ahead and decrypt
the 48-byte fi nished message:
[jdavies@localhost ssl]$ ./aes -d 0x6dbb1276d318c6551ef8245888420cf4 \
0xf6bb0cc22615db9c0d93ad3c21d2f58e \
0x1ce1a2aaf31267749db1e7701d8f9598d8cd65526b90a4d8\
d075361dd46a2647874f495ac78c897dcc1ee3ad37b25e8d
1400000ce3945aa7b226794d96cfcaf7b79febcb41c2bd7b48a77d7b26f
958296dc1467c0b0b0b0b0b0b0b0b0b0b0b0b
This is, as expected, a handshake message of type 0x14 (fi nished), followed
by a three-byte length indicating that the message is 12 bytes long. If you recall,
this is correct; the fi nished message is 12 bytes, generated by the PRF, seeded
with the hash values of all of the handshake messages up to this point.
However, the message body is signifi cantly longer. It includes 20 bytes of
MAC and an extra 12 bytes of padding, because 4+12+20 (header + contents +
MAC) is equal to 36, which is not an even multiple of the 16-byte block size.
Notice that there are 12 bytes of padding, but the value of the padding byte is
0x0b
(11); there's always one byte on the end that indicates how much padding
there is, which isn't actually considered padding.
You can verify the MAC as well. Remember that the MAC is the HMAC
function of the sequence number, the TLS header, and the contents. Because
this is the fi rst securely exchanged packet, the sequence number is 0. However,
be careful. If you try to do this
[jdavies@localhost ssl]$ ./hmac -sha1 \
0x3a1ee25b3fa7efb9a2c8f112de47c3276917a2bb \
0x000000000000000016010100301400000ce3945aa7b226794d96cfcaf7
dfc0e0ef8c50a3bc3f9db3d87168a99ce3c4f99d
you'll get the wrong answer. The MAC is actually
b79febcb41c2bd7b48a77d
7b26f958296dc1467c
; what went wrong?
Remember that the MAC was generated from the sequence number and
what the TLS header
would have
looked like, had there been no encryption
or MAC — that is, the length before padding and MAC. So, to get the correct
answer, you have to subtract the 32 bytes of MAC and padding from the length
in the TLS header and compute:
[jdavies@localhost ssl]$ ./hmac -sha1 \
0x3a1ee25b3fa7efb9a2c8f112de47c3276917a2bb \
0x000000000000000016030100101400000ce3945aa7b226794d96cfcaf7
b79febcb41c2bd7b48a77d7b26f958296dc1467c
The server receives the fi nished message, decrypts it, verifi es the MAC, and
compares the verify data of
e3945aa7b226794d96cfcaf7
to what it has computed
so far. It then responds with its own change cipher spec and fi nished message:
12:37:04.047107 IP localhost.localdomain.https > localhost.localdomain.56047: P
822:881(59) ack 185 win 256 <nop,nop,timestamp 12673376 12673376>
0x0000: 4500 006f 82e6 4000 4006 b9a0 7f00 0001 E..o..@.@.......
Search WWH ::
Custom Search