Search code examples
sslhttpstcp

Why this SSL connection ends abruptly

I am trying to make an HTTPS POST request. The connection ends abruptly at the very beginning. I took the following capture with Wireshark. 192.168.0.33 is my client attempting to connect to the server. 192.185.47.210 is the server.

No.     Time           Source                Destination           Protocol Length Info
     51 2.476681000    192.168.0.33          192.185.47.210        TCP      62     1143→443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
     52 2.534541000    192.185.47.210        192.168.0.33          TCP      62     443→1143 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1
     53 2.534559000    192.168.0.33          192.185.47.210        TCP      54     1143→443 [ACK] Seq=1 Ack=1 Win=65535 Len=0
     54 2.534720000    192.168.0.33          192.185.47.210        TLSv1    163    Client Hello
     56 2.592332000    192.185.47.210        192.168.0.33          TCP      60     443→1143 [ACK] Seq=1 Ack=110 Win=29200 Len=0
     57 2.594550000    192.185.47.210        192.168.0.33          TLSv1    191    Server Hello, Change Cipher Spec, Encrypted Handshake Message
     58 2.596455000    192.168.0.33          192.185.47.210        TCP      54     1143→443 [FIN, ACK] Seq=110 Ack=138 Win=65398 Len=0
     60 2.654542000    192.185.47.210        192.168.0.33          TCP      60     443→1143 [FIN, ACK] Seq=138 Ack=111 Win=29200 Len=0
     61 2.654558000    192.168.0.33          192.185.47.210        TCP      54     1143→443 [ACK] Seq=111 Ack=139 Win=65398 Len=0

I suspect the problem is with packet 57, because upon receiving this packet, client initiates a disconnect of the TCP connection. Packet 57 looks like 

Frame 57: 191 bytes on wire (1528 bits), 191 bytes captured (1528 bits) on interface 0
Ethernet II, Src: Actionte_39:b9:de (18:1b:eb:39:b9:de), Dst: CadmusCo_f6:2b:9b (08:00:27:f6:2b:9b)
Internet Protocol Version 4, Src: 192.185.47.210 (192.185.47.210), Dst: 192.168.0.33 (192.168.0.33)
Transmission Control Protocol, Src Port: 443 (443), Dst Port: 1143 (1143), Seq: 1, Ack: 110, Len: 137
Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 81
        Handshake Protocol: Server Hello
    TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Change Cipher Spec Message
    TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 40
        Handshake Protocol: Encrypted Handshake Message

Other info:

The client is a C# program running on Windows XP. The call is made by the WebRequest (https://msdn.microsoft.com/en-us/library/system.net.webrequest%28v=vs.110%29.aspx) class. The server is on shared hosting (Hostgator) with dedicated IP and an SSL certificate from COMODO.

Question

Can anyone help me understand why receiving packet 57 is causing the client to disconnect?

Solution

  • Based on this Q&A I linked to in comments, and the additional edited-in fact, that connection attempt is made by C# in Windows XP, the most likely reason is that verification against Trusted Roots might fail.

    The problem you're seeing might not appear in browsers; this could be surprising. It's so because web browsers typically provide their own set of trust data, in addition to what's in the system - and probably more up-to-date, whereas Windows has to rely on updates/service packs, which don't appear anymore (and even if, OS policy about these things might be a bit stricter than the browsers').

    The solution will be adding root to ones trusted by the system, or loading it programmatically in your application.