Bug 484380 - SSL (reverse) proxy flaky
SSL (reverse) proxy flaky
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mod_nss (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Rob Crittenden
Chandrasekar Kannan
Depends On:
  Show dependency treegraph
Reported: 2009-02-06 09:58 EST by Joe Orton
Modified: 2015-01-04 18:36 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:29:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
nss_error_log with LogLevel debug (1.81 KB, text/plain)
2009-02-06 10:15 EST, Joe Orton
no flags Details
strace output of child process (9.42 KB, application/octet-stream)
2009-02-06 10:18 EST, Joe Orton
no flags Details

  None (edit)
Description Joe Orton 2009-02-06 09:58:32 EST
Testing for #479410, mod_nss seems flaky as an SSL reverse proxy.

I added to the nss.conf vhost:

NSSProxyEngine On
NSSProxyCipherSuite +rsa_3des_sha,-rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5
NSSProxyProtocol SSLv3

ProxyPass / https://issues.apache.org/
ProxyPassReverse / https://issues.apache.org/

alone, and e.g. loading the /bugzilla/ URL doesn't seem to work.

mod_ssl works fine in a similar confniguration so this seems like
a mod_nss issue rather than a mod_proxy issue.
Comment 1 Rob Crittenden 2009-02-06 10:08:27 EST
Is anything being logged to the error log?
Comment 2 Joe Orton 2009-02-06 10:14:29 EST
Nope.  If I turn up to "LogLevel debug" in the vhost, I get lots of mod_proxy output; I'll attach it.
Comment 3 Joe Orton 2009-02-06 10:15:23 EST
Created attachment 331133 [details]
nss_error_log with LogLevel debug
Comment 4 Joe Orton 2009-02-06 10:18:48 EST
Created attachment 331134 [details]
strace output of child process

This shows at least that the proxy is talking SSL to the origin server.
Comment 5 Rob Crittenden 2009-02-06 11:15:36 EST
Ok, I can duplicate this behavior. The request to / works ok but clicking on any links is not working. The local Apache server is returning a 200 result with a content-length of 0.
Comment 6 Rob Crittenden 2009-02-16 12:01:14 EST
PR_Read() is returning 0 bytes when there is still data. The 0 causes mod_nss to consider the connection closed so it sets APR_EOF, hence an empty body.

This 0 read can actually happen a couple of times on a large page. I'll need to dig into PR_Read() some more but 0 is supposed to mean EOF.
Comment 7 Rob Crittenden 2009-02-17 23:01:44 EST
The problem was in the mod_nss NSPR bucket layer. If no data was available then it was returning 0 and not -1. It is a small patch that fixes it and returns the appropriate NSPR error.

--- mod_nss-1.0.3.orig/nss_engine_io.c  2006-04-07 16:17:12.000000000 -0400
+++ mod_nss-1.0.3/nss_engine_io.c       2009-02-17 22:51:44.000000000 -0500
@@ -259,7 +259,8 @@
         if (APR_STATUS_IS_EAGAIN(inctx->rc) || APR_STATUS_IS_EINTR(inctx->rc)
                || (inctx->rc == APR_SUCCESS && APR_BRIGADE_EMPTY(inctx->bb))) {
-            return 0;
+            PR_SetError(PR_WOULD_BLOCK_ERROR, 0);
+            return -1;
         if (inctx->rc != APR_SUCCESS) {
Comment 8 Joe Orton 2009-02-18 05:51:26 EST
Great!  We should get that fixed in a RHEL update if people are using this stuff in anger.
Comment 9 Rob Crittenden 2009-02-18 21:32:26 EST
Fix committed upstream:

/cvs/dirsec/mod_nss/nss_engine_io.c,v  <--  nss_engine_io.c
new revision: 1.9; previous revision: 1.8
Comment 16 errata-xmlrpc 2009-09-02 07:29:01 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.