SSL decrypting when Browser in play ??

Question

I am trying to decrypt a complete SSL session using wireshark (and then will use tshark). I have the server private key and can see wireshark decrypting return traffic from server to client. However, the client sourced traffic is not decrypted (I can't see the decrypted GET). I am using the Internet Explorer browser on a Win7 system. Wireshark is running on the Win7 system.

Now for a few questions:

1) do I need to have the IE browser private key loaded into wireshark ??

2) if so, where do I find the private key used by the browser ?? must I somehow extract it ??

Any/all advice would be appreciated. (yes, I've read the various tag entries regarding ssl but haven't seen anything that fully addresses my question. If I missed the golden nugget, please provide a pointer)

thanks, wk

Answer 1

1

No, you don't need anything from the client, there must be some other reason that it won't decrypt the client messages...

Do you see a "Finished" handshake message from the client? If so, then decryption did start correctly for the client side (otherwise there would be an "Encrypted Handshake" message instead).

If it is a server in a test environment, could you post the capture file on www.cloudshark.org and post the link here accompanied by the server key?

If that's not possible, can you attach the SSL debug log to your question?

answered 10 Apr '12, 13:48

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

Thanks for sharing this valuable information.

(11 Apr '12, 22:57) Mano

You're welcome!

(I converted your "answer" to a "comment", which is how this site works best, please see the FAQ)

(11 Apr '12, 23:30) SYN-bit ♦♦

Answers to questions from Syn-Bit...

1) yes there is a client FINISH. The finish is contained in the same packet as the Client Key Exchange and Change Cipher messages.

2) It seems that the SSL dissector may be trying to convert to regular HTTP, but its claiming a malformed packet thus I don't see the GET. I'm not sure what it doesn't like about the packet ?? If I run the same page w/o SSL, wireshark doesn't complain about malformation. The log entry for the malformed (packet #30) is below. It is the first packet from client to server after the client FINISH (client is ie browser).

dissect_ssl enter frame #30 (first time)
  conversation = 03E32978, ssl_session = 03E32CE0
  record: offset = 0, reported_length_remaining = 666
dissect_ssl3_record: content_type 23
decrypt_ssl3_record: app_data len 32, ssl state 0x3F
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
ssl_decrypt_record ciphertext len 32
Ciphertext[32]:
51 46 f2 c0 98 0f f8 d5 30 e2 27 63 c0 1b e9 fa 
1d b4 a3 93 77 34 b1 d7 06 1c 15 a0 00 63 4e 9b 
Plaintext[32]:
47 36 54 ed ff ea d9 0f df 11 b0 50 50 05 3e e4 
9b 6b 8f 5d f8 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 
ssl_decrypt_record found padding 10 final len 21
checking mac (len 1, version 301, ct 23 seq 1)
tls_check_mac mac type:SHA1 md 2
Mac[20]:
36 54 ed ff ea d9 0f df 11 b0 50 50 05 3e e4 9b 
6b 8f 5d f8 
ssl_decrypt_record: mac ok
ssl_add_data_info: new data inserted data_len = 1, seq = 0, nxtseq = 1
association_find: TCP port 60129 found 00000000
association_find: TCP port 443 found 03793460
dissect_ssl3_record decrypted len 1
decrypted app data fragment: G
dissect_ssl3_record found association 03793460

I couldn't figure out how to attach the complete log file. I'd love to know what the dissector is having issues with ?? The site seems to work fine. The good news is that the issue is very reproduceable.

Thanks so much for any help you can provide.

-walter

(13 Apr '12, 07:40) wakelt

OK, decryption works, but indeed the HTTP request is garbled. What you can do is to use "data" in your SSL-keys list instead of "http" to disable http processing by Wireshark.

You can also do "Follow SSL stream" to get a few on the decrypted data.

(13 Apr '12, 08:12) SYN-bit ♦♦

Thanks Syn-Bit...I am looking at the "data" within the packet as you suggest. I see the following oddity:

immediately after the client FINISH, the client sends the encrypted GET out (so far so good)
wireshark is decoding 2 data field in the same packet:

Data (1 byte)
Data: 47 [Length: 1] Data (743 bytes) Data: 45675xxxxxxxxxxxxxxxxxx...lots of bytes [Length: 743]

It so happens that 0x47 is ascii letter G (the first letter of GET). The second data field has the remainder of the request.

Why is the SSL dissector seeing two data fields ?? Something feels odd about this. What separates one data field from the next ?? Is there some type of index that is off ?? As mentioned earlier, the server has no issue interpreting the encrypted command and respond with proper data.

thanks, Walter

(13 Apr '12, 10:29) wakelt

snippet of the packet byte output where wireshark claims malformation. Again, not sure why the dissector splits up the G ET into two separate data decryptions ???? (if that is indeed what it is doing)

===================================================================================== 02e0 28 e9 56 ed 40 01 69 aa 68 6d 72 df 88 29 a2 99 ([email protected]).. 02f0 fe ee 84 b5 fd 8c af 29 b3 dd 64 f0 4c e6 d1 d6 .......)..d.L... 0300 d3 4f ac 95 fb 48 e8 62 f0 a9 2d e7 5b 36 1c 68 .O...H.b..-.[6.h 0310 04 bb 6b 25 2d 34 cb cb 35 df c7 ca 41 18 45 d6 ..k%-4..5...A.E. 0320 fe 07 c0 36 e2 96 35 fa 28 ab 12 c5 15 da 80 09 ...6..5.(.......

Decrypted SSL data (1 bytes):

0000 47 G

Decrypted SSL data (697 bytes):

0000 45 54 20 2f 63 73 73 2f 6d 61 69 6e 2e 63 73 73 ET /css/main.css 0010 20 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63 65 70 HTTP/1.1..Accep 0020 74 3a 20 2a 2f 2a 0d 0a 52 65 66 65 72 65 72 3a t: /..Referer: 0030 20 68 74 74 70 73 3a 2f 2f 6f 72 69 67 69 6e 2d https://origin-

(13 Apr '12, 12:15) wakelt

@wakelt I changed your "answers" to comments. See the FAQ about how this Q&A site works. To add such long pieces of updated information to your questions in the future, you should edit the original question.

(13 Apr '12, 13:34) multipleinte...

showing 5 of 7 show 2 more comments

Answer 2

Step one – set up an SSL-protected server to use as a testbed

To illustrate the process, we’re going to use OpenSSL to generate a certificate and act as a web server running HTTP over SSL (aka HTTPS) – it’s quite straightforward.

To begin with, we need to get ourselves a self-signed certificate that our HTTPS server can use. We can do this with a single command:

openssl req -x509 -nodes -newkey rsa:1024 -keyout testkey.pem -out testcert.pem

OpenSSL will ask you for some input to populate your certificate with; once you’ve answered all the questions, the output of this command is two files, testkey.pem (containing a 1024 bit RSA private key) and testcert.pem (containing a self signed certificate). PEM (Privacy Enhanced Mail) format files are plaintext, and consist of a BASE64 encoded body with header and footer lines. You can look at the contents of your key and certificate files in more detail like this:

openssl rsa -in testkey.pem -text -noout (output here) openssl x509 -in testcert.pem -text -noout (output here; more info here)

We need to perform one tiny tweak to the format of the private key file (Wireshark will use this later on, and it won’t work properly until we’ve done this):

openssl rsa -in testkey.pem -out testkey.pem

Now we’re ready to fire up our HTTPS server:

openssl s_server -key testkey.pem -cert testcert.pem -WWW -cipher RC4-SHA -accept 443

The -key and -cert parameters to the s_server command reference the files we’ve just created, and the -WWW parameter (this one is case sensitive) causes OpenSSL to act like a simple web server capable of retrieving files in the current directory (I created a simple test file called myfile.html for the purposes of the test).

The -cipher parameter tells the server to use a particular cipher suite – I’m using RC4-SHA because that’s what’s used when you go to https://www.google.com. The RC4-SHA cipher suite will use RSA keys for authentication and key exchange, 128-bit RC4 for encryption, and SHA1 for hashing.

Having got our server up and running, we can point a browser at https://myserver/myfile.html and retrieve our test file via SSL (you can ignore any warnings about the validity of the certificate). If you’ve got this working, we can move on to…

Step two – capture some traffic with Wireshark

Fire up Wireshark on the server machine, ideally with a capture filter like “tcp port 443″ so that we don’t capture any unnecessary traffic. Once we’re capturing, point your browser (running on a different machine) at https://myserver/myfile.html and stop the capture once it’s complete.

Right-click on any of the captured frames and select “Follow TCP stream” – a window will pop up that’s largely full of SSL-protected gobbledegook:

Step three – configuring Wireshark for decryption

Close the TCP Stream window and select Preferences from Wireshark’s Edit menu. Expand the “Protocols” node in the tree on the left and scroll down to SSL (in newer versions of Wireshark, you can open the node and type SSL and it will take you there).

Once SSL is selected, there’s an option on the right to enter an “RSA keys list”. Enter something like this:

10.16.8.5,443,http,c:\openssl-win32\bin\testkey.pem

You’ll need to edit the server IP address and path to testkey.pem as appropriate. If this has worked, we’ll notice two things:

* Wireshark’s SSL dissector can look into otherwise encrypted SSL packets and dissect the protocol inside:
* We can right-click on any of the captured frames that are listed as SSL or TLS and select “Follow SSL stream”: