Re: Clarification of my remarks about Netscape

[Hal <hfinney@shell.portal.com>]

-----BEGIN PGP SIGNED MESSAGE-----

From: kipp@warp.mcom.com (Kipp E.B. Hickman)
> From the spec, the appendix on certificates:
> 
>    Certificates are validated using a few straightforward steps. First,
>    the signature on the certificate is checked and if invalid, the
>    certificate is invalid (either a transmission error or an attempted
>    forgery occurred). Next, the CertificateInfo::issuer field is verified
>    to be an issuer that the application trusts (using an unspecified
>    mechanism). The CertificateInfo::validity field is checked against the
>    current date and verified.
> 
> Here is what we do in Netscape (for now). We have imbedded a set of
> certificates in the client. The certificates are for issuers of
> certificates that "we" trust. Any server which is certified by one of
> these issuers will be automatically trusted by the Netscape
> Navigator...
> 
> Admittedly this is primitive, but it's a start.

Thanks, I had overlooked that in the appendix.  I notice you left off the
next paragraph:

          Finally, the CertificateInfo::subject field is checked. This
          check is optional and depends on the level of trust required by
          the application using SSL.

This subject field would hold the distinguished name of the server.  That
is pretty important to check!  Otherwise anybody with any old certificate
will fool you.  In your appendix D when you describe the man in the
middle attack, you say:

          The man in the middle operates by pretending to be the real
          server to the client. With SSL this attack is impossible
          because of the usage of server certificates. During the
          security connection handshake the server is required to provide
          a certificate that is signed by a certificate authority.
          Contained in the certificate is the server's public key as well
          as its name and the name of the certificate issuer. The client
          verifies the certificate by first checking the signature and
          then verifying that the name of the issuer is somebody that the
          client trusts.

This is in accord with your description above.  Note that the only name
check mentioned is the name of the issuer.  But later, in analyzing this
attack, you say:

          If the certificate provided by the
          bad guy is legitimate, but for the bad guy instead of for the
          real server, then the signature will pass but the name check
          will fail

Here you must mean a different name check, the optional one that checks
the subject field.  So this analysis is somewhat inconsistent with the
procedure I quoted just above.  Also, when you describe the subject name
check as "optional" and depending on the required level of trust, perhaps
you should say explicitly that if you don't do it you are vulnerable to a
man in the middle attack.

Actually, the attack is more general than that: if I could intercept
connections to your server and use my own certificate to make the user
think he is securely talking to you then I don't actually have to involve
you at all.  I am not a man in the middle, I am a spoofer pretending to
be you.  And you have marked the important step in the protocol which
would check for this as optional.

It appears from your docs that the Netscape client has a File menu item
that brings up a Document Information dialog box which displays the
distinguished names of the certificate issuer and of the subject (the
owner of the key).  This does provide a way of checking that you are
securely connected to the server that you expect (assuming that the
name is recognizable to the user).  But it sounds like this is not
something which the customer sees automatically.  Again, this seems
like an important security aspect which should be displayed more
prominently.

BTW, what do you see in the dialog when you connect securely to
mcom.com?  What is the subject name in your certificate?

I hope these comments are helpful to you.  I am surprised that you
published this spec only after distributing implementations of it.  This
wil probably make it hard to change.  Usually it is better to do the
review before implementation rather than afterwards.

Hal Finney
hfinney@shell.portal.com

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLu9zThnMLJtOy9MBAQEVPgH+KObAFiOsALCGokUzk7gsqpnVEda85MUD
5LU5P2GjFhmR5msBKr6uuDKSrodUl69bq0/CfpE3qYSzcz7SGPrrag==
=ivlO
-----END PGP SIGNATURE-----