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.
Regards,
Rainer
