Subject: [TLS] Root certificates in server certificate chains

From: [email-masked]
Date: Tue, 31 Aug 2010 22:30:54 +0000

The standard (RFC 5246, sec. 7.4.2) says that a server certificate chain  
may include, as the last entry in this chain, the root certificate that is  
to be considered the ultimate trust anchor as far the server certificate is  
concerned. What would prevent an attacker from inserting a Certificate  
message of its own during the handshake, containing a totally bogus root  
certificate? Actually, doesn't this render the whole idea of authentication  
of the remote useless? How can one make sure that a root certificate  
received in a certificate chain is genuine? The only thing I can think of  
would consist of comparing it against its matching, locally-stored root  
certificate (which is assumed to have been copied by secure means, whatever  
those may be.) But, in this case, why allow the server to include a root  
certificate in the certificate chain in the first place? In this light, is  
it correct to assume that if a root certificate is present in the server  
certificate chain and also in local, permanent storage, the latter must be  
used, rather than the former?

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 01 Sep 2010 02:03:05 +0200

On 09/01/2010 12:30 AM, [email-masked] wrote:

Dear truncated squareroot:
> The standard (RFC 5246, sec. 7.4.2) says that a server certificate 
> chain may include, as the last entry in this chain, the root 
> certificate that is to be considered the ultimate trust anchor as far 
> the server certificate is concerned.
It doesn't say 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.  Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate that specifies the root
       certificate authority MAY be omitted from the chain, under the
       assumption that the remote end must already possess it in order to
       validate it in any case.

IMO it says that one may send what it
believes to be a useful chain including a potential trust anchor
represented by a self signed (root) cert. Not more.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 31 Aug 2010 20:09:44 -0400

The following is my understanding.  Others should feel free to disagree
or correct me.

On Tue, 2010-08-31 at 22:30 +0000, [email-masked] wrote:
> the server certificate is concerned. What would prevent an attacker
> from inserting a Certificate message of its own during the handshake,
> containing a totally bogus root certificate?

Like any other tampering with the handshake, this would cause the
Finished check to fail.

> Actually, doesn't this render the whole idea of authentication of the
> remote useless? How can one make sure that a root certificate received
> in a certificate chain is genuine? The only thing I can think of would
> consist of comparing it against its matching, locally-stored root
> certificate (which is assumed to have been copied by secure means,
> whatever those may be.)  In this light, is it correct to assume that
> if a root certificate is present in the server certificate chain and
> also in local, permanent storage, the latter must be used, rather than
> the former?

Yes, the client MUST verify the chain using a locally stored root
certificate, i.e., a trust anchor.  If the server sends a root
certificate that is one of the client's trust anchors, that's fine.  If
the server sends a root certificate that is not a trust anchor of the
client, the client MAY ignore it or fail the handshake.

More generally, a client that receives an incomplete, misordered, or
otherwise invalid chain from a non-compliant server MAY fail the
handshake or proceed if it is able to construct a valid chain some other
way.

> But, in this case, why allow the server to include a root certificate
> in the certificate chain in the first place?

Perhaps as a hint to clients that might decide they wish to add that
certificate as a trust anchor, possibly after further research?

-- 
Matt

---

From: Marsh Ray <[email-masked]>
Date: Tue, 31 Aug 2010 20:56:53 -0500

> Like any other tampering with the handshake, this would cause the

Not if the attacker is successful in getting the client to accept his 
proposed root certificate.

>> remote useless?

Sure, if the client is willing to accept it.

>> How can one make sure that a root certificate received
>> in a certificate chain is genuine?

Perhaps the client already trusts that root cert or key? If so, why even 
bother to send it?

> certificate as a trust anchor, possibly after further research?

To make it easier for users to "Permanently store this exception"?  :-P

- Marsh

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Tue, 31 Aug 2010 22:15:23 -0400

Sending root cert makes sense for Trust model based on computed probabilities - which does not exist today except in research papers.

The idea is - you verify as much as practical, and decide how much you trust the requester regarding his request.

E.g. consider two questions: "can I use your phone?" and "can I use your car?"
 
Oh, and the current trust model has little room for root cert as a part of the transmitted chain. Although - a home-grown CA, a bunch of pals establishing a  TLS-protected Web chat site...? No need to get VeriSign involved... Why not? 

--
Regards,
Uri

----- Original Message -----
From: Marsh Ray [mailto:[email-masked]]
Sent: Tuesday, August 31, 2010 09:56 PM
To: Matt McCutchen <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [TLS] Root certificates in server certificate chains

- Marsh
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 31 Aug 2010 22:15:59 -0400

> proposed root certificate.

I think we are answering different questions.  The attacker can of
course act as a MITM using the proposed root certificate.  But any
manipulation of the handshake between two parties that falls short of a
full MITM will prevent the Finished check from passing, unless the
attacker can cause a rollback to a cipher suite he can break in order to
forge the Finished messages.

-- 
Matt

---

From: Marsh Ray <[email-masked]>
Date: Tue, 31 Aug 2010 21:49:18 -0500

> forge the Finished messages.

My guess is that an attacker could tell whether or not the client was 
"taking the bait" and so he wouldn't pass the Finished messages at all 
unless they were expected to validate at one or both ends.

An aborted attack might not look much different to the legitimate client 
and server than ordinary packet loss.

- Marsh

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 01 Sep 2010 00:54:48 -0400

> and server than ordinary packet loss.

What attack are you describing?  If the attacker replaces the entire
Certificate message with one containing his public key chained to a
bogus root certificate, that is just a MITM attack.  If the attacker
does some tampering but does not replace the server's public key with
his own, he has no way to generate valid Finished messages.

-- 
Matt

---

From: Marsh Ray <[email-masked]>
Date: Wed, 01 Sep 2010 00:57:45 -0500

On 08/31/2010 11:54 PM, Matt McCutchen wrote:
> bogus root certificate, that is just a MITM attack.

Yes, at times a very effective one.

> If the attacker

Why would he do something like that? Why even bring it up?

I don't know if this is what you had in mind, but on example might be 
that he only cares about a valid Finished message in one direction. For 
non-resumption handshakes, the client is forced to transmit his valid 
Finished message before he has a chance to validate much of anything 
about the server's identity or the handshake. Under certain conditions, 
certain servers will perform some "highly non idempotent" actions upon 
the receipt of the clients valid Finished verify_data.

- Marsh

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 01 Sep 2010 02:07:33 -0400

> Why would he do something like that? Why even bring it up?

I thought that was what 1.41421 originally proposed, but maybe I
misunderstood.

> the receipt of the clients valid Finished verify_data.

I did not have that in mind, and a modification to the handshake will
break /both/ Finished messages, so it is not a problem.

-- 
Matt