CAs, server key permanence, SSL weaknesses (X.509 support in ssh)

[Peter Watkins]

On Wed, Jan 23, 2002 at 12:07:28PM -0600, mouring at etoh.eviladmin.org wrote:

> On Wed, 23 Jan 2002, Ed Phillips wrote:

> > I would think that the benefit here is that if your client is configured
> > to trust only certain signers, then Joe Hacker can't play
> > man-in-the-middle during the "should I accept this hostkey" question,
> > because Joe Hacker shouldn't have the private key for the CA you trust.
> >
> > Isn't that an improvement?

> Until your CA's employees do something brain dead like hand out a copy of
> your key to someone who 'claims' to be an employee of your company.

> Think warm fuzzy thoughts that your CA is trustworthy. =)

:-) To be fair, and not come across as a complete apologist for CAs, I think
it may be worthwhile to point out that part of the reason CAs are needed for
https and Web commerce is not simply the difficulty of distributing Amazon's
server keypair. Protocol design and server key permanence are important
factors in the importance of CA certs for SSL/TLS. Except for the weak
"export" ciphers, the RSA ciphers for SSL/TLS lack what's known as Perfect
Forward Secrecy. Anyone who posesses a copy of the server keys can decrypt
any traffic to any server using those server keys. Let's say
merchant.example.com sets up shop on January 1st.  Does a lot of SSL. Some
black hat records all the traffic, but can't read any of it because it uses
the fairly strong 128-bit RSA SSL/TLS ciphers. But the black hat's
significant other does some dumpster diving, turns up the server key from
merchant.example.com, and presents it as a Kwanzaa gift.  Voila, the black
hat can now decrypt all that captured traffic. 

It doesn't have to be that way, but that's how the spec was written. My
personal belief, based on my lurking in the TLS IETF working group's mailing
list, is that certain big software companies have exerted pressure on the
IETF not to require better ciphers, fearing the ciphers would hurt server
performance (and Web admins generally agree that https is a bear compared to
http, of course). So, generally speaking, when a company like
merchant.example.com renews its annual SSL/TLS cert, it generates a new
server keypair.[0] IMO, this ought to happen more often, but... The point is
that in https (and SSL/TLS in general), it is *expected* that server certs
will be periodically replaced. So a static cache like OpenSSH uses would not
be appropriate. A static cache would prevent merchant.example.com from
replacing their cert, giving the data-sniffing black hats even more to gain
if/when they got the server keypair. CAs are critcial to allowing merchants
to replace their keys, to reduce the risks involved in keypair compromise.

Of course that brings us to the other side of PKI, the downside of OpenSSH's 
static hostkey cache. With https, a merchant can fairly effectively[1] 
disavow a keypair & replace it if it believes the key was compromised, to 
protect future traffic[2], by revoking the cert -- the revoked cert would 
then be disavowed with the CA's Certificate Revocation List. How is the 
admin of an sshd server supposed to handle a situation where his sshd servre 
keypair has been compromised? 

-Peter

[0] At least commercial products like iPlanet Web Server generate new kesy 
whenever they generate new Certificate Signing Requests; I believe with 
something like Apache + mod_ssl + 'openssl' it's easy to reuse a key, bad
as that is to do.

[1] This is up to the client, of course, just as an ssh client could "ignore
and add" a host key if it were poorly designed/configured.

[2] Revoking a compromised cert of course does nothing to protect past 
traffic that may have been captured, and is now decipherable by the attacker.

-- 
We must all learn to live together as brothers,
or we will all perish as fools. - Dr Martin Luther King, Jr