Decrypt SSL traffic with the openssl command line tool 8

0

For my final steps in my script I followed this to obtain the client encryption key to perform the decryption with.

client.random xxd -p crnd.bin

5b689404b500456eef2f1a79ec782eb3eeaac3a8d7c02ae03c8426f363b1
8a33

server.random xxd - srnd.bin

5b6894043bb1289e158b0278ef66dc53c9fa71e75e900739af2657cd4476
ec1e

(echo -n key expansion ; cat srnd.bin crnd.bin) > master_seed.key
xxd -p master_seed.key

6b657920657870616e73696f6e 5b6894043bb1289e158b0278ef66dc53c9
fa71e75e900739af2657cd4476ec1e 5b689404b500456eef2f1a79ec782e
b3eeaac3a8d7c02ae03c8426f363b18a33
note: as before the spaces are not there I added them for clarity

key=$(cat master_secret.hex)                                                                        
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <master_seed.key -binary >a1
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a1 -binary >a2
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a2 -binary >a3
openssl dgst -sha256 -mac hmac -macopt hexkey:$key <a3 -binary >a4
##
cat a1 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k1
cat a2 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k2
cat a3 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k3
cat a4 master_seed.key | openssl dgst -sha256 -mac hmac -macopt hexkey:$key -binary >k4
cat k1 k2 k3 k4 | head -c104 | xxd -p -c104 > k1_k4.hex
truncate -s-1 k1_k4.hex

$cat k1_k4.hex
64666eafe1cbd51f2e2b50799b40f6007c3dc56fe0aac1312d35b5e8b6bf9af6ecf07e1dff27c784
4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808ca94445e3d771d3e
06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff
dd bs=40 count=1 if=k1_k4.hex of=cmackey.hex 2>/dev/null
dd bs=40 count=1 skip=1 if=k1_k4.hex of=smackey.hex 2>/dev/null
dd bs=80 skip=1 if=k1_k4.hex 2>/dev/null | dd bs=64 count=1 of=cenckey.hex 2>/dev/null
dd bs=80 skip=1 if=k1_k4.hex 2>/dev/null | dd bs=64 skip=1 count=1 of=senckey.hex 2>/dev/null

$cat cmackey.hex

64666eafe1cbd51f2e2b50799b40f6007c3dc56f

$cat smackey.hex

e0aac1312d35b5e8b6bf9af6ecf07e1dff27c784

$cat cenckey.hex

4bf20108190203c4210ff9df6c4eb6e907ddd1f49646ab4b243c80a6ae9b4808

$cat senckey.hex

ca94445e3d771d3e06b71ee0deb4c1879986c4c6a4b78bf1c3c1083a6ddce9ff

Encrypted handshake wireshark log

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 64
    Handshake Protocol: Encrypted Handshake Message

Handshake Protocol: Encrypted Handshake Message
16030300409a1bf36b786c3b5985617c76afd985d68ffdaf
6d9f1a25ef40159702b5adef402bdb5196ce76a93fd73049
3accf929447fa9c6f1172d6b4035f5578ebfe95c6d

Saved just the encrypted data (last 64 bytes to cenc.dat) $xxd -p cenc.dat

9a1bf36b786c3b5985617c76afd985d6 8ffdaf6d9f1a25ef40159702b5ad
ef402bdb5196ce76a93fd730493accf929447fa9c6f1172d6b4035f5578e
bfe95c6d
Note: space added again for clarity

$xxd -p iv.bin

9a1bf36b786c3b5985617c76afd985d6

$xxd -p encmsg.bin

8ffdaf6d9f1a25ef40159702b5adef402bdb5196ce76a93fd730493accf9
29447fa9c6f1172d6b4035f5578ebfe95c6d

Last

$cat encmsg.bin | openssl aes-256-cbc -d -K $key -iv $iv -nopad |xxd
gives the same result of bad decrypted data not a finished (14) record

Dave, In comparing my output byte for byte I do not see any problems with my steps. I've gone over this a dozen or more times manually and calling my script and I get the same output which is wrong as you pointed out it does not decrypt to a finish message. Are you spotting anything here? Thanks

David B

Posted 2018-08-10T11:28:04.237

Reputation: 41

1Who's Dave?.... – djsmiley2k TMW – 2018-08-10T12:13:01.793

The person that's been helping me out. Hope that was not out of line to direct that to him. I had done this on my previous posts. – David B – 2018-08-10T12:25:17.993

It's just confusing to read. That's all. – djsmiley2k TMW – 2018-08-10T12:30:13.410

Perhaps an @daveSomethingOrOther to his stack exchange id would help – Hogstrom – 2018-08-10T18:29:46.407

No, I don't spot anything. The only remaining possibility I can think of is that your systems used (agreed) the Extended Master Secret extension which (radically!) changes the master secret derivation, and thus of course the keys. Check ClientHello and ServerHello in the capture to see if they both contain this extension (0017 hex or 23 decimal if wireshark doesn't decode it).

– dave_thompson_085 – 2018-08-11T09:53:34.607

@Hogstrom: @-notify only works for people already 'present' on this Q, NOT sitewide. See midnote 1 in the help link for the comment box, or the more detailed https://meta.stackexchange.com/questions/43019/how-do-comment-replies-work . The asker did comment on the previous Q where I was the only other commentor, which automatically 'pinged' me.

– dave_thompson_085 – 2018-08-11T10:05:53.433

Thanks, Got it let me review my logs and RFC7627. I heard back from our sys admin who is going to work on adding the libraries to our mumps o.s. that runs on top of unix. This should make things easier but there is no eta on when I might have this available to me. – David B – 2018-08-11T12:31:39.260

that's it! The client had sent in 17 (23) for the extended handshake. I didn't notice I coded my response with a 17 as well indicating my server would as well. I changed my response to not use extended master secret and the decryption worked. I posted my next item to hopefully get close to finishing up here you take a look Dave thanks.

– David B – 2018-08-13T13:03:21.393

No answers