Re: [Pkg-openssl-devel] Backport apache2 version >= 2.2.12 ? With or without new openssl?
On Wed, Apr 14, 2010 at 09:54:50PM +0200, Stefan Fritsch wrote:
> On Wednesday 14 April 2010, Sandro Tosi wrote:
> > On Mon, Apr 5, 2010 at 10:54, Stefan Fritsch <firstname.lastname@example.org> wrote:
> > > - 2.2.15-2 still has some bugs in mod_reqtimeout, 2.2.15-3 would
> > > be better (but will take some time until it hits testing).
> > so do you suggest to backport -3 instead of -2? we don't use
> > mod_reqtimeout so we are not impacted from those bugs (so we didn't
> > spot them).
> mod_reqtimeout will be enabled on update, though (unless you changed
> that). The bugs are mostly relevant when using mod_proxy at the same
> time, but using apache2 as reverse proxy is a common configuration.
> > On Wed, Apr 14, 2010 at 07:58, Jan Wagner <email@example.com> wrote:
> > > On Monday 05 April 2010 10:54:54 Stefan Fritsch wrote:
> > >> - it is also possible to use an older openssl, this would just
> > >> mean that the new 'SSLInsecureRenegotiation' directive would not
> > >> be available (at least I believe that lenny's openssl already
> > >> has SNI support). Maybe it would be better not to force people
> > >> to update that core library. If you want to go with the older
> > >> openssl, just downgrade the build-depends in apache and mention
> > >> in the changelog that this removes SSLInsecureRenegotiation.
> > >
> > > Any news here?
> > Well, in our configuration we need SSLInsecureRenegotiation, so I
> > need a more recent openssl. If it's a problem, I can leave
> > Jan, are you testing the packages I provided? are you facing any
> > issues?
> The openssl from squeeze will disable insecure renegotiation by
> default and will cause problems for some people. For example, it
> breaks tor (IIRC).
But openssl has an option to re-enable the old behaviour, and the
version of tor in squeeze should work with any version of openssl.
> I am not too familiar with backports.org. Will packages built in
> backports always be built with the openssl from backports, or only if
> there is a built-dep that cannot be satisfied in the normal lenny?
As far as I know, only when the build-depedencies require it, but
I'm not really sure about that. Note that is also depends on the
system the person used to make the package on, so it might be
different on the other arches.
> the former, I am against backporting it. If the latter, people have
> the option to just not install it. I am CCing the openssl maintainer,
> in case he wants to add something.
Anyway the openssl version in lenny was build with tls extentions
enabled to support SNI for apache. But the patch for apache to
enable SNI had various issues so that SNI was not supported by
apache in lenny. So SNI is not a reason you want for backporting
Having secure renegiotation support in Lenny would be nice. The
security team indicated that they wanted to wait with fixing
openssl in Lenny until the renegiotation was implemented, which it
is now. I asked if they wanted it backported but I don't think
I got reply on that.
I understand that this also requires changes on the client side,
which for web clients ussually isn't with openssl but mozilla's
nss or gnutls (because of license issues). And I have no idea
what the state of that is.
So it's my understanding that SNI and secure renegiotation are
not supported by all clients yet, but it's probably nice to be
able to turn that option on. And I would like to get this fixed
in stable rather than backports.