Riverbed Cascade Pilot Personal Edition: Take Wireshark to the Next Level - Advanced Triggers and Alerts; Web and VoIP Analytics; Long-Term Trending and Forensics; Deep Packet Analysis with Wireshark

Wireshark-users: Re: [Wireshark-users] Trouble with SSL dissector - got ithalf working!

Date Index Thread Index Other Months All Mailing Lists

Date Prev Date Next Thread Prev Thread Next

From: Dominic Tulley <dominic.tulley@xxxxxxxxxx>
Date: Thu, 1 Oct 2009 08:43:47 +0100

Hi Sake,

that makes sense at least. I wasn't using a VM so I don't understand why we have duplicate packets - I was using two real machines. Anyhow, so long as I understand how to resolve the issue that's great.
I'll raise an enhancement request as you asked.

Thanks for your help.

-Dominic

==================
Dominic Tulley
Leading Architect, DOORS Development Lab
Rational Requirements Definition and Management
IBM Software Group
==================

From:	"Sake Blok" <sake@xxxxxxxxxx>
To:	"Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Date:	30/09/2009 16:44
Subject:	Re: [Wireshark-users] Trouble with SSL dissector - got ithalf working!
Sent by:	wireshark-users-bounces@xxxxxxxxxxxxx

Hi Dominic,

Duplicate packets will be displayed as "ouf-of-order" at the tcp level, as there is no code (yet) to recognize these packets as duplicates. I bet you are capturing traffic to and from a VM on the host on which this VM runs. In VMware, this results in duplicates (I have no idea why, anyone?).

Editcap does not re-order packets, the -d option just removes the duplicates (you can vrify this by running capinfos on the infile and the outfile).

Wireshark is not able to recognize or delete duplicates at the moment, but it would be a nice feature. Do you mind filing an enhancement request for this at https://bugs.wireshark.org?

Cheers,

Sake

----- Original Message -----
From: Dominic Tulley
To: Community support list for Wireshark
Sent: Wednesday, September 30, 2009 10:42 AM
Subject: Re: [Wireshark-users] Trouble with SSL dissector - got ithalf working!

Hi Sake,
Looking at the capture, I seem to have plenty of out of order packets so that would seem a good place to start. I don't think I am able to share the packet capture with you unfortunately.

I've just run editcap -d on my capture and I seem to have a fully decoded conversation now. So you've already provided some great help!
It surprised me a little that this worked though since I don't believe I have any duplicate packets - do you think editcap also re-sorts the packets to the order they should be in?

Is there no way to do this sorting of packets within wireshark? It's a bit frustrating to have to save every capture, convert it and reload it.

Thanks very much,

-Dominic

From:	"Sake Blok" <sake@xxxxxxxxxx>
To:	"Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Date:	29/09/2009 17:06
Subject:	Re: [Wireshark-users] Trouble with SSL dissector - got it half working!
Sent by:	wireshark-users-bounces@xxxxxxxxxxxxx

Hi Dominic,

The fact that you got it working for one of the two flows means that the key is ok, you are not using a DH cipher and that all packets of the SSL handshake are present in the trace (those are the 3 common problems with decrypting traffic). However, if the other flow does not decrypt, that could be caused by:

- a missing packet in that flow (unable to fix)
- the first tcp segment of the first SSL record received out-of-order (could be fixed with editcap and mergecap, but is not so trivial)
- duplicate packets in that flow (could be fixed by using 'editcap -d <infile> <outfile>')

If those are not the case, are you able to provide the capture file and the key? Or is this a production environment?

Cheers,

Sake

----- Original Message -----
From: Dominic Tulley
To: wireshark-users@xxxxxxxxxxxxx
Sent: Tuesday, September 29, 2009 11:26 AM
Subject: [Wireshark-users] Trouble with SSL dissector - got it half working!

After much trawling and experimentation I've almost managed to get the SSL dissector working but strangely I can only decode my incoming http requests (all the responses are still encrypted). I've tried using the "decode as" option to make it decode for the client port as well as the server port (although I didn't expect that to be necessary) and I've tried added the client ip address and socket as a second "private key" in the configuration. Neither helped.

I'd appreciate any suggestions - I'm happy to provide additional details if that would help.

Thanks,

-Dominic

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Next by Date: Re: [Wireshark-users] Tshark not displaying all ssl.records
Next by thread: Re: [Wireshark-users] Tshark not displaying all ssl.records
Index(es):
- Date
- Thread