headers
Matt McCutchen | 1 Sep 2010 02:09

Re: Root certificates in server certificate chains

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

On Tue, 2010-08-31 at 22:30 +0000, 1.41421 <at> gmail.com wrote:
> 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?

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.
(Continue reading)

Permalink | Reply |
headers
Marsh Ray | 1 Sep 2010 03:56
Favicon

Re: Root certificates in server certificate chains

On 08/31/2010 07:09 PM, Matt McCutchen wrote:
> The following is my understanding.  Others should feel free to disagree
> or correct me.
>
> On Tue, 2010-08-31 at 22:30 +0000, 1.41421 <at> gmail.com wrote:
>> 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?
>
> Like any other tampering with the handshake, this would cause the
> Finished check to fail.

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

>> Actually, doesn't this render the whole idea of authentication of the
>> 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?

>> But, in this case, why allow the server to include a root certificate
(Continue reading)

Permalink | Reply |
headers
Blumenthal, Uri - 0668 - MITLL | 1 Sep 2010 04:15
Picon

Re: Root certificates in server certificate chains

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:marsh <at> extendedsubset.com]
Sent: Tuesday, August 31, 2010 09:56 PM
To: Matt McCutchen <matt <at> mattmccutchen.net>
Cc: 1.41421 <at> gmail.com <1.41421 <at> gmail.com>; tls <at> ietf.org <tls <at> ietf.org>
Subject: Re: [TLS] Root certificates in server certificate chains

On 08/31/2010 07:09 PM, Matt McCutchen wrote:
> The following is my understanding.  Others should feel free to disagree
> or correct me.
>
> On Tue, 2010-08-31 at 22:30 +0000, 1.41421 <at> gmail.com wrote:
>> 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
(Continue reading)

Permalink | Reply |
headers
Matt McCutchen | 1 Sep 2010 04:15

Re: Root certificates in server certificate chains

On Tue, 2010-08-31 at 20:56 -0500, Marsh Ray wrote:
> On 08/31/2010 07:09 PM, Matt McCutchen wrote:
> > The following is my understanding.  Others should feel free to disagree
> > or correct me.
> >
> > On Tue, 2010-08-31 at 22:30 +0000, 1.41421 <at> gmail.com wrote:
> >> 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?
> >
> > Like any other tampering with the handshake, this would cause the
> > Finished check to fail.
> 
> Not if the attacker is successful in getting the client to accept his 
> 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
Permalink | Reply |
headers
Marsh Ray | 1 Sep 2010 04:49
Favicon

Re: Root certificates in server certificate chains

On 08/31/2010 09:15 PM, Matt McCutchen wrote:
> On Tue, 2010-08-31 at 20:56 -0500, Marsh Ray wrote:
>>
>> Not if the attacker is successful in getting the client to accept his
>> 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.

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
Permalink | Reply |
headers
Matt McCutchen | 1 Sep 2010 06:54

Re: Root certificates in server certificate chains

On Tue, 2010-08-31 at 21:49 -0500, Marsh Ray wrote:
> On 08/31/2010 09:15 PM, Matt McCutchen wrote:
> > On Tue, 2010-08-31 at 20:56 -0500, Marsh Ray wrote:
> >>
> >> Not if the attacker is successful in getting the client to accept his
> >> 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.
> 
> 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.

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
(Continue reading)

Permalink | Reply |
headers
Marsh Ray | 1 Sep 2010 07:57
Favicon

Re: Root certificates in server certificate chains

On 08/31/2010 11:54 PM, Matt McCutchen wrote:
> On Tue, 2010-08-31 at 21:49 -0500, Marsh Ray wrote:
>>
>> 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.
>
> 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.

Yes, at times a very effective one.

> 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.

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.
(Continue reading)

Permalink | Reply |
headers
Matt McCutchen | 1 Sep 2010 08:07

Re: Root certificates in server certificate chains

On Wed, 2010-09-01 at 00:57 -0500, Marsh Ray wrote:
> On 08/31/2010 11:54 PM, Matt McCutchen wrote:
> > 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.
> 
> 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.

> 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.

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
Permalink | Reply |
headers
Martin Rex | 15 Sep 2010 02:44
Picon
Favicon

Re: Root certificates in server certificate chains

Matt McCutchen wrote:
> 
> 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.

At the TLS level, this is not a MitM attack.
TLS (at least when no old/vulnerable renegotiation can be coerced)
reliably protects against MitM.  What you're describing, if it
succeeds at the TLS level, is a TLS server impersonation, and
unless the the server has somehow acquired the real servers
credentials, could only happen if the clients method to
identify (or authenticate) the server is fatally flawed.

At the application(!) level, the attack might might still
be an MitM attack.  It does not necessarily require an
TLS-encrypted communication channel between the impersonating
server and the real server. 

-Martin
Permalink | Reply |

Gmane