seems to be similar problem as the one posted 2 years ago, but starting a new thread per Kurt's recommendation.
https://ask.wireshark.org/questions/12121/unable-to-decrypt-ssl-traffic-in-wireshark-logs?page=1&focusedAnswerId=12122#12122
Here is my Wireshark SSL debug log
ssl_association_remove removing TCP 443 - ssl handle 00000000041CF020 6553 bytes read
PKCS#12 imported
Bag 0/0: PKCS#8 Encrypted key
Private key imported: KeyID b7:20:ac:00:7b:d3:57:53:4b:c0:e5:69:42:fb:27:50:...
ssl_load_key: swapping p and q parameters and recomputing u
Bag 1/0: Encrypted
Bag 1/0 decrypted: Certificate
Certificate imported: smtp.****.com <<ERROR>>, KeyID b720ac007bd357534bc0e56942fb27502483819a
Bag 1/1: Certificate
Certificate imported: DigiCert High Assurance EV Root CA <<ERROR>>, KeyID 13317e62854253d6d7783190ec919056e991b9e3
Bag 1/2: Certificate
Certificate imported: DigiCert High Assurance CA-3 <<ERROR>>, KeyID 25f9d7434b1ce71def4211ee6be3c0e0256fad95
ssl_init IPv4 addr '192.168.1.15' (192.168.1.15) port '443' filename 'P:\n0.pfx' password(only for p12 file) '*****'
ssl_init private key file P:\n0.pfx successfully loaded.
association_add TCP port 443 protocol ssl handle 00000000041CF020
asked 23 Sep '14, 09:08
net_tech
116●30●33●37
accept rate: 13%
In "the RSA Keys list:" dialog box where you configure the certificate path, is "Protocol" set to "ssl" or "http"? I'm not familiar with what shows up in the ssl debug log, but this line makes me suspect it's "ssl" when it should be "http".
It's encrypted SMTP traffic, it should be smtp I think. Wrong port? Should it be 25 instead of 443 since communication is happening over 25.
Sorry, I didn't go back and fully digest your original message. In that RSA Keys List dialog box, the port number should be the destination (serverside) port number of the tcp connection you're trying to decrypt. If the unencrypted traffic is SMTP instead of HTTP, then yes, specify "smtp".
Perhaps you've already decrypted this and don't know it. Do you see readable text if you right-click a packet and select "Follow SSL Stream"?
updated from 443 to 25 and changed from ssl to smtp. still unable to decrypt when I follow SSL stream. (blank screen comes up)
This probably won't work, but try re-opening the trace. I've had to refresh it before.
In any case, would you mind including a bit more of the ssl debug log? There should be a record for every packet it tries to decrypt. It looks like you might have decided to cut it off before that point.
looks like the answer is right here.
ssl_find_private_key server 204.232.236.146:25
ssl_find_private_key: testing 1 keys
ssl_find_private_key can't find private key for this server! Try it again with universal port 0
ssl_find_private_key can't find private key for this server (universal port)! Try it again with universal address 0.0.0.0
ssl_find_private_key can't find private key for this server! Try it again with universal address 0.0.0.0 and universal port 0
ssl_find_private_key can't find any private key!
the private key I have is for incoming connections, can't decrypt outgoing connection since I don't have the key from the remote side.
Not sure I understand what you mean there, but perhaps I just don't understand SSL enough - entirely possible. Regardless, glad you feel you have an explanation.
spoke too soon... looking at a stream from an external smtp server to mine and still get blank window when ssl stream is followed
OK, now I'm confused. Perhaps you should post the stream you want to decrypt to cloudshark, or attach, so we can look at the same thing.
It's possible that the stream was a cached session, in which case Wireshark can't decrypt - it needs the full handshake. We should be able to confirm this if you post the trace somewhere we can see it.
SSL Log link
Sorry, I was referring to the actual trace file (.pcap or .pcapng). But the log file you linked to does seem to have the answer:
I think this means that the SSL session was cached. Wireshark can't decrypt a cached SSL session because the full key exchange doesn't take place. We should be able to tell pretty quickly if you post the actual trace file. You can also confirm yourself by looking for the certificate in the Packet Details pane of the Server Hello packet. If instead you see Session ID and renegotiation fields, it's a re-used session and Wireshark can't decrypt it. You need the full handshake.
it does!
https://ask.wireshark.org/questions/16788/wireshark-decrypt-ssl-traffic
googled for ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt and found my answer in Q16788
I am way out of my league now. And I'm not entirely convinced it's impossible - the SSL Wiki seems to say otherwise. Also see this link. I'm sure someone more knowledgeable will chime in here.
Good luck.
Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (cipher suite 0xc014) is used in the stream I am trying to decrypt.
Another post by Kurt (from this year) suggests that it's possible with Wireshark 1.11, I am running 1.12.
https://ask.wireshark.org/questions/32668/unable-to-decrypt-ssl-sessions-in-wireshark
Yeah, I don't (yet) think the issue here is with the protocol being used. The debug log says it can't find the right private key:
So I think either you haven't quite yet specified the right properties in the RSA Keys List dialog, or you didn't catch the full handshake.
In the RSA Keys List dialog, are you sure you have the private key from the serverside of the connection (204.232.236.146:25), and that the Port number is 25?
Can you post the trace?
Unfortunately i can't post this trace anywhere, but after examining Server Hello, Certificate, Server Key Exchange, Server Hello Done frame I can see that the serialNumber of the cert does not match the serial number of the private key I exported.
I was unable to decrypt SSL traffic with wireshark even after obtaining the correct private key.
SYN-bit's post confirms this https://ask.wireshark.org/questions/17630/cant-decrypt-tlsv1-traffic
Perhaps this is the way to decrypt... http://www.codybaker.org/2012/08/debugging-ssl-communications/
I've done my best to help you here, but I'm at my limits. You'll need to wait for someone more knowledgeable to respond. If you decide to post a new question, I'll hold off from commenting to encourage responses from others.
Sorry I couldn't help more.