[Pkg-openssl-devel] Bug#640457: [openssl] some Verisign certificates fail to verify

[Kyle Moffett]

reassign 640457 konqueror
thanks

On Sun, Oct 16, 2011 at 11:54, Maximilian Engelhardt <maxi at daemonizer.de> wrote:
> On Friday 14 October 2011 07:28:00 Kyle Moffett wrote:
>> > So chain-0 can be verified by chain-1 and chain-1 can be verified by the
>> > system installed CAs.
>> >
>> > The problem is that
>> > VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt
>> > got updated in ca-certificates 20110421.
>> > And the last certificated sent by the server (chain-2) is the old version
>> > of this same certificate.
>> >
>> > $ openssl x509 -noout -subject -issuer -in
>> > /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_-
>> > _G5.pem
>> > subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
>> > VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
>> > Primary Certification Authority - G5
>> > issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
>> > VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
>> > Primary Certification Authority - G5
>> >
>> > So it seems like openssl first uses the certificate that's send from the
>> > server, but then fails to verify it (as it can't find an appropriate root
>> > certificate). Instead it should ignore the sent certificate and use the
>> > one that is installed on the local system and thus trusted as root
>> > certificate.
>> >
>> > This behaviour is especially a problem for me since konqueror uses
>> > openssl to verify the certificates and there are quite some sites that
>> > deliver the old certificate in the chain.
>> >
>> > Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt
>> > -p 443 signin.ebay.de" does verify the certificate just fine.
>>
>> This PHP bug-report seems basically identical:
>>   https://bugs.php.net/bug.php?id=49419
>>
>> Based on my understanding of TLS and from that PHP bug-report... I'm
>> actually pretty sure that this is not a bug.  According to the TLS
>> standard (RFC2246):
>>    certificate_list
>>        This is a sequence (chain) of X.509v3 certificates. The sender's
>>        certificate must come first in the list. Each following
>>        certificate must directly certify the one preceding it. Because
>>        certificate validation requires that root keys be distributed
>>        independently, the self-signed certificate which specifies the
>>        root certificate authority may optionally be omitted from the
>>        chain, under the assumption that the remote end must already
>>        possess it in order to validate it in any case.
>>
>> The certificates passed in the protocol must be a strict sequence.
>> Any server sending out-of-order or bogus certificates in the chain is
>> not complying with the TLS protocol requirements, and cannot
>> reasonably expect to validate correctly.  It's entirely possible that
>> some implementations are much more lenient than others, but the
>> standard itself seems very obvious as to the requirement.
>>
>> As far as I can tell, OpenSSL implements a very safe default for SSL
>> certificate chain construction and requires the application to
>> implement a more advanced model if desired.  This is basically a
>> server configuration problem, and at best this should be a feature
>> request against konqueror to better handle broken server
>> configurations.
>>
>> Please note that GnuTLS has historically been missing a number of the
>> stricter checks that OpenSSL provides by default, and that those tend
>> to get added to GnuTLS when their absence is identified.  For example,
>> OpenSSL has always checked certificate validity times by default, but
>> prior to CVE-2009-1417, the GnuTLS library relied upon the application
>> to perform those checks (and most did not).
>>
>> Let me know if you want me to reassign this bug to konqueror or close
>> it as "wontfix".
>
> Hello Kyle,
>
> thanks for your detailed explanation. So this seems to be a Konqueror bug,
> perhaps even an upstream KDE bug.
>
> On the other hand this might also be a ca-certificates bug, since it doesn't
> ship the old Verisign root certificate anymore, but without that certificate
> openssl will fail to verify any chain that uses it (and it seems to be wildly
> used).

No, ca-certificates still ships the old Verisign root certificate.
What changed is that the website you were accessing upgraded from
their old certificate (issued with the old Verisign root) to a new one
(issued by the new Verisign root), but they did not fix their
certificate chain file to match.

> I'm not really sure if it's a Konqueror or a ca-certificates bug, so feel free
> to reassign it to whatever you think fits best, perhaps Konqueror, as you did
> suggest in your last mail.

I have reassigned this bug to konqueror.

> I'm wondering how many other programs that use openssl experience the same
> problem.

This is an extremely common error among website operators, as most of
the TLS implementations don't actually have very good diagnostics for
identifying and fixing the issue.  I have had this exact same issue
myself with SMTP TLS, and the fix involved a configuration change on
the server.

In this case, it is very definitely a server misconfiguration.  The
only question is: How far should web browsers and TLS clients go in
verifying server certificates when the server is providing a garbage
certificate chain?  It's the same fundamental issue with the "Be
strict in what you admit and lenient in what you accept" policy that
has plagued HTML; at some point you have a bunch of disparate
implementations and *none* of them are compliant with the standards
because most of the others are willing to tolerate most of the bugs.

Cheers,
Kyle Moffett

-- 
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/