Bug 49382 - ab says "SSL read failed"
Summary: ab says "SSL read failed"
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: support (show other bugs)
Version: 2.2.15
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2010-06-03 16:27 UTC by Pavel Kankovsky
Modified: 2014-12-02 12:53 UTC (History)
2 users (show)

proposed patch (2.19 KB, text/plain)
2010-06-03 16:35 UTC, Pavel Kankovsky
Updated patch for 2.4.1 (2.22 KB, patch)
2012-03-07 19:50 UTC, Ian Webb
Details | Diff
Patch for ab to stop "SSL read failed" (2.58 KB, patch)
2012-04-09 12:49 UTC, Masaoki Kobayashi
Details | Diff
update of patch attachment ID # 28564, with failed hunks removed (1.19 KB, patch)
2013-05-22 02:45 UTC, Matthew Hall
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Kankovsky 2010-06-03 16:27:11 UTC
ab has trouble receiving responses from many HTTPS non-Apache servers (IIS 6.0, Lotus Domino, Google gws), complaining that "SSL read failed":

$ ./ab https://www.google.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.google.com (be patient)...SSL read failed - closing connection

Those servers seem to terminate TCP connection after the response without shutting down SSL session properly (using close_notify).

A possible workaround is to stop reading after Content-Length bytes have been received. I have implemented that that workaround (see the attachment). It appears to work in most cases, the only notable exception is Google gws because it does not send Content-Length in responses to HTTP/1.0 request.

Trunk (2.3) appears to be affected too.
Comment 1 Pavel Kankovsky 2010-06-03 16:35:34 UTC
Created attachment 25520 [details]
proposed patch
Comment 2 Andreas Roth 2011-01-29 02:12:49 UTC

i experienced the same problem with the apache2-utils package version 2.2.16-1ubuntu3.1 installed on my maverick machine.
I get the following output from ab:
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.google.com (be patient)...SSL read failed - closing connection

Server Software:        gws
Server Hostname:        www.google.com
Server Port:            443
SSL/TLS Protocol:       TLSv1/SSLv3,RC4-SHA,1024,128

Document Path:          /
Document Length:        0 bytes

Concurrency Level:      1
Time taken for tests:   0.205 seconds
Complete requests:      1
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Non-2xx responses:      1
Total transferred:      840 bytes
HTML transferred:       226 bytes
Requests per second:    4.89 [#/sec] (mean)
Time per request:       204.524 [ms] (mean)
Time per request:       204.524 [ms] (mean, across all concurrent requests)
Transfer rate:          4.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      152  152   0.0    152     152
Processing:    52   52   0.0     52      52
Waiting:       52   52   0.0     52      52
Total:        204  204   0.0    204     204

I haven't check the newer versions of ab, since i haven't got a system ready to build apache on my own. Is there any progress on this issue?

Comment 3 Ian Webb 2012-03-07 19:50:34 UTC
Created attachment 28435 [details]
Updated patch for 2.4.1

Confirmed that this bug still exists in the 2.4.1 release. Updated the patch for 2.4.1 and it's working for me now. Any chance we could get this committed to trunk?
Comment 4 Ian Webb 2012-03-07 20:37:40 UTC
Upon further testing, I've found some sites this still doesn't work on.

In particular, I've verified that ab will now work fine with -n1 against https://www.google.com/ and https://www.facebook.com/, but will fail with -n2 or higher. The failure modes seem slightly different but both Google and Facebook "cheat" in various ways for performance (such as defeating slow-start) so I'm not too surprised this fails on those two. (Other Google properties, such as https://gmail.com/, work fine.)

In testing against most sites I monitor in production it works fine. This represents a mix of Apache, IIS, nginx, and F5 BigIP HTTPS servers.

I have found one Tomcat 5.5 that fails, unfortunately this may be exposing a serious error. The first request resolves with a 200, then subsequent requests seem to be continuing the data flow from that first request and interpreting it as a 500. Note that the function (this was with -v2, the failure happens in a part of the page that has JavaScript so that's just page data) is cut off in the middle by a 500 response code. Not sure what's going on.

function popWindowSecure(url,winnam
WARNING: Response code not 2xx (500)
LOG: header received:
Comment 5 Masaoki Kobayashi 2012-04-09 12:49:05 UTC
Created attachment 28564 [details]
Patch for ab to stop "SSL read failed"

This is another patch for making ab work with SSL.
Also includes the removal of unnecessary apr_socket_bind() call, and the version string of ab will include the openssl version with this patch.
Comment 6 Masaoki Kobayashi 2012-04-09 13:02:32 UTC
I don't think watching Content-Length on http layer is good idea.
Content-Length on http does not always exist because there are other mechanism like "Transfer-Encoding: chunked" or like "100 Continue" or something, even if the http layer is enough neat and honest.
We can still take care of chunked coding, but it seems meaningless because the server still can respond incorrectly.  Generally they are sloppy and unreliable.

My patch is easy one which just treats zero-byte read as the end of communication.
Comment 7 Pavel Kankovsky 2012-04-18 00:29:57 UTC
(In reply to comment #4)
Does the problem with Tomcat occur when keepalive is NOT enabled?

(In reply to comment #6)
1. ab sends HTTP/1.0 requests. See RFC 2616
(a) 3.6 Transfer Codings: "A server MUST NOT send transfer-codings to an HTTP/1.0 client."
(b) 8.2.3 Use of the 100 (Continue) Status: "An origin server ... MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client."
2. Indeed, a server can respond incorrectly. Such a server is broken.
Comment 8 olivier.suritz 2012-10-31 13:49:21 UTC
Bump. We're experiencing a lot of SSL write failed and some read failed. Not sure if it's the same issue.
Anyways, last entry was from APR-18, has this been integrated/what's the status?
Comment 9 Matthew Hall 2013-05-22 02:45:28 UTC
Created attachment 30307 [details]
update of patch attachment ID # 28564, with failed hunks removed

A couple of hunks in patch attachment ID # 28564 were failing due to some changes in the code. So I stripped these out to get it applying again on my system to httpd-2.2.22.

Can we please figure out what we need to do to get this finished and merged? Right now it's crippling a tried and true utility that's survived for ages, and it's kind of sad to watch.

Let me know if I can help, too!
Comment 10 Ruediger Pluem 2014-12-02 12:53:21 UTC
IMHO fixed in 2.4.x via r1373084.