Ask Your Question
0

TLS 1.2 connection problems

asked 2021-04-18 15:09:47 +0000

timvdh gravatar image

I am trying to establish a TLS 1.2 connection via a machine certificate. This works fine on one machine:

3.590109    ClientIp    ServerIp    TLSv1.2 221 Client Hello
3.617942    ServerIp    ClientIp    TLSv1.2 1514    Server Hello
3.618151    ServerIp    ClientIp    TLSv1.2 1143    Certificate, Server Key Exchange, Certificate Request, Server Hello Done
3.627569    ClientIp    ServerIp    TLSv1.2 3593    Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
3.660094    ServerIp    ClientIp    TLSv1.2 105 Change Cipher Spec, Encrypted Handshake Message

Connection established, data flowing. This machine does not use a proxy. The exact same client (a .NET program) on different machine is not so lucky, I can see in Wireshark that the client just does not not seem to answer to the server's certificate request:

10.792079   ClientIp    ProxyIp TLSv1.2 221 Client Hello
10.827628   ServerIp    ClientIp    TLSv1.2 1374    Server Hello
10.827753   ServerIp    ClientIp    TLSv1.2 1374    Certificate [TCP segment of a reassembled PDU]
10.827840   ServerIp    ClientIp    TLSv1.2 103 Server Key Exchange, Certificate Request, Server Hello Done

Then the client reports "The request was aborted: Could not create SSL/TLS secure channel".

The only hint I am seeing is the [TCP segment of a reassembled PDU] message, which I am only (and always) seeing on the machine where the client is not connecting. I read that this just means that Wireshark reassembled packets and that it may not point to any protocol errors, however, maybe it means something since it never appears with the client that can connect?

edit retag flag offensive close merge delete

Comments

It's easier to analyze if you can share pcaps.
On what system (or part of the network) are the captures made?
What is the system ProxyIp? Should the server be communicating back through the proxy?

Chuckc gravatar imageChuckc ( 2021-04-18 16:13:04 +0000 )edit

Sorry, I would not know how to clean the pcaps (are they "anonymizable") and this is in my customer's network. I made the captures on one Windows 10 PC in the customer network (where it does not work) and on one Windows 10 PC at home (no problems there). But another W10 machine in the same customer network can connect with the exact same software / configuration (cannot provide wireshark info for that before tomorrow). The customer is using a proxy (I made a mistake there and edited that now), so the proxy ip will show up in wireshark. Yes, the server should communicate through the proxy.

timvdh gravatar imagetimvdh ( 2021-04-18 16:36:51 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-04-19 17:25:58 +0000

SYN-bit gravatar image

It seems the two examples use a different TCP/MSS value. In the first (working) example, it seems to be the default 1460. In the second example, it seems to be 1320. That is probably the reason why you see the "[TCP segment of a reassembled PDU]" only in one of the two examples, although it does seem weird. Are you using the same wireshark version for viewing these two examples?

In your output, the clienthello is to the proxyip (and so was the 3-way-handshake I assume), but the serverhello/certificate/etc are directly from the server back to the client. The client will not recognize these packets as it has a connection to the proxyip, not the serverip.

I think the proxy should do source NAT for requests coming from the local network.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-04-18 15:09:47 +0000

Seen: 1,095 times

Last updated: Apr 19 '21