httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Wed, 13 Apr 2016 19:22:57 GMT
Am 13.04.2016 um 19:49 schrieb Rainer Jung:
> Am 13.04.2016 um 17:04 schrieb Graham Leggett:
>> On 13 Apr 2016, at 12:40 PM, Rainer Jung <rainer.jung@kippdata.de> wrote:
>>
>>> I stumbled into a situation where a reverse proxy had two different
>>> backends behind the same VHost of the proxy. Both backends demand
>>> client certs as becomes more and more common for services today.
>>> Unfortunately the CA which issues the client certs in both cases is
>>> the same CA, but the demanded client cert is individual to the
>>> backend services.
>>>
>>> As far as I can see, this is currently not configurable. The
>>> SSLProxyMachineCertificateFile and SSLProxyMachineCertificatePath
>>> only work on the VHost level and the client cert detection algo in
>>> ssl_callback_proxy_cert() chooses the first client cert it can find
>>> which was issued b the right CA. No way to distinguish further.
>>>
>>> To me it looks like the "right" way of handling SSLProxy* config
>>> would be per <Proxy>. Did anyone else already encounter a similar
>>> problem? Any thoughts or experiments on how to solve this for the
>>> future?
>>
>> I looked at this a while back.
>>
>> The catch is that mod_ssl forces us to declare SSL certs and keys
>> server wide, not per directory, loaded and parsed at startup. We
>> however want to specify certs per directory.
>
> Per directory or better in some new way per proxy backend (or proxy
> worker, proxy balancer).
>
>> What I had in mind was a syntax where the certs were named, for example:
>>
>> SSLProxyCertificate foo /path/to/foo.cert
>>
>> Followed somewhere else by:
>>
>> <Proxy …>
>>    SSLProxyEnable foo
>> </Proxy>
>
> I would also like to prevent using per dir config, directory walk etc.
>
> Like (I think) proxy has it's backend config in per server structures
> which are lists of backends with names, the proxy ssl config could be a
> list of traditional ssl configs indexed by name. Name could be like you
> suggest a name given via additional directive attributes, or simply the
> balancer name (URL) given in the opening <Proxy URL> tag of the proxy
> container.
>
> What I haven't yet investigated is, how easy one could pass the worker
> or balancer name from mod_proxy to mod_ssl, so that mod_ssl can choose
> the correct ssl proxy config (without coupling the proxy and ssl details
> too close to each other). Another thing is getting a hand at the URL
> when the SSLProxy* directive is handled inside <Proxy> during directive
> parsing. Maybe similar to how mod_proxy does it.
>
> Yes, that looks like a deeper coupling of mod_ssl and mod_proxy, but the
> whole use case of mod_ssl as an client currently is coupled to the proxy
> setup, so it doesn't look wrong to "fully" support SSLProxy* per <Proxy>.

We could pass the worker name from mod_proxy to mod_ssl via a connection 
note, similar to currently already passing the SNI name via the 
connection note proxy-request-hostname.

> I guess we need to prototype something.

Regards,

Rainer

Mime
View raw message