Re: [Wireshark-users] Malformed SSL - Is it really?
On Thu, Apr 12, 2007 at 11:24:48PM -0400, Small, James wrote: > > > > > [Malformed Packet: SSL] > > > > > > > > Is the packet really malformed, or is it possible that Wireshark > > > > doesn't support the cipher being used? If so, is there any way to > > > > tell if the packet is really malformed versus Wireshark just not > > > > understanding it/the encryption scheme? > > > > Oh, it could also be that there are frames missing in the tcp-stream. > > That means the ssl-dissector can't reassemble it's stream properly > > and that creates a "malformed" packet. You can check this by > > disabling the "Allow subdissector to reassemble TCP streams" > > option in the tcp protocol preferences. The "malformed" message > > will then disappear. > > > > [Small, James] Sake, when I do that, these "SSL" frames no longer show > up as malformed, instead they show up as unreassembled: That's exactly what I was aiming at... > I guess I'm not sure if that's an error or not. I was capturing from > the client, but does that mean that a reply from the server might have > gotten lost and caused this problem? But if that were the case, I > should see a missing sequence number or retransmission in the stream > which I don't. Are you sure you see all packets of the tcp-session? Sometimes you do not see a retransmission because the endpoints did get all the data, but the capturing system did not (I have seen SPAN-ports drop 0,1% of packets, even on expensive hardware, I'm not sure if they still drop packets, but you always have to be aware that you might not see all the packets that were there). > > > Could you file this as a bug on bugzilla with a sample trace > > > (with the whole tcp-session if possible)? > > > > [Small, James] No problem if there's something wrong - at this point I'm > not sure. I'm not sure either, is it possible for you to filter out this one TCP-session and send it to the list (or me)? Cheers, Sake ___ Wireshark-users mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Malformed SSL - Is it really?
Hi Sake, > > > [Malformed Packet: SSL] > > > > > > Is the packet really malformed, or is it possible that Wireshark > > > doesn't support the cipher being used? If so, is there any way to > > > tell if the packet is really malformed versus Wireshark just not > > > understanding it/the encryption scheme? > > Oh, it could also be that there are frames missing in the tcp-stream. > That means the ssl-dissector can't reassemble it's stream properly > and that creates a "malformed" packet. You can check this by > disabling the "Allow subdissector to reassemble TCP streams" > option in the tcp protocol preferences. The "malformed" message > will then disappear. > [Small, James] Sake, when I do that, these "SSL" frames no longer show up as malformed, instead they show up as unreassembled: No. TimeSourceDestination Protocol Src Port Dst Port Delta Info 182 7.590722172.24.101.100172.24.100.107SSL 443 1096 0.099158[Unreassembled Packet] Frame 182 (1314 bytes on wire, 1314 bytes captured) Ethernet II, Src: StBernar_00:8c:e5 (00:07:e8:00:8c:e5), Dst: Dell_00:be:6b (00:12:3f:00:be:6b) Internet Protocol, Src: 172.24.101.100 (172.24.101.100), Dst: 172.24.100.107 (172.24.100.107) Transmission Control Protocol, Src Port: 3128 (3128), Dst Port: 1096 (1096), Seq: 2330, Ack: 1407, Len: 1260 Source port: 3128 (3128) Destination port: 1096 (1096) Sequence number: 2330(relative sequence number) [Next sequence number: 3590(relative sequence number)] Acknowledgement number: 1407(relative ack number) Header length: 20 bytes Flags: 0x10 (ACK) Window size: 65535 Checksum: 0x3d02 [correct] [SEQ/ACK analysis] Hypertext Transfer Protocol Secure Socket Layer [Unreassembled Packet: SSL] I guess I'm not sure if that's an error or not. I was capturing from the client, but does that mean that a reply from the server might have gotten lost and caused this problem? But if that were the case, I should see a missing sequence number or retransmission in the stream which I don't. Also, as you suspected, transmitting via port 3128 is to a proxy, in this case a St. Bernard iPrism Proxy Appliance. > > Could you file this as a bug on bugzilla with a sample trace > > (with the whole tcp-session if possible)? > [Small, James] No problem if there's something wrong - at this point I'm not sure. Thanks, --Jim ___ Wireshark-users mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Malformed SSL - Is it really?
On Thu, Apr 12, 2007 at 10:09:41PM +0200, Sake Blok wrote: > > Transmission Control Protocol, Src Port: 3128 (3128), Dst Port: 1136 > > (1136), Seq: 9184, Ack: 1341, Len: 1260 > > Hypertext Transfer Protocol > > Secure Socket Layer > > TLSv1 Record Layer: Application Data Protocol: http > > Content Type: Application Data (23) > > Version: TLS 1.0 (0x0301) > > Length: 1048 > > Encrypted Application Data: > > 986EF11CE4141826D529372C664768C27C0E749FFC4BB768... > > [Malformed Packet: SSL] > > > > Is the packet really malformed, or is it possible that Wireshark > > doesn't support the cipher being used? If so, is there any way to > > tell if the packet is really malformed versus Wireshark just not > > understanding it/the encryption scheme? Oh, it could also be that there are frames missing in the tcp-stream. That means the ssl-dissector can't reassemble it's stream properly and that creates a "malformed" packet. You can check this by disabling the "Allow subdissector to reassemble TCP streams" option in the tcp protocol preferences. The "malformed" message will then disappear. > Could you file this as a bug on bugzilla with a sample trace > (with the whole tcp-session if possible)? Only if it is not a reassembly issue of course :) Cheers, Sake ___ Wireshark-users mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Malformed SSL - Is it really?
On Tue, Apr 10, 2007 at 11:07:29AM -0400, Small, James wrote: > Hello, > > When using Wireshark 0.99.5 on Windows, sometimes I see: > [Malformed Packet: SSL] > > e.g.: > No. TimeSourceDestination Protocol Src > Port Dst Port Delta Info > 381 15.301101 172.24.101.100172.24.100.107TLSv1443 > 1136 0.017923Application Data, [Malformed Packet] > Frame 381 (1314 bytes on wire, 1314 bytes captured) > Arrival Time: Apr 10, 2007 10:20:40.195898000 > [Time delta from previous packet: 0.017923000 seconds] > [Time since reference or first frame: 15.301101000 seconds] > Frame Number: 381 > Packet Length: 1314 bytes > Capture Length: 1314 bytes > [Frame is marked: True] > [Protocols in frame: eth:ip:tcp:http:ssl] > [Coloring Rule Name: HTTP] > [Coloring Rule String: http || tcp.port == 80] > Ethernet II, Src: StBernar_00:8c:e5 (00:07:e8:00:8c:e5), Dst: Dell_00:be:6b > (00:12:3f:00:be:6b) > Internet Protocol, Src: 172.24.101.100 (172.24.101.100), Dst: 172.24.100.107 > (172.24.100.107) > Transmission Control Protocol, Src Port: 3128 (3128), Dst Port: 1136 (1136), > Seq: 9184, Ack: 1341, Len: 1260 > Hypertext Transfer Protocol > Secure Socket Layer > TLSv1 Record Layer: Application Data Protocol: http > Content Type: Application Data (23) > Version: TLS 1.0 (0x0301) > Length: 1048 > Encrypted Application Data: > 986EF11CE4141826D529372C664768C27C0E749FFC4BB768... > [Malformed Packet: SSL] > > Is the packet really malformed, or is it possible that Wireshark > doesn't support the cipher being used? If so, is there any way to > tell if the packet is really malformed versus Wireshark just not > understanding it/the encryption scheme? Hmmm... it does not look like an unsupported cipher, because then the whole session should be malformed. And next to that, Wireshark gives a message about unsupported ciphers... If you look at the frame info, it shows protocols in frame: [Protocols in frame: eth:ip:tcp:http:ssl] From the uses tcp-port (3128) it shows that this is a proxied SSL session (many proxies use 3128 as proxy-port). I think somehow the SSL dissector has problems with SSL over a proxy. Could you file this as a bug on bugzilla with a sample trace (with the whole tcp-session if possible)? Cheers, Sake ___ Wireshark-users mailing list [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-users
