A silly question to Server Identy Check (RFC 2595)

[Alexander Ausserstorfer]

Using TLS with IMAP, POP3 and ACAP:

http://www.ietf.org/rfc/rfc2595.txt

From page 2:

| 2.4. Server Identity Check
|
| During the TLS negotiation, the client MUST check its understanding
| of the server hostname against the server's identity as presented in
| the server Certificate message, in order to prevent man-in-the-middle
| attacks. Matching is performed according to these rules:
|
| - The client MUST use the server hostname it used to open the
| connection as the value to compare against the server name as
| expressed in the server certificate. The client MUST NOT use any
| form of the server hostname derived from an insecure remote source
| (e.g., insecure DNS lookup). CNAME canonicalization is not done.

Why does this work? Cannot someone send a wrong Certificate but with the
right hostname?

A.

[Barry Margolin]

In article <056d2a3...@bavariasound.chiemgau-net.de>,

Not if the Certificate Authority is doing their job. They shouldn't
approve and sign a certificate that has a hostname that doesn't belong
to the holder of the certificate. I can't call Verisign and ask them to
sign a certificate that has the hostname login.google.com, only an
authorized Google representative should be able to do this.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Peter Schoo]

Am 04.04.13 19:15, schrieb Barry Margolin:

>> Why does this work? Cannot someone send a wrong Certificate but with the
>> > right hostname?

> Not if the Certificate Authority is doing their job. They shouldn't
> approve and sign a certificate that has a hostname that doesn't belong
> to the holder of the certificate.

you're right, Berry, but we have to face the facts:
http://doi.ieeecomputersociety.org/10.1109/MIC.2013.5

BR
Peter