Forum Discussion
CirrostratusChrome fails to respond to SSL Server hello
Hi,
We're using a basic VS with SSL for a internal site, the clients are accessing the VS over an MPLS link. We dont have any proxies or SSL inspection devices in the path and this is only happening with the chrome browser but works fine with IE.
Is there anyway to gather more info about why this is happening maybe by using openssl or fiddler tool?
As this pcap shows the client is not responding after server hello done and then the f5 closes the connection after timing out.
And this is from the same pcap file where we see the client responding properly.
A normal SSL handshake.
Any other suggestions on what could be happening?
DanS92Cirrus
Based on the information given I can't tell if this is your problem, but on 10/16/2018 Chrome 70 was released. This update included the distrusting of Thawte, GeoTrust, and RapidSSL certificates. My company switched from Thawte to Digicert before this update was released. More info here: https://knowledge.digicert.com/alerts/ALERT2562.html
David_MHi Dan,
We're using digicert certs here and this same app works fine over the lan network and the internet.
- David_M
Hi Lidev,
I did ssldump -nr on the pcap as I do not have the keys right now to decrypt.
But I just see the same RSTs there and nothing specific, maybe I am missing something.
Also I see application data after serverhello done without the client key exchange msgs. .
I am looking at the connection 20.
New TCP connection #20: 10.12.119.147(52927) <-> 192.168.3.81(443) 19 1 0.0258 (0.0258) C>S Handshake ClientHello Version 3.3 resume [32]= 3e 86 32 ce 63 41 29 3d 44 cf a3 e4 61 9e e9 23 09 61 e9 86 de ed c7 23 29 c6 23 4d de 77 0e 05 cipher suites Unknown value 0x2a2a Unknown value 0x1301 Unknown value 0x1302 Unknown value 0x1303 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Unknown value 0xcca9 Unknown value 0xcca8 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 20 1 0.0264 (0.0264) C>S Handshake ClientHello Version 3.3 resume [32]= 01 5f 57 a0 b6 14 b7 ff 13 63 04 0f 5b 99 29 3c 42 a2 0f 51 2a 07 a0 24 2e 8d 68 64 ec b3 0c 81 cipher suites Unknown value 0xa0a Unknown value 0x1301 Unknown value 0x1302 Unknown value 0x1303 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Unknown value 0xcca9 Unknown value 0xcca8 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 19 2 0.0266 (0.0008) S>C Handshake ServerHello Version 3.3 session_id[32]= 20 ff 53 89 55 a3 a6 cc c9 86 dc 09 7f ab 0e 10 55 4d c2 22 93 bd d2 66 cb 67 56 bc cc bb de a5 cipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 compressionMethod NULL 19 3 0.0266 (0.0000) S>C Handshake Certificate 19 4 0.0266 (0.0000) S>C Handshake ServerKeyExchange 19 5 0.0266 (0.0000) S>C Handshake ServerHelloDone 20 2 0.0273 (0.0008) S>C Handshake ServerHello Version 3.3 session_id[32]= 38 37 2b 80 ed 5a fe 45 e1 be b0 8a 14 63 66 89 53 0a e9 03 aa 74 2c c4 e3 3f be 84 64 73 36 1d cipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 compressionMethod NULL 20 3 0.0273 (0.0000) S>C Handshake Certificate 20 4 0.0273 (0.0000) S>C Handshake ServerKeyExchange 20 5 0.0273 (0.0000) S>C Handshake ServerHelloDone 12 19 1.5286 (0.2182) C>S application_data 12 20 1.5373 (0.0086) S>C application_data 12 21 1.7430 (0.2057) C>S application_data 12 22 1.7536 (0.0105) S>C application_data 12 23 1.9602 (0.2066) C>S application_data 12 24 1.9679 (0.0077) S>C application_data 12 25 2.1770 (0.2091) C>S application_data 12 26 2.2036 (0.0265) S>C application_data 12 27 2.2036 (0.0000) S>C application_data 12 28 2.2036 (0.0000) S>C application_data 12 29 2.4217 (0.2181) C>S application_data 12 30 2.4349 (0.0131) S>C application_data 12 31 2.4349 (0.0000) S>C application_data 12 32 2.6403 (0.2053) C>S application_data 12 33 2.6522 (0.0118) S>C application_data 12 34 2.8569 (0.2047) C>S application_data 12 35 2.8708 (0.0138) S>C application_data 12 36 3.0776 (0.2067) C>S application_data 12 37 3.0878 (0.0101) S>C application_data 12 38 3.2913 (0.2035) C>S application_data 12 39 3.3268 (0.0354) S>C application_data 12 40 3.3268 (0.0000) S>C application_data 12 3.5435 (0.2166) C>S TCP FIN 12 3.5435 (0.0000) S>C TCP FIN New TCP connection #21: 192.168.2.31(61316) <-> 10.1.54.32(7779) 21 0.0045 (0.0045) C>S TCP FIN 21 0.0068 (0.0022) S>C TCP FIN New TCP connection #22: 192.168.2.31(54520) <-> 10.1.54.31(7779) 22 0.0058 (0.0058) C>S TCP FIN 22 0.0060 (0.0002) S>C TCP FIN 20 10.0023 (9.9750) S>C TCP RST 19 10.0025 (9.9759) S>C TCP RST 19 10.0025 (9.9759) S>C TCP RSTAttaching it here anyway.
Thanks.
- Lidev
Nacreous
Indeed, i don't see anything any clue on your ssldump.
Compare the Trusted Root store of the two browser, maybe the root CA cert or certificate chain is missing/corrupted on the Google Chrome trusted store for you internal website.
- David_M
Well this is not happening on just one pc but many over the mpls and it works fine on the same chrome and windows version when using on the lan network and the internet.
- David_M
Now I see some bad request response coming from the backend nodes.
so its
client: 10.12.119.147
VS: 192.168.3.81
server: 10.1.54.31 and 32
both 31 and 32 servers are doing this, but more of .31.
Right before the bad request response I see this PSH from the f5 to the server.
Thoughts?
