This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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.

A network error occured

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's gravatar image

raymondcc
11112
accept rate: 0%


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
Frame 27 is a Fast Retransmission of tcp.seq==3773 but this time the data portion is no longer a 0x170301 but starts with 0x26992!

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?
I don't tink that it is really the server as the retransmissions occur too fast for the RTT! Also the 'Fast Retransmission occurs without any duplicate ACKs being sent in your trace!

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. alt text

permanent link

answered 02 Apr '14, 11:38

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

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.

(02 Apr '14, 20:53) raymondcc

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.

(03 Apr '14, 09:24) mrEEde
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×319
×69

question asked: 01 Apr '14, 20:59

question was seen: 2,691 times

last updated: 03 Apr '14, 09:24

p​o​w​e​r​e​d by O​S​Q​A