Bug 805720

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.

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.

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?

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.

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.

Is the assumption that both modules would work the same way really safe?

It would be an area ripe for regressions, I think.

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.

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.

*** Bug 842868 has been marked as a duplicate of this bug. ***

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?

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.

Sorry, still it is not clear to me. Is SSLProxyEngine and NSSProxyEngine supposed to work together, e.g. running 2 proxies with different engines?

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.

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