924898 - Random single URL fails to load after HTTPS negotiation

Status: RESOLVED INCOMPLETE

(Core :: Security: PSM, defect)

Description

[Damien]

Attachment: bad_url.pcapng

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

Internal application running on HTTPS works fine in other browsers but in FF occasionally a single asset or URL becomes stuck and spins as if it is still contacting the DNS server.  When it does occur it will be several people at once who experiences the same issue on the same URL a clear indication of some kind of DNS or network issue on our network -- more on this later. These same people can then successfully load the webpage in IE, can close and go back into FF with same issue on same specific URL.  Adding a random get variable on the URL will cause it to load, changing back to original URL same problem comes back.  It clears up after 24 hours for that user, after a browser upgrade and rarely a cache flush/browser restart will correct.  I've never seen this on websites outside our application but the volume is very high for some of these pages, FF might hit the same URL 30 times in an hour.  It appears to be an edge case, something particular in our network that causes FF to improperly cache or abandon trying some URLs.  When it occurs there is no error message and the browser never times out, it just spins.  This started after upgrading from FF 3, our computers are now running versions 21-24.  It occurs in our user base across multiple divisions, building and networks, the application is the same, it even occurs in the test environments.  This URL does not go through our firewall or proxy.
Thinking it was a DNS issue we have tested changing many of the browser settings such as dnsCacheExpiration, disabling IP6, enabling pipelining, etc and your common dns flushing and trying a different DNS server.  Our webserver lighttpd does not report the incoming request, debugging on the server shows nothing.  We tested changing various HTML headers as well.  Finally was able to get a packet dump from a computer running wireshark, this showed FF does correctly do the DNS lookup, correctly gets OCSP packets and is correctly starting HTTPS negotiations with the webserver.  The breakdown seems to occur after TLSv1 Change Cipher Spec, Encrypted handshake packets, in which FF does not properly then ask the webserver for the URL. Comparing a good URL in FF to one that spins the packets are nearly identical, leading me to suspect internally FF is cached something that prevents it from asking for the file again, even though it does begin communication with the webserver.  Some of the packet dumps I'm seeing TCP Retransmission messages, I think we have an internal issue where our network gets delayed and packets fall outside the TCP window this might be the source of the problem, the effect though is something in FF gets stuck and does not properly handle it.


Actual results:

URL spins like it is doing a DNS look up.


Expected results:

Page or asset should load.

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Is this still an issue?