Cryptography Reference
In-Depth Information
[jdavies@localhost ssl]$ ./digest -md5 \
0x000102030405060730000102030405060708090a0b0c0d0e0f\
b73b8d2a4c35192bf6ffe87b01378772
14f258c2fe6bf291b84ce9aeebc6d4d8
Master Key
0001020304050607
ASCII Zero
30
Challenge
000102030405060708090a0b0c0d0e0f
Connection Id
b73b8d2a4c35192bf6f fe87b01378772
Read Key
14f258c2fe6bf291
Write Key
b84ce9aeebc6d4d8
According to the specification, the client should next respond with a
client_finished
message, but OpenSSL jumps the gun and sends its own
server_verify
. Because neither is dependent on the other, it doesn't matter
what order they are received in:
15:57:38.916066 IP localhost.localdomain.pcsync-https >
localhost.localdomain.50704: P 893:936(43) ack 121
win 256 <nop,nop,timestamp 24215213 24215212>
0x0000: 4500 005f 8fa1 4000 4006 acf5 7f00 0001
0x0010: 7f00 0001 20fb c610 9bb0 f575 9b92 7ef7
0x0020: 8018 0100 fe53 0000 0101 080a 0171 7ead
0x0030: 0171 7eac
0028 0777 76d1 5c1e 94b1 d24d
0x0040: a349 b24c b342 af66 537b 0b19 154b 6daf
0x0050: 2a36 064c a459 53b4 5c55 7c70 509a 14
However, the connection is now encrypted. A passive observer could follow
along until this point, but without access to the keys — either the server's pri-
vate key or the negotiated symmetric keys — he would be unable to fi gure out
what the contents of this packet were, or even what type it is. You can decrypt
it, though, because you know the keys. The fi rst three bytes are sent in plain
text; they are the length of the packet (0x0028), and the length of the padding
(0x07). The rest is DES encrypted:
[jdavies@localhost ssl]$ ./des -d 0x14f258c2fe6bf291 \
0x0001020304050607 \
0x7776d15c1e94b1d24da349b24cb342af66537b0b19154b6daf\
2a36064ca45953b45c557c70509a14490d1f61abaf26ace8326d\
baa79b5f2805000102030405060708090a0b0c0d0e0f00000000000000
You can see the seven bytes of padding, which should be removed:
490d1f61abaf26ace8326dbaa79b5f2805000102030405060708090a0b0c0d0e0f
Search WWH ::
Custom Search