You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2011/11/08 22:10:06 UTC
Small things to do
Hi,
yesterday at the Dover Arms pub, we discussed what needs to be done for
2.4 and we came up with a list of things that would be nice, but are
definitely not blockers for GA:
- fix ssl session cookie stuff (Paul volunteered)
- fix the bug in mod_authn_socache that I brought up on the list recently
(I will do that unless Nick beats me to it)
- Rainer wanted to check some pcre linking issues, but I don't remember
the exact details
- check the list of modules that are loaded by default; I think we may
want to downgrade some of them
- check that the default config has all necessary <IfModule> statements
- chack that the values the default config are identical with the built-in
compiled values, where applicable
- check that the sizing default values in the config are reasonable
- make some performance comparison with 2.2.x
- convince some more people to install it on their production servers
(Steffen?)
- there was also the question if we want to change the default config so
that there is sep
- Bill brought up having a switch to load all modules, for the benefit of
the test framework (I will do that)
- There are some entries in the blockers list in STATUS, which are
actually not blockers but nice-to-have IMHO:
* The mod_session* modules need to be checked that their hooks respect
the returning of int (HTTP status codes) and apr_status_t as appropriate,
and any anomolies fixed.
jim sez: from what I can see, mod_session* is no worse that other
modules that mix these 2 types... clean up is
forthcoming but should not be considered a blocker, imo
pgollucci: +1 jim
wrowe asks: what's the API change required?
wrowe asks; why are we shipping this if it requires apr_ssl
* mod_ssl's proxy support only allows one proxy client certificate per
frontend virtual host. Lift this restriction.
jim sez: Why a blocker?, pgollucci +1 jim
wrowe asks: what's the API change required?
Cheers,
Stefan
Re: Small things to do
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 8 Nov 2011 22:01:07 +0000
Nick Kew <ni...@webthing.com> wrote:
> On Tue, 8 Nov 2011 22:10:06 +0100 (CET)
> Stefan Fritsch <sf...@sfritsch.de> wrote:
>
> > Hi,
> >
> >
> > yesterday at the Dover Arms pub, we discussed what needs to be done for
> > 2.4 and we came up with a list of things that would be nice, but are
> > definitely not blockers for GA:
>
> mod_proxy_html: I want to switch to using ap_expr for conditional evaluation.
>
> I'd've done it long ago if it wasn't for the issue of 2.0/2.2 compatibility.
> In trunk that's not an issue.
>
> I'll tackle it within the next 48 hours.
Done.
In doing so, I also discovered and fixed a couple of omission bugs.
The one that matters is that I had omitted the stock proxy-html.conf
that is required for mod_proxy_html to do anything.
> > - fix the bug in mod_authn_socache that I brought up on the list recently
> > (I will do that unless Nick beats me to it)
>
> Heh. Looking back, I said I'd do that when I was back home.
> I've now been back home for some time with no excuse beyond
> a mild bout of seasonal lurgy.
Done - but that's old news now!
--
Nick Kew
Re: Small things to do
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 8 Nov 2011 22:10:06 +0100 (CET)
Stefan Fritsch <sf...@sfritsch.de> wrote:
> Hi,
>
>
> yesterday at the Dover Arms pub, we discussed what needs to be done for
> 2.4 and we came up with a list of things that would be nice, but are
> definitely not blockers for GA:
mod_proxy_html: I want to switch to using ap_expr for conditional evaluation.
I'd've done it long ago if it wasn't for the issue of 2.0/2.2 compatibility.
In trunk that's not an issue.
I'll tackle it within the next 48 hours.
> - fix the bug in mod_authn_socache that I brought up on the list recently
> (I will do that unless Nick beats me to it)
Heh. Looking back, I said I'd do that when I was back home.
I've now been back home for some time with no excuse beyond
a mild bout of seasonal lurgy.
--
Nick Kew
Re: Small things to do
Posted by Graham Leggett <mi...@sharp.fm>.
On 09 Nov 2011, at 1:52 AM, Daniel Ruggeri wrote:
> One thing I know for certain that does not fall in line with this is
> if some.where.back.there and some.where.different are signed out of
> the
> same CA, but you wish to send different client certs based on path
> (such
> a use case exists, silly as it may seem in my eyes).
That would be the use case, yes.
We have a service oriented platform that is hardened end to end, in
other words services are client cert protected, and apps must strongly
authenticate to use the service using their own client cert. Sometimes
the apps need to expose the URL space of the service directly (for the
benefit of ajax, etc), but currently can't using a simple proxypass
because the app next door needs to expose a different service with a
different client cert.
As to the use case being silly, we live in an age of the cloud, where
one app at location A is referencing a service in location B, with an
unsecured network in between. Times have changed :)
Regards,
Graham
--
Re: Small things to do
Posted by Daniel Ruggeri <DR...@primary.net>.
On 11/8/2011 5:37 PM, Graham Leggett wrote:
> Currently in our environment we have reverse proxies connecting to
> client-cert-authenticated backends, and one of the things we can't do
> is this:
>
> <VirtualHost ...>
> <Location /foo>
> ProxyPass https://some.where.back.there/foo
> ...
> </Location>
> <Location /bar>
> ProxyPass https://some.where.different/bar
> ...
> </Location>
> </VirtualHost>
>
> where "https://some.where.back.there" and
> "https://some.where.different" are authenticated by separate sets of
> client certs and separate CA certs.
>
> We do some nasty php to get around this, it isn't ideal. It is nice to
> have though, and shouldn't block 2.4.
>
> Regards,
> Graham
> --
>
I'd have to set up a test case to mimic what you have, but as I
understand it, the SSLProxyMachineCertificateFile at the vhost level
should have both client certs in use within the file. When connecting to
both backends, mod_proxy's client cert callback should pick the correct
client cert from those in the file already (if you look in the code it
actually uses X509_NAME_cmp on each item in the store)... This was one
of the things I verified with my patch for
SSLProxyMachineCertificateChainFile.
One thing I know for certain that does not fall in line with this is
if some.where.back.there and some.where.different are signed out of the
same CA, but you wish to send different client certs based on path (such
a use case exists, silly as it may seem in my eyes). Is this more in
line with what you are doing? If not, can you email me directly or share
a bit more of a complete example configuration? I have a few test CA's I
stood up for the patch mentioned above that I wouldn't mind taking a
crack at this one. FWIW, In all of my test cases I used ProxyPass to
balancers.
--
Daniel Ruggeri
Re: Small things to do
Posted by Graham Leggett <mi...@sharp.fm>.
On 09 Nov 2011, at 1:03 AM, Daniel Ruggeri wrote:
> On 11/8/2011 3:10 PM, Stefan Fritsch wrote:
>> * mod_ssl's proxy support only allows one proxy client certificate
>> per
>> frontend virtual host. Lift this restriction.
>> jim sez: Why a blocker?, pgollucci +1 jim
>> wrowe asks: what's the API change required?
>
> I'm not sure I understand this one... does anyone have the history to
> elaborate?
Currently in our environment we have reverse proxies connecting to
client-cert-authenticated backends, and one of the things we can't do
is this:
<VirtualHost ...>
<Location /foo>
ProxyPass https://some.where.back.there/foo
...
</Location>
<Location /bar>
ProxyPass https://some.where.different/bar
...
</Location>
</VirtualHost>
where "https://some.where.back.there" and "https://
some.where.different" are authenticated by separate sets of client
certs and separate CA certs.
We do some nasty php to get around this, it isn't ideal. It is nice to
have though, and shouldn't block 2.4.
Regards,
Graham
--
Re: Small things to do
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tue, 8 Nov 2011, Daniel Ruggeri wrote:
> On 11/8/2011 3:10 PM, Stefan Fritsch wrote:
>> * mod_ssl's proxy support only allows one proxy client certificate per
>> frontend virtual host. Lift this restriction.
>> jim sez: Why a blocker?, pgollucci +1 jim
>> wrowe asks: what's the API change required?
>
> I'm not sure I understand this one... does anyone have the history to
> elaborate?
I suspect that the intention was to make SSLProxyMachineCertificateFile
work inside <Proxy> blocks (i.e. per-dir and not per-vhost). But the issue
has been added by Graham Leggett, so he should know more details.
Re: Small things to do
Posted by Dirk-WIllem van Gulik <Di...@bbc.co.uk>.
On 8 Nov 2011, at 23:03, Daniel Ruggeri wrote:
> On 11/8/2011 3:10 PM, Stefan Fritsch wrote:
> > * mod_ssl's proxy support only allows one proxy client certificate per
> > frontend virtual host. Lift this restriction.
> > jim sez: Why a blocker?, pgollucci +1 jim
> > wrowe asks: what's the API change required?
>
> I'm not sure I understand this one... does anyone have the history to
> elaborate?
>
Three things really - in order of priority:
- Specify a specific client cert per proxy-pass or other <Location and so on.
- Be able to have a bunch of client certs respond/get picked right (narrowest) when the server gives a list of acceptable authorities.
- Be able to lock a specific client cert down to a cert in the chain of the servers issuer; or to the DN/etc of the server.
Though the latter/last is easily worked around with by having multiple vhosts wrapped around.
Dw
Re: Small things to do
Posted by Daniel Ruggeri <DR...@primary.net>.
On 11/8/2011 3:10 PM, Stefan Fritsch wrote:
> * mod_ssl's proxy support only allows one proxy client certificate per
> frontend virtual host. Lift this restriction.
> jim sez: Why a blocker?, pgollucci +1 jim
> wrowe asks: what's the API change required?
I'm not sure I understand this one... does anyone have the history to
elaborate?
--
Daniel Ruggeri
Re: Small things to do
Posted by Rainer Jung <ra...@kippdata.de>.
On 08.11.2011 13:10, Stefan Fritsch wrote:
> - Rainer wanted to check some pcre linking issues, but I don't remember
> the exact details
The problem is mainly gone with trunk. It concerns dependency libs,
which are likely used by 3rd-party modules as well. Until 2.2 PCRE was
such a library *plus* we bundled a totally outdated version. So users
e.g. typically build mod_security against a newer incompatible version
of PCRE which supports recursion limits etc.
At runtime - at least on Solaris and Linux - by default the dynamic
linker searches symbols in the order the shared objects had been loaded.
So when mod_security initializes PCRE, the symbol is found in httpd core
(statically linked in), but later calls for PCRE functions not existing
in the old PCRE lib will be found in the additionally loaded new PCRE
lib. This normally gives a crash.
At least on Solaris one can add flags when linking which encodes a
different search strategy in the shared objects. It is called direct
linking (-Bdirect) and means, that symbols are always searched first in
the shared object itself, then in its dependencies and only if not found
there in the remaining shared objects. That way mod_security e.g. would
find all PCRE symbols in its own PCRE dependency.
For trunk the problem is much smaller, because we no longer bundle and
therefore it gets more likely, that the dependency libs used to compile
httpd and to compile additional libraries will be compatible.
Still we (I) could document how to use e.g. the LDFLAGS resp. LDADD
variables and linker flags to fix this problem. But AFAIK there is no
similar solution on Linux, so the info is of limited value.
Regards,
Rainer