[RFC] OpenSSL accepts "invalid" server cert chain

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] OpenSSL accepts "invalid" server cert chain

David Woodhouse-7
I have encountered a server which presents an invalid set of
certificates in its TLS handshake.

It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain from #2->#3->#4 is fine,
but #2 isn't actually the issuer of #1. (It just happens to have the
same *name* as the issuer of #1; cf. RT#1942).

This violates RFC5246 §7.4.2, which says of the certificate_list that:
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.

However, the missing intermediate CA *is* found in my local trust
database, and OpenSSL verifies the server quite happily using *that*.

This seems wrong — surely the handshake should be rejected? Should I
submit a patch?

I note that GnuTLS *does* reject the server's handshake — and rightly
so, as far as I can tell from the RFC.

--
dwmw2

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] OpenSSL accepts "invalid" server cert chain

Ryan Hurst-3
David,

Failing when a server sends the certificates out of order would result in a large % of transactions failing. On platforms other than Windows the order is determined by the server administrator and what order they put them in the configuration.

I recommend not changing the behavior here, there are plenty of cases where standards say one strict behavior but clients have to be flexible enough to work around what's really out in the wild and this is just one of them.

Also RFC 5280 (chain validation RFC) is designed to work in these cases, so in that respect OpenSSL is RFC compliant.

One could potentially propose a patch that would be used by nginx, apache, etc to do chain validation against the configured certificates before sending the certs to ensure that the implementations also send them in order though -- this is what Windows does.

Ryan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Woodhouse
Sent: Thursday, July 12, 2012 6:36 AM
To: [hidden email]
Subject: [RFC] OpenSSL accepts "invalid" server cert chain

I have encountered a server which presents an invalid set of
certificates in its TLS handshake.

It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain from #2->#3->#4 is fine,
but #2 isn't actually the issuer of #1. (It just happens to have the
same *name* as the issuer of #1; cf. RT#1942).

This violates RFC5246 §7.4.2, which says of the certificate_list that:
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.

However, the missing intermediate CA *is* found in my local trust
database, and OpenSSL verifies the server quite happily using *that*.

This seems wrong — surely the handshake should be rejected? Should I
submit a patch?

I note that GnuTLS *does* reject the server's handshake — and rightly
so, as far as I can tell from the RFC.

--
dwmw2

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [RFC] OpenSSL accepts "invalid" server cert chain

Erwann ABALEA
In reply to this post by David Woodhouse-7
Le 12/07/2012 15:36, David Woodhouse a écrit :
> I have encountered a server which presents an invalid set of
> certificates in its TLS handshake.

This is common. Really common.

> It's presenting four certificates, where the second cert is *not* the
> issuer of the first cert in the list. The chain from #2->#3->#4 is fine,
> but #2 isn't actually the issuer of #1. (It just happens to have the
> same *name* as the issuer of #1; cf. RT#1942).

If it has the same name, then it's the same CA. Has it been rekeyed?

> This violates RFC5246 §7.4.2, which says of the certificate_list that:
>        This is a sequence (chain) of certificates.  The sender's
>        certificate MUST come first in the list.  Each following
>        certificate MUST directly certify the one preceding it.
>
> However, the missing intermediate CA *is* found in my local trust
> database, and OpenSSL verifies the server quite happily using *that*.

As do other toolkits and browsers.

> This seems wrong — surely the handshake should be rejected? Should I
> submit a patch?
>
> I note that GnuTLS *does* reject the server's handshake — and rightly
> so, as far as I can tell from the RFC.

Does GnuTLS have access to the missing intermediate CA, too?
GnuTLS is not really a good example, it doesn't follow X.520 naming, and
doesn't enforce the pathLen constraints.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] OpenSSL accepts "invalid" server cert chain

Erik Tkal
In reply to this post by David Woodhouse-7
If the actual issuing CA is in your trust store and can be shown to have validly issued the server certificate, then by definition you trust that server.

....................................
Erik Tkal
Juniper OAC/UAC/Pulse Development


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Woodhouse
Sent: Thursday, July 12, 2012 9:36 AM
To: [hidden email]
Subject: [RFC] OpenSSL accepts "invalid" server cert chain

I have encountered a server which presents an invalid set of
certificates in its TLS handshake.

It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain from #2->#3->#4 is fine,
but #2 isn't actually the issuer of #1. (It just happens to have the
same *name* as the issuer of #1; cf. RT#1942).

This violates RFC5246 §7.4.2, which says of the certificate_list that:
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.

However, the missing intermediate CA *is* found in my local trust
database, and OpenSSL verifies the server quite happily using *that*.

This seems wrong — surely the handshake should be rejected? Should I
submit a patch?

I note that GnuTLS *does* reject the server's handshake — and rightly
so, as far as I can tell from the RFC.

--
dwmw2
:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [RFC] OpenSSL accepts "invalid" server cert chain

David Woodhouse-7
In reply to this post by Erwann ABALEA
On Thu, 2012-07-12 at 20:44 +0200, Erwann Abalea wrote:

> Le 12/07/2012 15:36, David Woodhouse a écrit :
> > I have encountered a server which presents an invalid set of
> > certificates in its TLS handshake.
>
> This is common. Really common.
>
> > It's presenting four certificates, where the second cert is *not* the
> > issuer of the first cert in the list. The chain from #2->#3->#4 is fine,
> > but #2 isn't actually the issuer of #1. (It just happens to have the
> > same *name* as the issuer of #1; cf. RT#1942).
>
> If it has the same name, then it's the same CA. Has it been rekeyed?
It has a different X509v3 Subject Key Identifier.

The Subject Key Identifier of the second cert in the list does not match
the Authority Key Identifier of the first cert. It's a broken chain. The
server MUST NOT do this.

> > I note that GnuTLS *does* reject the server's handshake — and rightly
> > so, as far as I can tell from the RFC.
>
> Does GnuTLS have access to the missing intermediate CA, too?

Yes. If the server had *omitted* the invalid intermediate CAs from its
handshake and presented only the leaf certificate, GnuTLS would have
accepted it. But when the server has blatantly violated the TLS
standard, GnuTLS fails validation without checking further.


To be honest, I don't care much whether it's accepted or not. The
responses so far seem to suggest that accepting it would be a good idea.
But what I care most about is that my VPN client behaves consistently
whether it's linked against OpenSSL or GnuTLS.

It sounds like I should 'fix' the GnuTLS side to accept this, even
though it's broken behaviour on the part of the server. Thanks to
everyone who replied.

--
dwmw2

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [RFC] OpenSSL accepts "invalid" server cert chain

Peter Sylvester-3
On 07/12/2012 10:00 PM, David Woodhouse wrote:

>> If it has the same name, then it's the same CA. Has it been rekeyed?
> It has a different X509v3 Subject Key Identifier.
>
> The Subject Key Identifier of the second cert in the list does not match
> the Authority Key Identifier of the first cert. It's a broken chain. The
> server MUST NOT do this.
sorry, a chain is defined by the names, not by key identifiers.
there is strictly no requirement the subject and key identifiers must match.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]