New issue 67565 by evan.leonard: Error 324 (net::ERR_EMPTY_RESPONSE)
http://code.google.com/p/chromium/issues/detail?id=67565
Chrome Version : 8.0.552.231
URLs (if applicable) : any with SSL
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: OK
Firefox 3.x: OK
IE 7/8:n/a
What steps will reproduce the problem?
1. Open Chrome
2. Navigate to a site requiring SSL (for instance an Atlassian Jira or
Confluence instance w/ SSL)
3. Observe 324 error
What is the expected result?
What happens instead?
Please provide any additional information below. Attach a screenshot if
possible.
Here's the results from using: chrome://net-internals/#tests on a failing
url
Result Experiment Error Time (ms)
FAIL Fetch https://wiki.<mycompany>.com/
Don't use any proxy
-324 424
FAIL Fetch https://wiki.progress.com/
Use system proxy settings
-324 538
FAIL Fetch https://wiki.progress.com/
Use Firefox's proxy settings
-324 454
Fetch https://wiki.progress.com/
Auto-detect proxy settings
? ?
Through a little investigation I found that if I start up like this with
the -use-system-ssl then everything works OK:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
-psn_0_4547670 --flag-switches-begin -use-system-ssl --flag-switches-end
Here are the webserver details:
Apache: 2.0.63
Tomcat: 6.0.18
ClearSpace: 2.5.17
JRE: 1.6
Apparently Chrome 8.0.552.224 works with these apps, but the version of
Chrome I'm using (8.0.552.231) does not.
Apache with mod_ssl uses OpenSSL, which certainly doesn't have any issues
with False Start. Also, no changes to False Start (except to add
giltcdn.com to the blacklist) were made between 552.224 and 552.231.
Are you sure that it's really an Apache server which is terminating the
connections?
I'm having the same issue as well with https on my site. When I use
-use-system-ssl my site loads without a problem. Once I have the page
cached I can close the browser and start a new session without the switch
and the https page will load.
However, if I click on the icon in the address bar to see certificate
details I have this message "the connection had to be retried using ssl
3.0. this typically means that the server is using very old software and
may have other security issues"
If I clear cache, or refresh enough times, I once again cannot connect to
https.
I'm not sure if this is a server issue or a browser issue, but https will
load in all other browsers.
bugsy2334: what is the URL?
Can I send to you privately so it's not publicly shown?
bugsy2334: Of course you can always email private information and, if you
so desire, use http://www.imperialviolet.org/key.asc
ser...@bitpalast.de: the issue with FreeBSD, and the maintainers of the
FreeBSD port concur, is that your servers are miscomputed. You are linking
against a different major version of OpenSSL than you compiled against.
This is causing memory corruption in your servers and is probably an
exploitable issue.
Given the reply: a) Why do other browsers work problem-free? b) If the
maintainers of the FreeBSD port concur, what are the exact steps to resolve
the problem on the FreeBSD platform?
We did of course test and re-compiled an Apache 2.2.17 and OpenSSL 1.0.0.4
last night, but the problem persists. What instructions or parameters need
to be given to resolve the problem?
Thank you very much for your reply. I have escalated the issue to our
datacenter experts. I know you are doing your best in developing a great
browser. But anyway, in this specific case I would kindly like to ask you
to reconsider your decision. Here is my argumentation:
A) Consider hundreds of thousands of FreeBSD/Apache 2 installations out in
the market that will need to be re-compiled/re-installed. This will cause
hundreds of thousands of work hours and therefore will have a global
economic impact. This bug will also have serious implications on the use of
Chrome in many companies. It will limit the market share that Chrome can
reach. You can tell that from Evan's comment #16 already.
B) Then in comparison to this huge impact and negative impact on the
distribution and market share of Chrome think about the very small effort
it would take to add a simple if-then decision in Chrome, e.g.
if ((324 Empty Response) && (SSL connection)) {
[run same procedure again but omit false start];
}
Why wouldn't you as developers not want to add such a simple switch. It
appears to me to be a much better solution than maintaining black lists
that will soon increase to thousands of URLs. Please give this a second
thought. What was first? FreeBSD/Apache or Chrome? We here believe that a
new browser should be compatible to what's already in the market and not
that the whole world should update their it infrastructure to match a new
browser. I much hope that you take a minute to address this bug with a
work-around IN Chrome.
Firstly, your issue isn't related to False Start, it's TLS compression
which is causing you problems.
We know from experience that adding workarounds doesn't help: the problems
that get worked around don't get fixed. We are still dealing with servers
that can't correctly implement ten year old standards even today.
Additionally, we certainly wouldn't want to add a workaround for this. It
would just leave a landmine for anyone who wanted to use compression in the
future and we want server operators to know that something is wrong. The
FreeBSD issue makes it very easy to take down any affected server.
Additionally, it's likely to be an easy security exploit. Given that the
issue is apparently known, there's a possibility that servers are already
getting sequestered.
I must have obviously understood comment #5 wrong. We tried the
--disable-ssl-false-start option, and with a disabled False Start SSL does
not cause any problems in Chrome. So I thought that an activated False
Start is the problem (no False Start = no problem).
Sorry to hear that you won't fix the issue. As for our customers I am sure
that they will rather prefer a solution that is a millisecond slower but
works in opposite to a super high tech up-to-date solution only one browser
with a very limited market share uses and does not work. I understand that
you wish the IT world to be perfect. From a practical point of view however
the goal should be to make things work.
This is nothing to do with False Start or speed (OpenSSL doesn't have any
issues with False Start). Disabling False Start may appear to solve the
issue, but that's because memory corruption can manifest in odd ways.
The problem is (again, probably, because I'm mostly guessing based on the
similarity with other case) that your Apache thinks that OpenSSL's data
structures are smaller than OpenSSL does. This means that Apache is
randomly corrupting its memory and crashing. Hiding this will only result
in the problem going unnoticed until someone malicious decides to use it in
order to steal all the private data from such servers and add them to a
botnet to DDoS someone else.
For everyone out there, here is an easy solution to work around the Google
bug: deactivate mod_deflate in httpd.conf. That's it.
The bad part of it is, that your websites won't compress any more
afterwards, so you will need to decide whether to have a fast, compressed
delivery of files or make it work with Chrome.
well, I tried disabling mod_deflate. It does not solve the issue. I do
happen to be running FreeBSD. Its a VPS system from ViaVerio. I'm not even
certain recompiling everything is an option. While I'm going to try doing
so, I agree with one of the other posters. This is Chrome's problem and
should be fixed in Chrome. To not do so is arrogant. I appreciate the
idea that you guys are trying to keep a well optimized browser, however it
is not up to you to force servers all over the world to recompile
everything or not work in chrome. The site I got this reported on is
alpinesports-santafe.com when in https mode only. The site works fine in
all the other major browsers. I'm not gonna hold my breath though for
Google to fix this.
Your mileage may vary, but on my Verio VPS, I disabled mod_deflate at the
top of the httpd.conf and then added the "LoadModule deflate_module
modules/mod_deflate.so" inside <Directory "/home/*/www">. This appeared to
do the trick for me and now Chrome shows the secure pages without error and
still gzip compressed apparently. Granted I have a shared certificate, so
all of my secure pages are routed from the /www/htdocs/ path and link back
to files contained in the /home/*/www path.
@endymion: I confirm the workaround in comment #31 for the NTT/Verio VPSv3,
this workaround works.
We also encountered this problem on some servers after Verio/ViaVerio
upgraded OpenSSL on their FreeBSD 6 servers (VPS and MPS) in late
October/early November. I just wanted to point out that a graceful restart
doesn't seem to resolve the issue after commenting out mod_deflate;
however, a full stop/start does.
The issue occurred for any SSL connection to the server (page, image, etc.)
and results in a "child pid 97236 exit signal Bus error (10)" message in
the main error_log file when the Apache process crashes.