Cryptography Reference
In-Depth Information
0xEAFF403432CBD12A7F7174C209F5364398E62F4A1B8F9B7C32B6CE190E71669\
6D3E866E09AF5367743EA5CC7903515D05D667E5480C562BCC0821F4A670B27F9 \
0x7a8d74369f97e386e4494f5e711e0f2059658304d2d432ce331067251c5a4be\
defd149935b92561a20959ab9e40427175e6d70cd0daf00e3c2c977ab115af5f7
02 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 00 03 01 02 03 04 05 06 07 08 09 0a 0b
0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26
27 28 29 2a 2b 2c 2d 2e 2f 00
030102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f2021222324252627
28292a2b2c2d2e2f
After stripping off the padding, you're left with a premaster secret whose
fi rst two bytes are the SSL version 0301 and then the premaster secret which,
in this case, isn't particularly secure.
According to the protocol, the client must now send a change cipher spec
message. This is a pretty boring message, consisting of a single byte:
12:37:04.046440 IP localhost.localdomain.56047 > localhost.localdomain.https: P
126:185(59) ack 822 win 270 <nop,nop,timestamp 12673376 12673376>
0x0000: 4500 006f 0345 4000 4006 3942 7f00 0001 E..o.E@.@.9B....
0x0010: 7f00 0001 daef 01bb 1e32 6430 1e28 e546 .........2d0.(.F
0x0020: 8018 010e fe63 0000 0101 080a 00c1 6160 .....c........a`
0x0030: 00c1 6160
1403 0100 0101
Notice that the message type is 14, not 16; change cipher spec is a separate
top-level type. Other than this, it's just the single, plain byte 0x01.
Decrypting the Encrypted Exchange
Change cipher spec is followed by a fi nished message. This message is encrypted
using the newly negotiated parameters, so must be decrypted. My network stack
decided to aggregate these two messages into a single TCP push, but there's no
particular reason why it would have to be this way.
The fi nished message starts with the standard, expected (unencrypted) TLS mes-
sage header, and tells the recipient that the message that follows is 48 bytes long.
Everything following the header is encrypted using the negotiated session keys.
1603 0100 301c
..a`..........0.
0x0040:
e1a2 aaf3 1267 749d b1e7 701d 8f95 98d8
.....gt...p.....
0x0050:
cd65 526b 90a4 d8d0 7536 1dd4 6a26 4787
.eRk....u6..j&G.
0x0060:
4f49 5ac7 8c89 7dcc 1ee3 ad37 b25e 8d
OIZ...}....7.^.
Because you know the private key that was used for the key exchange, you know
the premaster secret. Therefore, you can work forward and discover the master
secret and the key material. Recall that the master secret was generated by applying
the PRF to the premaster secret. Specifi cally, the PRF takes three input parameters:
the secret, the label, and the seed. Recall that, for master secret computation, the
label is the fi xed string
“master secret”
, and the seed is the client random fol-
lowed by the server random. The secret is, of course, the premaster secret.
Search WWH ::
Custom Search