httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Fri, 15 Apr 2016 10:31:39 GMT
Am 15.04.2016 um 03:20 schrieb Daniel Ruggeri:
> On 4/14/2016 3:08 AM, Rainer Jung wrote:
>> Your idea to allow selecting a client cert based on CN or DN sounds
>> attractive to me as well. But since it wouldn't help with other per
>> backend settings (like different Verify settings) we might even think
>> about combining both. As long as your only problem would be client
>> certs, you can select via CN or DN and keep the config vhost global,
>> but once you need more adjustments per backend, you would start to
>> configure SSLProxy* inside <Proxy ...>.
>> WDYT?
> Yep! Agreed - I was focusing on the use case presented, but didn't think
> about other cases such as different SSLProxyVerify settings and friends
> such as this. I'd cast a vote for the more comprehensive solution you
> and Graham shared that makes each option available in a directory
> context. Adding yet another directive would satisfy this one use case,
> but the bigger picture would serve users better and be less confusing.
> Food for thought - I haven't dug into these...
> * Not sure if it would be a handy target of opportunity or PITA... Since
> ProxyPass is currently server/vhost/dir configurable, should we think to
> include this capability as arguments to ProxyPass/BalancerMember, too?
> * Maybe I missed it, but I don't think the proposed ideas truly provide
> per-backend configuration. Rather, they provide configuration for all
> backends in a dir context if you land on a balancer containing many
> targets. Is that OK, or should we be thinking about ways to make it even
> more granular? (the use cases that come to mind are rather contrived, so
> I may be overthinking it)
> * Would each of these per-dir configs post-merge result in a distinct
> SSL_CTX that needs to be created in mod_ssl? If so, does that require
> significant refactoring in mod_ssl or does the proxy module manage these?

I think there are two notions of dir config versus server config.

First: in which contexts are directives allowed by the general checks 
Apache does. Here <Proxy> is ACCESS_CONF (global server or vhost, but 
not inside Directory, Location, Files), but ProxyPass is RSRC_CONF or 
ACCESS_CONF (everything except htaccess).

Second: how do we handle the values and do we force additional 
structural requirements on the config. Do we add the values to a server 
config structure or to a directory config structure.

In our case I would much prefer to keep the config in a server config 
structure so that it could still be used for init purposes during server 
startup and not only later during request processing. No directory tree 
walking etc., only server config merging during startup and handling in 
the post_config hook, similar to today.

That is one of the reasons, I would prefer to only allow SSLProxy* in 
<Proxy> but not allowing ssl key=value tokens in ProxyPass. The 
implementation would become much harder, but also the semantics very 
unclear. As soon as there is more than one ProxyPass to the same backend 
the question would be, whether the ssl setting is really meant to apply 
only for the specific left hand side of the ProxyPass (incoming URI). I 
find it featurewise sufficient to support setting per backend and not 
support settings per backend and incoming URI.

What we might be able to do, is handling (and documenting) any ssl 
setting in ProxyPass as being used per server per backend, not per 
location. We would not put the setting to a dir config but instead to a 
server config (I think that works but we'd need to test).

I personally don't like very much the long key=value lists behind a 
ProxyPass so I would be already satisfied with a <Proxy> solution.

BalancerMember: if a setting were in a <Proxy> for a balancer we would 
it apply to any member. Do we think we need the possibility to have 
different ssl settings for the members of the same balancer? I'd hope we 
can start without that feature, but I might overlook some use case here.

I'd put the ssl settings in a hash of SSL_CTX structs per server. The 
key to the hash would be the worker URL (name).

Your idea of making the client cert choosable via CN and/or DN is an 
excellent addition, because this is probably the most important use 
case, where an SSL setting could depend on the URI of the target and 
where doing a directory walk is cheap and doesn't mean major 
refactoring, because we don't have to create SSL contexts but instead 
just use a string token to select the correct certficate.



View raw message