1362986 - HTTP stack does not respond to FIN with close() in https://

Status: RESOLVED INCOMPLETE

(Core :: Networking: HTTP, defect, P2)

Description

[Yosha]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170413192749

Steps to reproduce:

	Firefox does not send out a [FIN, ACK] packet in reply to server's [FIN, PSH, ACK] packet.
	
	We are testing HTTPS SSL handshakes over various browsers for our web server. IE and Chrome work fine but there is a rough 3-5 seconds delay while browsing with Firefox browser.
	After analysing the issue, I found that the issue is that the firefox browser is not sending a [FIN, ACK] packet reply to server's [FIN, PSH, ACK] packet. 
	Server is timing out and sending a [RST] packet.
	
	This is a rough scenario for the HTTPS connection between firefox and web server :

		1. Firefox sends a SYN packet to Server.
		2. Server replies with [SYN, ACK]
		3. Firefox sends [ACK].
		4. Firefox sends a Client hello.
		5. Server replies back with server hello, Cipher spec.
		6. Application data is exchanged between firefox and server.
		7. Server sends a [FIN, PSH, ACK] packet to firefox.
		8. Firefox replies with [ACK] packet.
		9. Firefox sends another Client Hello packet from another socket.
		10. But server does not reply bec it is still waiting on Firefox's [FIN] packet for previous socket.
		11. After 5 seconds Server sends a RST packet.
		12. Server then replies with server hello to the new connection from the new socket.
		
	So the question is why is firefox not sending a FIN packet to web server ?
	This issue is not seen in HTTP connection. It sends it in HTTP connection in reply to HTTP ok packet.
	
	Note that the HTTPS connection is with a self signed certificate if that helps. Tried the scenario with both adding an exception and then adding it to trusted authorities.



Actual results:

Firefox is not sending a FIN packet in reply to server's FIN packet


Expected results:

Firefox should send a FIN packet in reply to server's FIN packet

Comment 1

[Patrick McManus [:mcmanus]]

sounds like a bug in that we aren't reading the FIN at the HTTP level to initiate a socket close.

Having a URL to test against would help alot.

you could work around it by sending a TLS-Alert I bet.

10 is a server bug tho. Those connections are independent and need to be scheduled that way. (what if, for example, the client FIN were just a dropped packet and needed to be retransmitted.. you don't want to block on that.)

Comment 2

[Yosha]

Unfortunately our server is still under testing so the URL is not yet open globally. This issue was observed during our internal testing.

The information provided by me may not be enough. But if you can give me pointers on what would help to get to bottom of this issue, I can try to debug this issue.

Thank you.

Comment 3

[Patrick McManus [:mcmanus]]

your best tools are

1] nspr log (about:networking)
2] a packet capture made with either tcpdump or wireshark
3] the SSLKEYLOGFILE which will allow wireshark to decode the packet trace from #2 (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format)

Comment 4

[Dragana Damjanovic [:dragana]]

Any news, log, a test url? Or is this fix?

Comment 5

[Yosha]

Packet capture did not help. I have already tested it with packet capture and then raised bug.

I will post as soon as i get any new information.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[Patrick McManus [:mcmanus]]

we need an nspr log to move forward here.. feel free to reopen with log added