Hello all, I've recently moved my website to an all HTTPS after purchasing an EV certificate from Starfield Technologies. Everything seems to go well until recently I discovered that a particular browser from a device (Stock browser from Android 4.x) is unable to access my website, showing the error "Connection PRoblem. A network error occured". Weirdly stock browser from older versions of Android such as 1.x and 2.x works fine.
Initially I thought that it was a certificate chaining problem, and I've included the full bundle provided by my SSL provider but still no go. Even tried changing different cipher, yet still did not fix the problem. Someone suggested to capture the handshake from my Android device and analyze the handshake. I've managed to install an app to capture the packets and uploaded the PCAP file to CloudShark. I am seeing a couple of Out-Of-Order and RST flags but don't know how to interpret them. https://www.cloudshark.org/captures/3efe30799215 Can anyone kindly help to take a look at the captured packets and determine what might be the cause for the stock browser from Android 4.x device unable to access my website? Thank you all for your time. asked 01 Apr '14, 20:59  raymondcc |
One Answer:
Hello, I've spent some time on the trace you provided, a real tough one I admit. The good thing is, TLS Handshake goes through so there is no problem with the certificates. The bad thing I believe is, that the TLS data gets tampered with when retransmission occurs and the encrypted data probably fails to decrypt so android closes the session after having received the first TLS Application data from the server. Quite a wild speculation you might think but I here is some evidence: Frame 36 is the Close Notify from android that starts the termination process of session tcp.port==49421 Frame 24 is a TSL application record 0x170301 with a length of 0x10a0 coming in as tcp.seq==3773 with a tcp.len==1292 Same happens for frames 35 and 38 - 38 being a 'retransmission' as well with data not being the same, even the tcp.len of the 'retransmitted' segment is different now! filter: (tcp.seq==3773 or tcp.seq==8941) and tcp.len gt 0 Now, who is retransmitting and why? Applying another filter on 'low ip.id' it becomes obvious that all inbound packets come through the same IP stack acting as a proxy: They arrive with a TTL of 16 and have incrementing ip.id even the originate from different servers (ip addresses). One more peculiarity is that the inbound SYN_ACKs do NOT HAVE ANY TCP options, not even MSS when they arrive at your android. Also an indication that some not-so-modern TCP stack is faking your real servers. Added comment: As only android_4x devices have this problem it might a software device within the android itself that is causing this ... I believe you need to fix or bypass this yet to be determined device. answered 02 Apr '14, 11:38  mrEEde edited 02 Apr '14, 13:06 |
Hi mrEEde, thanks for taking the time to analyze the captured packets. I've gone through the process of elimination and found that this error is caused by SPDY from LiteSpeed 5.0 RC1.
I've reported this bug to the LiteSpeed developers and they claim this will be fixed in RC2.
I guess it's never good to use Beta or Release Candidate on production servers.
Thanks again.
You're welcome. Glad to hear that you found the culprit. Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.