Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Nicolas Boullis]

Hello,

Florian Weimer wrote:
>>I just built it; it seems to work fine.
> 
> Thanks.

No problem. Do you plan to issue a new DSA that applies this patch to
etch's gnutls13?


> The usual problem with X.509v1 certificates: if you add something to
> the certificate store, assuming it's a server certificate, it turns
> into a CA certificate.  This might be a problem in some cases.

But do you think anyone would still issue X.509v1 certificates?
To the best of my knowledge, most server certificates are short-lasting
(a few years) and all X.509v1 server certificates should have been
expired for long...
On the other hand, root certificates are supposed to be long-lasting (a
few tens of years), so it's not surprising that some very old root
certificates (including X.509v1 ones) are still in use...


Regards,

-- 
Nicolas Boullis
École Centrale Paris


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Florian Weimer]

* Nicolas Boullis:

>> You could try if recompiling gnutls13 with this patch
>> 
>> 
>> 
>> enables your setup to work.
>
> I just built it; it seems to work fine.

Thanks.

>> However, it is unlikely that we will
>> apply a similar change to lenny.  (For etch, the best approach is
>> still somewhat unclear.  But it's either changing gnutls13 in this
>> way, or keeping the current behavior; modifying all applications is
>> out of the question.)
>
> What's the problem with this patch?

The usual problem with X.509v1 certificates: if you add something to
the certificate store, assuming it's a server certificate, it turns
into a CA certificate.  This might be a problem in some cases.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Nicolas Boullis]

Hello Florian,

Florian Weimer wrote:
> 
>>Our servers use commercial certificates, with "GTE CyberTrust Global
>>Root" as the root certificate. It apparently is a v1 x509 certificate...
> 
> It's uses 1024 bit RSA, it is more than ten years old, and GTE
> Cybertrust does not exist anymore--GTE sold Cybertrust to Baltimore,
> Baltimore was sucked in to Betrusted, and Betrusted was bought by
> Verizon, so the key material is controlled by someone else these days.
> (It does not matter that the self-signature uses RSA-MD5.)

As Thijs Kinkhorst said, even if this sucks, this root certificate is
still in wide use in the european accademic community...


> You could try if recompiling gnutls13 with this patch
> 
> 
> 
> enables your setup to work.

I just built it; it seems to work fine.


> However, it is unlikely that we will
> apply a similar change to lenny.  (For etch, the best approach is
> still somewhat unclear.  But it's either changing gnutls13 in this
> way, or keeping the current behavior; modifying all applications is
> out of the question.)

What's the problem with this patch?
As for etch, I don't think the best approach is to keep things broken by
a security update.
As for lenny, I'd prefer not to have to add the intermediate CA to my
trusted list, but it certainly looks like a working solution.


Regards,

-- 
Nicolas Boullis
École Centrale Paris


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Florian Weimer]

* Thijs Kinkhorst:

> On sneon 14 Febrewaris 2009, Florian Weimer wrote:
>> > Our servers use commercial certificates, with "GTE CyberTrust Global
>> > Root" as the root certificate. It apparently is a v1 x509 certificate...
>>
>> It's uses 1024 bit RSA, it is more than ten years old, and GTE
>> Cybertrust does not exist anymore--GTE sold Cybertrust to Baltimore,
>> Baltimore was sucked in to Betrusted, and Betrusted was bought by
>> Verizon, so the key material is controlled by someone else these days.
>> (It does not matter that the self-signature uses RSA-MD5.)
>
> This may be true, but it is this certificate that is used as the root by for 
> example Terena, the association of all European NRENs, and hence are in use 
> by a very large part of the European academic community.
> http://www.terena.org/activities/scs/participants.html

Yuck. 8-(

> The certificate may be old, but this is unfortunately a given and
> hard to change.

Would you recommend to apply the X.509v1 hack (see the patch I linked
to) to lenny as well?


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Thijs Kinkhorst]

On sneon 14 Febrewaris 2009, Florian Weimer wrote:
> > Our servers use commercial certificates, with "GTE CyberTrust Global
> > Root" as the root certificate. It apparently is a v1 x509 certificate...
>
> It's uses 1024 bit RSA, it is more than ten years old, and GTE
> Cybertrust does not exist anymore--GTE sold Cybertrust to Baltimore,
> Baltimore was sucked in to Betrusted, and Betrusted was bought by
> Verizon, so the key material is controlled by someone else these days.
> (It does not matter that the self-signature uses RSA-MD5.)

This may be true, but it is this certificate that is used as the root by for 
example Terena, the association of all European NRENs, and hence are in use 
by a very large part of the European academic community.
http://www.terena.org/activities/scs/participants.html

The certificate may be old, but this is unfortunately a given and hard to 
change. That said, there are workarounds and of course in critical 
environments you'd test upgrades in a test environment before deploying them, 
so it's not the end of the world.


cheers,
Thijs


signature.asc
Description: This is a digitally signed message part.

Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Florian Weimer]

* Nicolas Boullis:

>> In addition, this update tightens the checks for X.509v1 certificates
>> which causes GNUTLS to reject certain certificate chains it accepted
>> before.  (In certificate chain processing, GNUTLS does not recognize
>> X.509v1 certificates as valid unless explicitly requested by the
>> application.)
>
> What the hell?
> After upgrading libgnutls13, our server could not anymore connect to our
> LDAP server, apparently because it does not like its certificate chain
> anymore...

Yes, this was sort of expected, but I had hoped that the fallout would
be minimal.

> Our servers use commercial certificates, with "GTE CyberTrust Global
> Root" as the root certificate. It apparently is a v1 x509 certificate...

It's uses 1024 bit RSA, it is more than ten years old, and GTE
Cybertrust does not exist anymore--GTE sold Cybertrust to Baltimore,
Baltimore was sucked in to Betrusted, and Betrusted was bought by
Verizon, so the key material is controlled by someone else these days.
(It does not matter that the self-signature uses RSA-MD5.)

We've received a similar report about a Valicert root, which has
similar issues due to its age (see #514807).

> What is the solution for me? Should I rebuild all the applications and
> libraries that use libgnutls, so that they request to accept x509v1
> certificates? How?

You could try if recompiling gnutls13 with this patch



enables your setup to work.  However, it is unlikely that we will
apply a similar change to lenny.  (For etch, the best approach is
still somewhat unclear.  But it's either changing gnutls13 in this
way, or keeping the current behavior; modifying all applications is
out of the question.)

You could add your server's certificate to the trusted certificate
store (assuming it's a v3 certificate).  Requesting a new certificate
located under a X.509v3 from your certificate provider would also
work.  If you mark your server certificates as trusted and remove all
CAs from the trusted CA list, you also isolate yourself from attacks
on careless CAs (which might issue certificates for the domain name of
your LDAP server in an unauthorized fahsion).  Unfortuantely, we
haven't got a good way to flag those problematic CAs which are only
good to make browser warnings disappear.

I'm not sure if a X.509v3 version of the root certificate would work,
or would create significant interop problems.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1719-1] New gnutls13 packages fix certificate validation

[Nicolas Boullis]

Hi,

Florian Weimer wrote:
> 
> In addition, this update tightens the checks for X.509v1 certificates
> which causes GNUTLS to reject certain certificate chains it accepted
> before.  (In certificate chain processing, GNUTLS does not recognize
> X.509v1 certificates as valid unless explicitly requested by the
> application.)

What the hell?
After upgrading libgnutls13, our server could not anymore connect to our
LDAP server, apparently because it does not like its certificate chain
anymore...

Our servers use commercial certificates, with "GTE CyberTrust Global
Root" as the root certificate. It apparently is a v1 x509 certificate...

What is the solution for me? Should I rebuild all the applications and
libraries that use libgnutls, so that they request to accept x509v1
certificates? How?

-- 
Nicolas Boullis


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org