Subject: Re: [TLS] Root certificates in server certificate chains

From: Peter Gutmann <[email-masked]>
Date: Wed, 01 Sep 2010 20:49:24 +1200

Marsh Ray <[email-masked]> writes:

>http://www.google.com/search?hl=en&q=%22begin+rsa+private+key%22+site%3Apastebin.com

Ah, another fan of the ubiquitous pastebin.  Back when PKIX was inventing yet
another one of its move-certs-around protocols for everyone to ignore I almost
wrote an April 1 RFC on "Certificate Management via Pastebin", which seems to
represent one of the more successful PKI protocols around.

Peter.

---

From: Kyle Hamilton <[email-masked]>
Date: Sun, 12 Sep 2010 14:59:44 -0700

On 8/31/10 10:33 PM, Matt McCutchen wrote:
> The server's CertificateRequest will contain Root A's distinguished
> name, and the client should use that as the indication of where to stop.
> Again, there is no benefit to sending the actual certificate for Root A.
No benefit except the difference between seeing only a single broken 
certificate in the chain and the proposed certificate chain.

Granted, only a small percentage of the user base will actually *see* 
it... you could call it 'advertising at the cost of about 800 bytes per 
TLS session'.

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Sep 2010 02:44:35 +0200 (MEST)

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