Bug#594150: regression in apt-transport-https interop with apt-cacher

[Johannes Ernst]

Assuming this is the right diagnosis, I still think this is a bug: it can't take several people several months (like us on this thread) to figure out that some setting needs to be moved by two lines. Lots of people will be upgrading their existing, working, Apache settings when migrating to squeeze, and they will expect (like me) that they continue to work, and certainly not silently fail.

At the minimum, can this generate a really nice and big and comprehensible error message?


On Nov 24, 2010, at 7:37, Simon McVittie wrote:

> On Tue, 23 Nov 2010 at 11:50:42 -0800, Johannes Ernst wrote:
>> Apologies that I didn't see this question earlier:
>> 
>> http://apt-test.aviatis.com/ has now been updated with the Apache configuration.
> 
> Thank you! I think this is indeed fallout from CVE-2009-3555 (DSA-1394).
> Quoting from the DSA, http://www.debian.org/security/2009/dsa-1934:
> 
>    A design flaw has been found in the TLS and SSL protocol that allows
>    an attacker to inject arbitrary content at the beginning of a TLS/SSL
>    connection. The attack is related to the way how TLS and SSL handle
>    session renegotiations [...]  The attack is still possible in
>    configurations where the server initiates the renegotiation. This
>    is the case for the following configurations (the information in
>    the changelog of the updated packages is slightly inaccurate):
> 
>        * The "SSLVerifyClient" directive is used in a Directory or
>          Location context.
> 	* The "SSLCipherSuite" directive is used in
>          a Directory or Location context.
> 
> Your server has SSLVerifyClient in a Directory context (really DirectoryMatch,
> but that's equivalent), so when the client announces its intention to access
> a path below /apt-cacher, your server performs renegotiation.
> 
> The TLS client used by apt-transport-https (gnutls) notices that this
> renegotiation could be someone exploiting CVE-2009-3555, so it aborts the
> TLS handshake.
> 
> The workaround suggested by DSA-1394 would be to move SSLVerifyClient up to
> the <VirtualHost> context, avoiding the need for renegotiation (doing that
> will require client certificates for the entire server, not just the
> /apt-cacher path, though). Could you try that on your server? If that works,
> I think we can close this bug.
> 
> The real fix for your configuration requires the server's apache2 and openssl
> to be upgraded to versions which can perform secure renegotiation as an
> extension; in squeeze that's been fixed in openssl >= 0.9.8m-1 and
> apache2 >= 2.2.15-1, but these changes haven't been backported to lenny.
> 
> Regards,
>    Simon