Re: question about bug 3303

[Sake Blok <sake () euronet nl>]

On 6 sep 2010, at 11:06, kolos_ws () ural2 hu wrote:

> Firstly, I really appreciate you helpfulness.

Glad to be of help!

> This is what I see in my capture that makes me think this might be the 
> same issue:
>
> [..]
> 216 <timestamp> <srcip> <dstip> TCP   [TCP segment of a reassembled PDU]
> 217 <timestamp> <srcip> <dstip> TLSv1 Server Hello, Certificate, Server Key Exchange, Server Hello Done
> [..]

I kind of missed the " Certificate, Server Key Exchange" before. But this means it is a totally different issue. This 
means the keying material is not created by the client and sent to the server encrypted with it's public key. Instead 
of that the DH algorithm is used to negotiate keying material. Wireshark is not able to decrypt sessions that used DH 
to negotiate keys.

You can see this by looking at the chosen cipher in the ServerHello message. It should have DH in the ciphername.

You can circumvent this by restricting the allowed ciphers on either the client or the server.

You might want to have a look at the SSL troubleshooting presentation I gave at Sharkfest'09. It shows more situations 
in which decryption does not work and might help you in your SSL troubleshooting:

https://www.cacetech.com/sharkfest.09/AU2_Blok_SSL_Troubleshooting_with_Wireshark_and_Tshark.pps
 (or watch the video of the presentation at http://www.lovemytool.com/blog/2009/06/sake_blok_11.html)

Cheers,


Sake


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe