Bug 805720 - Only a single interface is available for SSL
Only a single interface is available for SSL
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: httpd (Show other bugs)
6.2
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Web Stack Team
Zbysek MRAZ
:
: 842868 (view as bug list)
Depends On:
Blocks: 791327 761574 835071 842868 842869 1021458 1021469
  Show dependency treegraph
 
Reported: 2012-03-21 17:40 EDT by Rob Crittenden
Modified: 2013-10-21 07:13 EDT (History)
7 users (show)

See Also:
Fixed In Version: httpd-2.2.15-24.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 866560 (view as bug list)
Environment:
Last Closed: 2013-02-21 05:16:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rob Crittenden 2012-03-21 17:40:16 EDT
Description of problem:

mod_proxy provides a single hook for providing SSL services but there are two SSL engines available in Apache.

Currently mod_ssl always registeres these hooks. mod_nss will register them if they are free.

This means that if the mod_ssl module is loaded in Apache at all, even if it isn't configured, then mod_proxy is unavailable to mod_nss.

We need some negotiation mechanism where both SSL engines can be support simultaneously.
Comment 2 Joe Orton 2012-03-22 09:32:31 EDT
Is it really useful/necessary/desirable to support loading both mod_ssl and mod_nss at the same time, i.e. why can't mod_nss Conflicts: mod_ssl?  We have hooks into the SSL module from not just the proxy but also mod_rewrite and mod_headers.
Comment 3 Rob Crittenden 2012-03-22 10:54:05 EDT
Honestly, that's what I thought too, but people keep doing it, particularly those using IPA which uses mod_nss for crypto. I think what they want is to use IPA *and* do their own stuff using mod_ssl which they may be more familiar/comfortable with.

I'm getting push back trying to add Conflicts: mod_ssl in the IPA package, it is considered a regression in EL6 since earlier versions of IPA didn't have this.

And it would make co-habitation work better.
Comment 4 Joe Orton 2012-03-23 04:55:25 EDT
So mod_ssl/mod_nss could do the following:

1. retrieve existing ssl_proxy_enable hook (with APR_RETRIEVE_OPTIONAL_FN), store that function pointer away somewhere
2. replace hook with own wrapper
3. wrapper does:
 a) "am I configured?"
 b) if no: run stored fn pointer for other module's ssl_proxy_enable fn
 c) if yes: act as normal

It's kind of ugly but it should work, I think; if both modules do work the same way, it should work regardless of wins the race to register the "real" optional fn.  It is only the proxy that people care about?
Comment 5 Rob Crittenden 2012-03-23 09:11:19 EDT
I like the idea of not automatically registering the callbacks, I think that might be the simplest fix. I don't know that one module should call the other though, this might make us vulnerable to load order.

I haven't gotten any reports of problems with other modules, just mod_proxy, perhaps because it is so visible.
Comment 6 Joe Orton 2012-03-23 09:39:54 EDT
I *think* that logic should avoid load-order issues.

1. module A wins race to register hook.
2. existing hook is empty, so APR_RETRIEVE_OPTIONAL_FN returns NULL for A
3. A installs own hook in ssl_proxy_enable.
4. module B runs second.
5. retrieves module A's hook via APR_RETRIEVE_OPTIONAL_FN and stores that ptr
6. B installs own hook as ssl_proxy_enable

We don't have "hard" symbol interdependencies between A and B, they merely exchange a function pointer.

I haven't tried it though so I might be missing something.
Comment 7 Dmitri Pal 2012-03-23 15:54:13 EDT
Is the assumption that both modules would work the same way really safe?
Comment 8 Rob Crittenden 2012-03-26 09:20:01 EDT
It would be an area ripe for regressions, I think.
Comment 11 RHEL Product and Program Management 2012-07-10 04:31:33 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 12 RHEL Product and Program Management 2012-07-10 19:23:03 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 14 Joe Orton 2012-07-25 11:02:24 EDT
*** Bug 842868 has been marked as a duplicate of this bug. ***
Comment 15 Karel Srot 2012-07-30 05:58:59 EDT
Hi,
could you please describe in more detail how this is supposed to work? Does it mean that once this is implemented, a user would be able to use both SSLProxyEngine and NSSProxyEngine simultaneously and there might be running several proxies using different engines? Could you please provide simple use case?
Comment 16 Joe Orton 2012-08-06 04:49:32 EDT
The test case should be that with both mod_ssl and mod_nss installed, a configuration with SSLProxyEngine enabled should work, and a configuration with NSSProxyEngine should also work.

  ProxyPass /blah https://localhost/
  SSLProxyEngine on

plus SSL CA cert setup.
Comment 17 Karel Srot 2012-08-06 05:05:47 EDT
Sorry, still it is not clear to me. Is SSLProxyEngine and NSSProxyEngine supposed to work together, e.g. running 2 proxies with different engines?
Comment 24 Rob Crittenden 2012-11-02 15:25:08 EDT
A somewhat more invasive way for mod_proxy() to know which SSL engine (if any) it is using is to look for specific input filter values via ap_get_input_filter_handle(). Each SSL provider would register their own set of callbacks and mod_proxy would know which one to call based on the filter(s) available.
Comment 30 errata-xmlrpc 2013-02-21 05:16:48 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0512.html

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