No Server Hello, Certificate, but works

Question

Running version 1.8.0. I have a trace of my client connecting to its server successfully. The WireShark trace does not have a Server Hello, Certificate, Server Hello Done. There is a Client Hello, followed by 1494 bytes [TCP segment of a reassembled PDU] followed by 967 bytes of "Ignored unknown Record" followed by Client Key Exchange. I can see the certificate info in the data preceding the Client Key Exchange but Wireshark doesn't recognize it. The operation works, but Wireshark isn't decoding the packets correctly.

I'd attach the trace data but I can't figure how to.

Answer 1

0

There is a problem with your capture file.

Capture file with Filter tcp.stream eq 2, AND with duplicate packets

http://cloudshark.org/captures/492b22ee7f57

Look at Frame #2 and #3. It's the same packet with a different source MAC address.

Frame #2 MAC address: Source: Netgear_51:c0:54 (e0:91:f5:51:c0:54)
Frame #3 MAC address: Source: PcPartne_31:0c:a6 (00:01:2e:31:0c:a6)

Do you have any explanation for this?
That MAC address (00:01:2e:31:0c:a6) appears several times in the capture file with different IP addresses!! Maybe some kind of MAC/IP spoofing. Please check !!!

http://cloudshark.org/captures/6a47effe6552?filter=eth.addr%20%3D%3D%2000%3A01%3A2e%3A31%3A0c%3Aa6

Can you identify that MAC address on your network?
The subject in the certificate you got is different than in my test with curl.

curl test: Certificate (id-at-commonName=207.25.252.200,id-at-organizationName=IBM,id-at-localityName=Armonk,id-at-stateOrProvinceName=New York,id-at-countryName=US,id-at-serialNumber=fleRakbayAlG8AP-jh3-xkyBPpwYMPab)
your capture: Certificate (id-at-commonName=207.25.252.200,id-at-organizationName=IBM,id-at-localityName=Armonk,id-at-stateOrProvinceName=New York,id-at-countryName=US,id-at-serialNumber=izt26fL9ceWum7uCe3Wzwh/g7mXtrFsH)

Strange. Either the server hands out different certs for different geo regions (can somebody else please check), or 'something' is tampering with your SSL connection. Together with the duplicate packets, this looks at least kind of strange !??!

do you get SSL warnings in the browser?
How did you capture?

SOLUTION: If I remove the duplicate packets with MAC address 00:01:2e:31:0c:a6, the SSL dissector detects the Server Hello.

Capture file with Filter tcp.stream eq 2 and not eth.src == 00:01:2e:31:0c:a6

http://cloudshark.org/captures/ced9c9b5bd11

HINT: You will see the Server Hello only, if you save the filtered packets and re-open it in Wireshark.

I'm not sure if this is a bug in Wireshark or not. You could file a bug report at https://bugs.wireshark.org/bugzilla/ and upload both capture files (links above) and a reference (link) to this question.

At least the duplicate packets are more than strange and could cause "confusion" in the SSL dissector.

Regards
Kurt

answered 27 Jun '12, 14:29

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 27 Jun '12, 15:02

The server machine has two network interfaces. One is hard wired and the other is WiFi. Could this be my problem? I never thought about it or even looked at the MAC addresses.

What is curl?

I've only uploaded the one capture file I saved.

I'll disable the WiFi interface and see what happens.

(27 Jun '12, 14:39) tcoder

One is hard wired and the other is WiFi. Could this be my problem?

In general yes, but your capture file looks really strange. Several packets with different IP addresses but with the same MAC address. This is either a bug in the capture engine, or someone is doing MAC/IP spoofing on your network. You should really try to find that MAC address on the network. Ask the network admins.

What is curl?

A commandline HTTP(S) client: http://curl.haxx.se

I'll disable the WiFi interface and see what happens.

Good luck!

(27 Jun '12, 14:50) Kurt Knochner ♦

From this question:

You mentioned the two MAC addresses. One is the MAC of the router and the other is the MAC of the Ethernet card in the server. They are the two MACs between the router and the server.

regarding the MAC address of the router: What is your netmask on the LAN?

Based on your capture file I would say, that this MAC address is the one of your netgear router (Netgear_51:c0:54 (e0:91:f5:51:c0:54) and this is the MAC address of your client (Ibm_24:4c:f4 (00:0d:60:24:4c:f4)) found in Frame #1. Is that correct?

If so, then who owns this MAC address on your network (the duplicate packets): PcPartne_31:0c:a6 (00:01:2e:31:0c:a6), found in Frame #3? PcPartner is a manufacturer of motherboards. That's most certainly not your router, is it?

I wonder why there have been these duplicate packets. Did you find an explanation for it or did you find that device on the network? That still looks strange.

(28 Jun '12, 01:37) Kurt Knochner ♦

As far as the duplicate packets go, I've always had them.

I could put the server on another machine in the same network or I can disable the routers connection to the Internet.

My netmask is 255.255.255.0

Server is PcPartne_31:0c:a6 (00:01:2e:31:0c:a6) 192.168.5.104.

Netgear router Netgear_51:c0:54 (e0:91:f5:51:c0:54) FVS318G

Client is Ibm_24:4c:f4 (00:0d:60:24:4c:f4)) 192.168.5.103

Why would the Netgear router be reporting? I looked at other traces I have and they also show duplicate packets. I will look into this.

As far as the capture file goes, I'm using Wireshark version 1.8.0.

(28 Jun '12, 08:39) tcoder

Let's walk through it:

Frame #1:

Src IP: 192.168.5.103 :: Client
Dst IP: 207.25.252.200 :: Internet server

Src MAC: Ibm_24:4c:f4 (00:0d:60:24:4c:f4) :: Client
Dst MAC: Netgear_51:c0:54 (e0:91:f5:51:c0:54) :: Router

That's all O.K.

Frame #2:

Src IP: 207.25.252.200 :: Internet server
Dst IP: 192.168.5.103 :: Client

Src MAC: Netgear_51:c0:54 (e0:91:f5:51:c0:54) :: Router
Dst MAC: Ibm_24:4c:f4 (00:0d:60:24:4c:f4) :: Client

That's all O.K.

Frame #3:

Src IP: 207.25.252.200 :: Internet server
Dst IP: 192.168.5.103 :: Client

Src MAC: PcPartne_31:0c:a6 (00:01:2e:31:0c:a6) :: Server
Dst MAC: Ibm_24:4c:f4 (00:0d:60:24:4c:f4) :: Client

That's NOT O.K. How comes your server (192.168.5.104) is involved here? It should not interfere with a connection between an internal client and a system on the internet.

Without further information, it's hard to understand what's going on. If you look at the capture file, you will see a lot of packets with the MAC address of the server, but with a different IP address.

What is the OS of your server?
You said, that the server has several interfaces. What is the output of: ifconfig -a (Linux) or ipconfig /all (Windows)?
What is the default route on your clients (according to the capture file it should be the netgear router).
Do you mirror traffic (on a switch) to the interfaces of the server? Maybe it just forwards those mirrored packets !??!
Where did you capture the traffic? Client, Server, different PC?

(28 Jun '12, 11:17) Kurt Knochner ♦

The OS is WindowsXP

Windows IP Configuration

    Host Name . . . . . . . . . . . . : pds-1
    Primary Dns Suffix  . . . . . . . :
    Node Type . . . . . . . . . . . . : Unknown
    IP Routing Enabled. . . . . . . . : No
    WINS Proxy Enabled. . . . . . . . : No
    DNS Suffix Search List. . . . . . : netgear.com

(28 Jun '12, 11:26) tcoder

I can't get the rest of the ipconfig /all on here because there is not enough characters allotted.

The default route is through the Netgear router. I'm not mirroring traffic.

I just found that 00:01:2E:31:0C:A6 IP = 192.168.5.10 is my monitoring PC. How can I stop it from being a part of the trace?

I can't trace from the HMC as it is a Linux OS and you can't break into the form and execute other programs. It's totally locked from running terminal commands.

(28 Jun '12, 11:52) tcoder

I have the HMC, server and my monitoring PC connected to a Netgear hub. The hub output goes to the Netgear router model FVS318G. The reason for the hub is so I can monitor the traffic. If I connected them directly to the router, I couldn't see the traffic. It looks like most tcp packets get resent.

Could the hub be causing the problem?

(28 Jun '12, 12:01) tcoder

I just found that 00:01:2E:31:0C:A6 IP = 192.168.5.10 is my monitoring PC

Did'nt you say it's the server?

I can't get the rest of the ipconfig /all on here because there is not enough characters allotted.

Post it as an answer. I will convert it to a comment. Please post the output of ipconfig /all on the capturing PC.

If the monitoring PC is a Windows system, disable the TCP/IP binding on the adpater where you are capturing. Open the properties of your LAN adapter and uncheck the TCP/IP binding. You can still capture on that interface, but it will not interact with the network.

(28 Jun '12, 13:47) Kurt Knochner ♦

I realized that I gave you wrong info for the server IP and MAC address. I had the server PC on TeamViewer and didn't realize that I was actually looking at my PC. What it should have been is: Server MAC 00:01:2E:2C:D0:5C IP = 192.168.5.104 and my PC MAC 00:01:2E:31:0C:A6 IP = 192.168.5.10 (monitoring PC). I'm sorry for the bad info.

(28 Jun '12, 13:55) tcoder

can you please ping the following systems from your client (192.168.5.103) and the post the output of arp -a

192.168.5.104
192.168.5.10

(28 Jun '12, 13:56) Kurt Knochner ♦

I'm sorry for the bad info.

never mind. I don't need the output of arp -a anymore.

BTW: Does your capturing PC have two interfaces as well? If so, what's the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter?

(28 Jun '12, 13:57) Kurt Knochner ♦

Yes, it has the motherboard connection (192.168.5.10) and a wireless connection (192.168.1.11). It's also running Windows7.

The value of IPEnableRouter does not exist. The possible values are Adapters, DNSRegisteredAdapters, Interfaces, PersistentRoutes and Winsock.

As for pinging from the client of 192.168.5.103, I can't because I can't break into the program. It's running Linux and they made it so no one could get out of the program. I can however, boot up KNOPPIX and do it from there.

(28 Jun '12, 14:56) tcoder

Here is the arp command from the monitoring PC Interface: 192.168.5.10 --- 0xa Internet Address Physical Address Type 192.168.5.1 e0-91-f5-51-c0-54 dynamic 192.168.5.100 00-90-a9-5e-c2-c8 dynamic 192.168.5.101 c4-3d-c7-98-2a-12 dynamic 192.168.5.103 00-0d-60-24-23-a9 dynamic 192.168.5.104 00-01-2e-2c-d0-5c dynamic 192.168.5.255 ff-ff-ff-ff-ff-ff static

(28 Jun '12, 14:59) tcoder

Interface: 192.168.1.11 --- 0x18 Internet Address Physical Address Type 192.168.1.1 c4-3d-c7-98-2a-11 dynamic 192.168.1.6 00-26-ab-89-b1-36 dynamic 192.168.1.7 2c-81-58-f1-33-51 dynamic 192.168.1.12 00-12-7b-4c-f1-8b dynamic 192.168.1.14 c0-cb-38-67-98-26 dynamic 192.168.1.16 00-0d-4b-63-10-f3 dynamic 192.168.1.19 5c-d9-98-04-20-93 dynamic 192.168.1.255 ff-ff-ff-ff-ff-ff static

(28 Jun '12, 15:00) tcoder

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\Terry>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : TERRY-DESKTOP
Primary Dns Suffix  . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : Yes  <<===== HERE !!
WINS Proxy Enabled. . . . . . . . : No

(28 Jun ‘12, 18:47) tcoder

As you can see, IP Routing is enabled on your machine. I believe your sniffer PC forwards the packets it sees in promicuous mode (capturing mode), as it ‘thinks’ it is a router. I wonder why the registry value does not exist on that system!??! Please check again. Search for ‘IPEnableRouter’ in regedit.

Anyway, this makes all sense now. Simple solution: Disable the TCP/IP bindings on the LAN adapter and capture again. You should not see duplicate packets.

(28 Jun ‘12, 23:11) Kurt Knochner ♦

showing 5 of 17 show 12 more comments

Answer 2

Every packet from the server is sent twice, once through the router and once direct. If you select all the directly sent packets (filter: eth.src == 00:01:2e:31:0c:a6) and then Ignore them from dissection (Edit -> Ignore All Displayed Packets), then Wireshark is able to dissect the SSL traffic perfectly.

Wireshark does not handle SSL reassembly well when there are retransmissions (or "duplicates" as in this tracefle.