[Wireshark-dev] SSL decryption breaks after retransmission
Hello, I just stumbled upon the known problem SSL decryption breaks after retransmission (http://www.wireshark.org/lists/wireshark-dev/200805/msg00067.html) with wireshark 1.6.5. I wonder if a patch for this issue is available? Is anybody working on this? Martin -- Dr. Martin Wilck PRIMERGY System Software Engineer x86 Server Engineering FUJITSU Fujitsu Technology Solutions GmbH Heinz-Nixdorf-Ring 1 33106 Paderborn, Germany Phone: ++49 5251 525 2796 Fax:++49 5251 525 2820 Email: martin.wi...@ts.fujitsu.com Internet: http://ts.fujitsu.com Company Details:http://ts.fujitsu.com/imprint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
2012/2/10 Martin Wilck martin.wi...@ts.fujitsu.com Hello, I just stumbled upon the known problem SSL decryption breaks after retransmission (http://www.wireshark.org/lists/wireshark-dev/200805/msg00067.html) with wireshark 1.6.5. I wonder if a patch for this issue is available? Is anybody working on this? I have made a patch and put it into the bug tracker about half a year ago. Now I think it could be implemented better than it is, but I have not discussed it with core developers and I've made it in a way to not break anything existing. It is done in the TCP desegment layer but needs some assistance from upper layer. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
On 02/10/2012 12:13 PM, Max Dmitrichenko wrote: I have made a patch and put it into the bug tracker about half a year ago. Thanks - I assume you're talking about https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 ? Martin -- Dr. Martin Wilck PRIMERGY System Software Engineer x86 Server Engineering FUJITSU Fujitsu Technology Solutions GmbH Heinz-Nixdorf-Ring 1 33106 Paderborn, Germany Phone: ++49 5251 525 2796 Fax:++49 5251 525 2820 Email: martin.wi...@ts.fujitsu.com Internet: http://ts.fujitsu.com Company Details:http://ts.fujitsu.com/imprint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
2012/2/10 Martin Wilck martin.wi...@ts.fujitsu.com On 02/10/2012 12:13 PM, Max Dmitrichenko wrote: I have made a patch and put it into the bug tracker about half a year ago. Thanks - I assume you're talking about https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 ? Yep! -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
On 02/10/2012 01:09 PM, Max Dmitrichenko wrote: Thanks - I assume you're talking about https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 ? Yep! I built wireshark with this patch applied, but it didn't solve my problem. I still need to tell wireshark manually to ignore the retransmitted packets in order to get proper SSL decryption of the follow-up SSL stream. Martin -- Dr. Martin Wilck PRIMERGY System Software Engineer x86 Server Engineering FUJITSU Fujitsu Technology Solutions GmbH Heinz-Nixdorf-Ring 1 33106 Paderborn, Germany Phone: ++49 5251 525 2796 Fax:++49 5251 525 2820 Email: martin.wi...@ts.fujitsu.com Internet: http://ts.fujitsu.com Company Details:http://ts.fujitsu.com/imprint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
2012/2/10 Martin Wilck martin.wi...@ts.fujitsu.com On 02/10/2012 01:09 PM, Max Dmitrichenko wrote: Thanks - I assume you're talking about https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 ? Yep! I built wireshark with this patch applied, but it didn't solve my problem. I still need to tell wireshark manually to ignore the retransmitted packets in order to get proper SSL decryption of the follow-up SSL stream. It will not work out of the box. A higher level dissector has to assist this and needs a patch. Actually the problem is that TCP is not a datagram but stream protocol. A subdissector for any protocol over TCP should not ignore this fact. In general, there are following cases. 0) Any TCP based dissector should be prepared to receive a TVB containing more than one logical PDU. 1) tvb contains a full logical PDU. Nothing to be done. 2) tvb contains the first part of logical PDU. Desegmentation needed. Currently TCP-desegmentor skips retransmissions of later parts. 3) tvb contains the second (or later) part of logical PDU or the first retransmitted part. Currently this is not handled. My patch is about to solve 3). You should patch the dissector to detect this situation and request the TCP-desegmentor to do the rest job. I guess this could be solved in out of the box way. But this will break the behavior of existing dissectors - they will not receive and dissect retransmissions which could be of someone's interest. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
Hi Sake, I was curious to know - Are you working on this? I just wanted to know because some work I am doing depends (slightly) on this and I will put comments in the code accordingly. Thanks! Abhik. On Thu, May 29, 2008 at 9:38 PM, Sake Blok [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. 1. Given that TCP is a streaming protocol, ISTR that a retransmitted frame can actually consist partially of bytes previously sent and partially of additional bytes not previously sent. If this is the case (and I'm not missing something), then presumably the tcp dissector would need to forward any new bytes of a frame. Yes indeed. When tcp reassembly is enabled, this will be taken care of unless the extra data is actually the start of a new upper layer PDU. I will either try to incorporate this case in my fix, or put some notes in the code that it should be fixed in the future. I think there will not be many cases where this happens... 2. How does re-assembly play into this discussion ? I haven't looked at the SSL dissector so I don't know how it works. Is re-assembly being used ? Doesn't re-assembly in effect take care of retransmissions (at least in some cases) ? It does, unless the retransmitted segment is the last part of the upper layer PDU (which of course includes the case where the PDU consists of only one tcp segment). Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
No problems... thanks for the update, Sake! On Mon, Jul 7, 2008 at 5:20 PM, Sake Blok [EMAIL PROTECTED] wrote: Abhik, I did take a look at it, but have not found the time yet to create a proper fix. Cheers, Sake On Mon, Jul 07, 2008 at 04:03:28PM +0400, Abhik Sarkar wrote: Hi Sake, I was curious to know - Are you working on this? I just wanted to know because some work I am doing depends (slightly) on this and I will put comments in the code accordingly. Thanks! Abhik. On Thu, May 29, 2008 at 9:38 PM, Sake Blok [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. 1. Given that TCP is a streaming protocol, ISTR that a retransmitted frame can actually consist partially of bytes previously sent and partially of additional bytes not previously sent. If this is the case (and I'm not missing something), then presumably the tcp dissector would need to forward any new bytes of a frame. Yes indeed. When tcp reassembly is enabled, this will be taken care of unless the extra data is actually the start of a new upper layer PDU. I will either try to incorporate this case in my fix, or put some notes in the code that it should be fixed in the future. I think there will not be many cases where this happens... 2. How does re-assembly play into this discussion ? I haven't looked at the SSL dissector so I don't know how it works. Is re-assembly being used ? Doesn't re-assembly in effect take care of retransmissions (at least in some cases) ? It does, unless the retransmitted segment is the last part of the upper layer PDU (which of course includes the case where the PDU consists of only one tcp segment). Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
I personally believe not passing retransmitted frames is a better choice, besides that its implementation is narrower, I see it as natural for a transport protocol not to pass retransmissions to the upper layer. All in all the user has a link in the packet details to the originally-transmitted frame if they need to see the dissection of the payload. L On Wed, May 28, 2008 at 10:24 PM, Sake Blok [EMAIL PROTECTED] wrote: On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote: On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: Today I noticed that SSL decryption breaks when there is a tcp retransmission. We never run out of things to fix, do we? :) It's a mixed up world, we should have all bugs fixed before the end of the day and never run out of beer... and *not* the other way around ;-) To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. Something about this just doesn't feel right. Well, at first no. But I reconsidered and to me it feels like the sensible way to go. All statistics will have duplicates when the retransmitted data is sent again to the upper layer dissector. (remember my session on Sharkfest, where enabling or disabling the tcp.desegment_tcp_streams preference gave different results). Dissecting the retransmitted data with the data dissector prevents these glitches. Also, on the system that received the packets, the data is sent to the upper layer only once (in case the ACK got lost and it indeed received the data twice). - Have a retransmitted_data flag in the frame-data structure which can be set by a dissector to warn the called dissector that the data is is receiving is actually a copy of earlier received data so that it can take proper action in dissecting it. I like this idea. The next protocol can then use it if necessary or ignore it. Yep, but that means having to change each and every dissector which has tcp as it's transport layer. - Accept that retransmitted frames will break SSL decryption and let the user delete the retransmitted frames themselves with editcap. Too much work for the user :). Agreed, have a look at the users-list, there is a thread in which this problem occurs :-) Any objections to the following fix: Have a preference in the tcp profile like show retransmitted frames as data with tooltip Dissecting the same fragment of data twice can disrupt the upper layer dissectors (ssl-decryption for example). By default this preference will be unchecked to not change the current behavior. Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
Sake Blok wrote: Any objections to the following fix: Have a preference in the tcp profile like show retransmitted frames as data with tooltip Dissecting the same fragment of data twice can disrupt the upper layer dissectors (ssl-decryption for example). By default this preference will be unchecked to not change the current behavior. How about something more like Don't pass retransmitted fragments... to make it clearer the effect of setting the option? (BTW I would think it should actually be defaulted to on.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
At Thu, 29 May 2008 11:04:02 -0400 (EDT), you wrote I personally believe not passing retransmitted frames is a better choice, besides that its implementation is narrower, I see it as natural for a transport protocol not to pass retransmissions to the upper layer. All in all the user has a link in the packet details to the originally-transmitted frame if they need to see the dissection of the payload. L On Wed, May 28, 2008 at 10:24 PM, Sake Blok [EMAIL PROTECTED] wrote: On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote: On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: Today I noticed that SSL decryption breaks when there is a tcp retransmission. We never run out of things to fix, do we? :) It's a mixed up world, we should have all bugs fixed before the end of the day and never run out of beer... and *not* the other way around ;-) To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. 1. Given that TCP is a streaming protocol, ISTR that a retransmitted frame can actually consist partially of bytes previously sent and partially of additional bytes not previously sent. If this is the case (and I'm not missing something), then presumably the tcp dissector would need to forward any new bytes of a frame. 2. How does re-assembly play into this discussion ? I haven't looked at the SSL dissector so I don't know how it works. Is re-assembly being used ? Doesn't re-assembly in effect take care of retransmissions (at least in some cases) ? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
On Thu, May 29, 2008 at 12:19:31PM -0400, Bill Meier wrote: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. 1. Given that TCP is a streaming protocol, ISTR that a retransmitted frame can actually consist partially of bytes previously sent and partially of additional bytes not previously sent. If this is the case (and I'm not missing something), then presumably the tcp dissector would need to forward any new bytes of a frame. Yes indeed. When tcp reassembly is enabled, this will be taken care of unless the extra data is actually the start of a new upper layer PDU. I will either try to incorporate this case in my fix, or put some notes in the code that it should be fixed in the future. I think there will not be many cases where this happens... 2. How does re-assembly play into this discussion ? I haven't looked at the SSL dissector so I don't know how it works. Is re-assembly being used ? Doesn't re-assembly in effect take care of retransmissions (at least in some cases) ? It does, unless the retransmitted segment is the last part of the upper layer PDU (which of course includes the case where the PDU consists of only one tcp segment). Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
On Tue, May 06, 2008 at 03:41:39PM -0600, Stephen Fisher wrote: On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: Today I noticed that SSL decryption breaks when there is a tcp retransmission. We never run out of things to fix, do we? :) It's a mixed up world, we should have all bugs fixed before the end of the day and never run out of beer... and *not* the other way around ;-) To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. Something about this just doesn't feel right. Well, at first no. But I reconsidered and to me it feels like the sensible way to go. All statistics will have duplicates when the retransmitted data is sent again to the upper layer dissector. (remember my session on Sharkfest, where enabling or disabling the tcp.desegment_tcp_streams preference gave different results). Dissecting the retransmitted data with the data dissector prevents these glitches. Also, on the system that received the packets, the data is sent to the upper layer only once (in case the ACK got lost and it indeed received the data twice). - Have a retransmitted_data flag in the frame-data structure which can be set by a dissector to warn the called dissector that the data is is receiving is actually a copy of earlier received data so that it can take proper action in dissecting it. I like this idea. The next protocol can then use it if necessary or ignore it. Yep, but that means having to change each and every dissector which has tcp as it's transport layer. - Accept that retransmitted frames will break SSL decryption and let the user delete the retransmitted frames themselves with editcap. Too much work for the user :). Agreed, have a look at the users-list, there is a thread in which this problem occurs :-) Any objections to the following fix: Have a preference in the tcp profile like show retransmitted frames as data with tooltip Dissecting the same fragment of data twice can disrupt the upper layer dissectors (ssl-decryption for example). By default this preference will be unchecked to not change the current behavior. Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] SSL decryption breaks after retransmission
Hi All, Today I noticed that SSL decryption breaks when there is a tcp retransmission. The retransmitted segment will be handled by the SSL dissector as if it was new data. The mac-check will fail, but the state of the SSL decrypter is left in an erroneous state, causing the dissection of all subsequent SSL records to fail. Of course on the receiving host, the TCP stack takes care of filtering out the retransmitted segment, so it's SSL stack will have an issue. To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. The change in behavior can be prevented with a preference, but I don't want to create a zillion preferences... - Have a retransmitted_data flag in the frame-data structure which can be set by a dissector to warn the called dissector that the data is is receiving is actually a copy of earlier received data so that it can take proper action in dissecting it. Since the flag only has meaning between the calling and the called dissector, I'm not so happy with it's presence in the frame-data structure. - Add code to the SSL dissector to get the TCP conversation data and check for the TCP analysis flag retransmission itself. But that would break the layered design of it all. - Accept that retransmitted frames will break SSL decryption and let the user delete the retransmitted frames themselves with editcap. For now, I think I would prefer option 1.What do you all think? Are there any other options that I haven't thought of? Cheers, Sake___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SSL decryption breaks after retransmission
On Tue, May 06, 2008 at 10:17:54PM +0200, Sake Blok wrote: Today I noticed that SSL decryption breaks when there is a tcp retransmission. We never run out of things to fix, do we? :) To solve this issue, I can think of several options: - Make the TCP dissector not forward retransmitted segments to higher layer protocols, just like the normal TCP stack will do on the receiving host. This will have a major impact on the way retransmitted frames are displayed. Then again, the fully dissected segment is already available. Something about this just doesn't feel right. - Have a retransmitted_data flag in the frame-data structure which can be set by a dissector to warn the called dissector that the data is is receiving is actually a copy of earlier received data so that it can take proper action in dissecting it. I like this idea. The next protocol can then use it if necessary or ignore it. Since the flag only has meaning between the calling and the called dissector, I'm not so happy with it's presence in the frame-data structure. The packet info struct is probably a better place for it based on what is already in epan/packet_info.h's declaration of packet_info. - Accept that retransmitted frames will break SSL decryption and let the user delete the retransmitted frames themselves with editcap. Too much work for the user :). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
