Created attachment 8642629 [details] certly.pcap User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150629114848 Steps to reproduce: I visit https://log.certly.io/ct/v1/get-roots using Firefox 39.0 (39.0+build5-0ubuntu0.14.04.1). This server currently seems to have a problem where the response is truncated after 32306 bytes using HTTP or 36774 bytes when using SPDY. The SPDY response ends with a RST_STREAM INTERNAL_ERROR. Actual results: The page loads and shows the truncated content briefly. Then the browser displays the screen: **Secure Connection Failed** The connection to log.certly.io was interrupted while the page was loading. • The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. • Please contact the website owners to inform them of this problem. I have attached a packet trace of the connection attempt. The relevant line from SSLKEYLOGFILE is: CLIENT_RANDOM d483851a6372c91f6105244e121df06b602ab89d0cf9590f4c0288875e1e6930 74497b585ef7b23d81cfcfbf624d1c3e0f09252b26bb6ed3baef51f18b6ad3a7432f942ff2c774fa07662fc1afb7534f When setting network.http.spdy.enabled to false, this message does not popup. Expected results: Well... I'm not sure. I don't know enough about SPDY and whether it might have a built-in integrity check but as a security researcher I don't really expect to see a "Secure Connection Failed" message when the server is just failing to communicate properly. As far as I can tell there's nothing wrong with the TLS frames being sent.
@ Jethro, thanks for reporting this problem! @ Patrick, what do you think of this SPDY error? Chrome and Safari show truncated JSON data. Showing truncated data without an indication that the data is incomplete seems like a bad idea. MS Edge shows a network error similar to Firefox's. IE11 tries to download the JSON data as a file, but aborts the download with a network error.
status-firefox39: --- → affected
status-firefox40: --- → affected
status-firefox41: --- → affected
status-firefox42: --- → affected
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Awesome bug report and repro - thanks! So this data isn't simply truncated (i.e closed connection) but is actually being reported explicitly as being aborted. nginx is sending a RST_INTERNAL_ERROR for that stream. In general with h2 (and spdy) we're trying to take a harder line on errors like this to avoid a degradation of the protocol into a "it sort of works" state like happened to http/1. The network stack is returning NS_ERROR_NET_INTERRUPT in OnStopRequest(), which seems to be the right thing to do and the localized text you are seeing is at least accurate. As to whether that is the right handling of this at UX, I think that's more of a call for steve workman's team..
Component: Networking: HTTP → Security: PSM
Flags: needinfo?(mcmanus) → needinfo?(sworkman)
Summary: Connection reset with SPDY/TLS results in Secure Connection Failed message → RST_STREAM with SPDY/TLS results in Secure Connection Failed message
Thanks folks! Keeler, can you take a look at this one please?
Flags: needinfo?(sworkman) → needinfo?(dkeeler)
We could probably make the UX more elucidating, but in terms of security, I think this is the correct behavior.
I think this will be handled by bug 1273708.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1273708
You need to log in before you can comment on or make changes to this bug.