OSQA is unmaintained. Help us figure out where to go from here.

Hi all, I'm using Wireshark 1.12.3, I can decode https traffic before (a few weeks ago) but now I cannot anymore. This is debug log file : debug.txt

I tried to search google and this site, I find some stuffs but they didn't work, some topic said:

Wireshark is only able to decrypt SSL when the full first SSL handshake is available ("Client Hello" with Session-ID = 0) --> How to check ?
The Key-Exchange should be RSA (not DHE or ECDHE) --> How to check ?
SSL: "Reassemble SSL records spanning multiple TCP segments" should be enabled --> yes
TCP: "Allow subdissectors to reassemble TCP streams" should also be enabled --> yes

the full SSL handshake needs to be present in the trace so that the proper keys can be extracted. A reused SSL session (with a short handshake) does not provide the keying material and can therefor only be decrypted when the original full handshake is also present in the tracefile. --> how to check ?

Then, as Jaap mentioned, when a DH cipher is used, the keying material is exchanged using the Diffie Hellman protocol which uses dynamically created keypairs instead of the server's public and private key. Therefor Wireshark is not able to decrypt these sessions. --> how to check ?

My webserver : Centos 6.4 64 bit. I tried to capture by wireshark on Windows client or tcpdump on server and many way but it still not works. Please let me know if you need more information.

asked 09 Feb '15, 19:48

Jack%20Chuong's gravatar image

Jack Chuong
accept rate: 0%

edited 09 Feb '15, 20:01

From your SSL debug log:

ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt

So, your session is using a DH cipher. You can see that for yourself when you look at the ServerHello message and then look at the cipher that was chosen. You can also determine this by seeing a "ServerKeyExchange" in the SSL session setup, you won't see a ServerKeyExchange in a RSA key negotiation.

If you want to know if your session is using a full SSL handshake, check whether there is a "Certificate" and "ClientKeyExchange" handshake message in the SSL session that you are looking at. If not, it's using a cached session. You can then check the SSL Session ID in the ServerHello message to see which session it was and look for other sessions in the tracefile with the same session ID. If one of these (the first one) does have a "Certificate" and "ClientKeyExchange" handshake message, then wireshark is able to decrypt all sessions with this session ID, if not, you're out of luck as the full SSL handshake was not captured.

permanent link

answered 10 Feb '15, 00:12

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

Hi SYN-bit, thank you for your reply.

I looked into SeverHello message and find out that Cipher Suite : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013).

How can I remove cached session and make my server and client to establish a full SSL handshake with RSA key negotiation ?

(10 Feb '15, 02:35) Jack Chuong

I made it work. As SYN-bit said, the reason because my server and client use DH cipher to exchange key, I should config my server to use RSA cipher to exchange key. with Apache : SSLCipherSuite RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS Now I can decrypt https traffic.

(23 Mar '15, 02:28) Jack Chuong
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 09 Feb '15, 19:48

question was seen: 7,996 times

last updated: 23 Mar '15, 09:52

p​o​w​e​r​e​d by O​S​Q​A