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
[Wireshark-users] Malformed SSL - Is it really?
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? Thanks, --Jim ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
