Late at night here and I'm not at work, but see the embedded responses
to clarify some things...
On 2016-02-03 12:43 AM, Yann Ylavic wrote:
On Wed, Feb 3, 2016 at 6:31 AM, Joachim Achtzehnter <joac...@kraut.ca> wrote:
Attached is file "ssl_log-v3.txt" with the log messages seen when using your
v3 patch. The other two files are the corresponding Wireshark traces,
collected on the client-side where Firefox was trying to retrieve the file.
Looks OK on the httpd side now with explicit flushes on write (during
handshake), but the issue seems to be on the client side now.
The "Encrypted Handshake Message" it uses to finalize its handshake
looks really weird, and it doesn't wait for the server to finalize the
handshake before sending the HTTP request (the complete handshake
response will only be read by the client when it expects the HTTP
response).
I can't tell about the underlying HTTP data here, but I suspect there
is more than a single HTTP request sent by the client,
No, there is definitely only one request for this test. In the real
application there is an HTML page, which triggers multiple requests for
style sheets, scripts, images, etc., and these may well be pipelined or
submitted via parallel connections. This still locked-up, 100%
reproducible. The test I use to collect the traces and logs is
retrieving a single small style sheet. No other files are involved. In
order to allow Wireshark to decrypt the SSL data I used Firefox, but for
my own testing and debugging I usually submit the request with curl. The
outcome is the same with both Firefox and curl.
which makes httpd believe requests are pipelined,
How does it make this determination?
and hence never flush its output
until the client stops pipelining requests.
The client is now blocked waiting for the first response...
Yes, it is waiting forever.
Before 2.4.18, since simply reading on the connection flushed the
output data on the server side, the client had its response while the
server was reading the second (pipelined) request.
Except that in this test there is no second request.
Some more details: The application offer the exact same Web
functionality in one of two modes:
1) HTTP only, configuration does not use virtual hosts
2) HTTPS with HTTP redirected to the corresponding HTTPS URL. The exact
same functionality as above is now defined in a virtual host for port
number 443. The virtual host for port number 80 simply sends a redirect
response back to the client.
With Apache 2.4.12 this all works. After upgrading to 2.4.18 mode 1
still works perfectly, but with mode 2 some https requests never get a
response and the application stalls.
I'd need more info to confirm (or invalidate) this, like LogLevel
trace8 (possibly privately, still).
While exploring a final fix for this, can I ask for your opinion about the
following work-around we currently rely on until there is an official fix.
We continue to use Apache 2.4.18, but have replaced mod_ssl.so with the one
from Apache 2.4.12. Is this likely to be safe? or do you not recommend
mixing versions?
This looks "risky" to me, recompiling 2.4.18 with your original patch
is much better IMHO.
Thanks,
Joachim
Regards,
Yann.
