Re: NetScape's dependence upon RSA down for the count!

> From ses@tipper.oit.unc.edu Sat Sep 30 20:43:51 1995

> My currently recommended approach is to enforce the verisign requirement 
> that all valid hostnames for the server be included in the certificate as 
> CN values. This allows the check to be made below the application layer. 
> Unfortunately a lot of currently issued certificates are non-compliant 
> (even Verisign and netscape :-); any fully automated implementation needs 
> a static table of hostnames aliases- interactive applications can 
> display certificates for manual review.

I don't think binding hostnames to certificates helps much because 
both hostnames and IP addresses can be spoofed and DNS servers can be 
subverted.  The important thing is the binding to the "service" name or 
definition (e.g. InterState online banking service).


> This is not really much protection. Getting hold of any key is much 
> easier than getting a specific key, and don't forget there are a number 
> of vulnerable keys floating around until their expiration dates pass. 

Well of course, if the secret key of the server (or worse yet, certificate 
authority) is compromised, all bets are off.  That's true of just about any 
protocol you can dream up.

Are you just referring to the problem of accurate and up to date certificate 
revocation lists (CRL) being available ?

If so, you're right, this is a very difficult problem to solve without 
having a truly reliable and pervasive key-distribution & CRL system 
deployed throughout the world.

- Don

On Sat, 30 Sep 1995, Don Stephenson wrote:

> I don't think binding hostnames to certificates helps much because 
> both hostnames and IP addresses can be spoofed and DNS servers can be 
> subverted.  The important thing is the binding to the "service" name or 

In this particular case, hostnames do help, because they are information 
imbedded in the url used to access the server. By verifying the hostname 
in the certificate with the hostname in the url, you can state with a 
high degree of confidence that the object retrieved is precisely the 
desired object covered by this url. 

> Well of course, if the secret key of the server (or worse yet, certificate 
> authority) is compromised, all bets are off.  That's true of just about any 
> protocol you can dream up.

I'm not referring to the secret key of _the_ server; I'm referring to the 
secret key of _ANY_ server. In the limiting case, such a key can be 
obtained by buying one from the CA. 

Simon

> On Sat, 30 Sep 1995, Don Stephenson wrote:
> 
> > I don't think binding hostnames to certificates helps much because 
> > both hostnames and IP addresses can be spoofed and DNS servers can be 
> > subverted.  The important thing is the binding to the "service" name or 
> 
> In this particular case, hostnames do help, because they are information 
> imbedded in the url used to access the server. By verifying the hostname 
> in the certificate with the hostname in the url, you can state with a 
> high degree of confidence that the object retrieved is precisely the 
> desired object covered by this url. 

Assume that the attacker Mallet is in the middle and has control of the http
stream.  Alice clicks on 'open Widget order form' to order a Widget
and Mallet sends her browser a redirect pointing to his evil web server.
Alice doesn't notice that the hostname in the url has changed, or
if she does, she figures that the catalog people have arranged to
have Mallet's server host their 'secure' transactions (not an unreasonable
assumption).  Mallet takes the order and pockets the money.
The hostname in the certificate (Mallet's) matches the hostname
in the URL (also Mallet's).

Of course this isn't really an attack on SSL per se.  It's an attack on
the certificate-granting policy- the CA gave a certificate to
an unscrupulous person (Mallet).

> 
> > Well of course, if the secret key of the server (or worse yet, certificate 
> > authority) is compromised, all bets are off.  That's true of just about any 
> > protocol you can dream up.
> 
> I'm not referring to the secret key of _the_ server; I'm referring to the 
> secret key of _ANY_ server. In the limiting case, such a key can be 
> obtained by buying one from the CA. 

Right. That's what I pointed out in an earlier message, although I
didn't elaborate on it.   The security of Netscape browsers depends
on Verisign's policy in handing out server certificates.


Backing up for a minute, the same problem holds for those neeto
credit-card readers that Visa and MasterCharge give out to merchants.
The merchant can be a crook setting up a 'store-front' operation to charge
to bogus/stolen card numbers, or the employees can steal using the numbers
they get in the corse of doing business, etc.  There are already
procedures in place for dealing with this sort of crime.  I'm not
sure that tricking Verisign into giving out a certificate to a group
of crackers is really any different than tricking Visa into giving
a card reader to a group of theives.

-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF