> David Schwartz wrote:
> > "Does the domain name in the server's certificate match the
> > domain name of
> > the server itself? This step confirms that the server is
> > actually located at
> > the same network address specified by the domain name in the server
> > certificate. Although step 4 is not technically part of the SSL
> > protocol, it
> > provides the only protection against a form of security attack
> > known as a
> > Man-in-the-Middle Attack. Clients must perform this step and
> > must refuse to
> > authenticate the server or establish a connection if the domain
> > names don't
> > match. If the server's actual domain name matches the domain name in the
> > server certificate, the client goes on to Step 5."
> Uh, I'm a wee bit annoyed at the invocation of MITM. It seems
> to me that SSLv3.0/TLSv1.0 with server auth protects against
> MITM, and it has nothing to do with the validation described.
What? it's this authentication that protects against a MITM.
> We know at the conclusion of the handshake that we are talking to
> the server which presented its certificate, and we presume (absent
> its inclusion in a CRL, OCSP response, etc.) the security of the
> associated private key. This entire negotiation is proof against
> MITM. We've validated the cert according to local rules (we
> trust the signer, have done chain validation, whatever).
Huh?! If I ask for 'www.amazon.com', I don't care whether I have a secure
or insecure connection to 'www.microsoft.com' or 'www.evil-mitms.com'. I
care that the certificate I got doesn't match the server I chose to trust.
A MITM can get a certificate for something.
> Fine, all SSL/TLS does is establish a secure channel between (in this
> case) the authenticated server and the client.
Yes, that's all SSL/TLS does. This check is not formally part of SSL (which
the quotation above makes clear). Without it, howerver, SSL would present no
protection against a MITM who had a vaild certificate.
> Trust management is entirely outside the scope of the protocol.
> This has nothing to do with MITM.
That's where your wrong. In the Internet trust model (anyone can get a
certificate signed by a trusted authority, all the certificate does it prove
they are who they say they are, not that they're someone I can trust), this
*is* the protection against a MITM.
If I try to connect to 'www.amazon.com', a MITM can do one of two things:
1) He can present the cert for 'www.amazon.com', but in that case, since he
doesn't have the private key, he can neither decrypt nor modify the data.
2) He can present his own cert for 'www.evil-mitms.com', but in that case,
I'll just dump the connection by this exact check.
So it's this check the stops MITM in the Internet's security model. It is
different in the NSA's security model, where you might be willing to trust
anyone who had an NSA-signed certificate regardless of contents, or where
you can trust the certificate to tell you what privileges to give.
That's why this isn't part of SSL (as you and Netscape correctly note).
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
