We have software that tries to make a connection to a third party. The software was utilizing the Microsoft MSXML HTTP object to make HTTP POSTs. Recently the third party disabled the SSLv3 protocol and will be disabling TLS 1.0 in the near future. After the SSLv3 protocol disabling, one of our clients has 2 Windows 7 PCs that fail to make the connection to the third party server, but 1 Windows 7 PC that is successful. Numerous other clients with different OSes have no issue.
Figuring it might have been an issue in the MSXML HTTP object, I wrote a test application using the Chilkat ActiveX library we have access to. This test application connects without issue to the third party on my Windows 10 PC, on a separate client's Windows 7 PC (that is not having this issue), and on the 1 Windows PC that can still connect at the client having this connection issue. However, the other 2 PCs get an error during the clientHandshake2 process according to the log. We have numerous other clients who have no issues with this connection, it is just this one client with 2 PCs that don't work and 1 PC that does with all 3 PCs going through the same network.
1) Does Chilkat use OS level components to make the HTTP connection. For example, Windows XP cannot make TLS 1.1 or TLS 1.2 connections because it is limited to TLS 1.0 in the OS and all Windows components are affected. Could Chilkat make a TLS 1.1 or TLS 1.2 connection on a Windows XP machine? I ask this because we may have some clients that do work right now but will fail when the third party disables TLS 1.0 due to having Win XP or Win Vista clients.
2) What would prevent a handshake on PCs similar to another PC with the same OS allowing the handshake? Here is the snippet of the log where the handshake fails:
clientHandshake(20000ms): The client cert chain is NULL. cacheClientCerts: Cached TLS client certificates. Client cert chain is NULL. --cacheClientCerts clientHandshake2(20000ms): readHandshakeMessages(20000ms): sockRecv: Socket operation timeout. Failed to read beginning of SSL/TLS record. b: 0 dbSize: 0 nReadNBytes: 0 --readHandshakeMessages --clientHandshake2 --clientHandshake Client handshake failed. (3)
Here is a successful handshake log (I have forced Chilkat to use TLS 1.2 protocol in the test):
clientHandshake(203ms): The client cert chain is NULL. cacheClientCerts: Cached TLS client certificates. Client cert chain is NULL. --cacheClientCertsclientHandshake2(203ms): readHandshakeMessages(78ms): processHandshakeRecord: processHandshakeMessage: processServerHello: negotiatedTlsVersion: TLS 1.2 negotiatedCipherSuite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 minAcceptableRsaKeySize: 1024 --processServerHello --processHandshakeMessage --processHandshakeRecord --readHandshakeMessages Sending 0-length certificate (this is normal). sendClientCertificates: buildCertificatesMessage: numCerts: 0 --buildCertificatesMessage --sendClientCertificates buildClientKeyExchange(16ms): buildClientKeyExchangeECDHE(16ms): verifyServerKeyExchange: verifyHash: keyType: Public hashInSize: 32 padding: PKCS v1.5 HashOid: 2.16.8126.96.36.199.4.2.1 --verifyHash --verifyServerKeyExchange Verified server key exchange. generateNewKey_ecc(16ms): loadCurveByName: name: secp256r1 --loadCurveByName --generateNewKey_ecc loadSshPubKey: loadCurveByName: name: secp256r1 --loadCurveByName --loadSshPubKey --buildClientKeyExchangeECDHE --buildClientKeyExchange --clientHandshake2 --clientHandshake
Both the successful and erroring clients are running version 188.8.131.52 of the Chilkat ActiveX single DLL, so it does not seem to be version issue. Both clients are Win 7 Pro 32 bit as well.
I've seen this behavior caused by Anti-Virus blocking the outgoing connection, and very few times, the returning connection. Sometimes this can also happen if the problem workstation shares an IP with another workstation on the network.
This ended up being that the IT at our client had only allowed the 1 PC access to connect outside the environment. As soon as they added the other 2 PCs with the same credentials, this worked just fine.