SSL authentication with certificates: should certificates have a host name?

Question

Quick version of the question

Gmail, TD (Canadian Bank), Royal Bank (Canadian Bank) use ssl. When you check their certificates, everyone has

Common Name (CN) mail.google.com 

Or more generally:

 Common Name (CN) <url> 

Is it necessary to prevent people in medium attacks?

Summary

JBoss allows clients and servers to authenticate using certificates and ssl. One thing that seems strange is that you do not need to include your hostname in the certificate.

I think this means that if server B is in your power of attorney, Sever B can claim any server that they want.

(And similarly: if customer B is in your trusted store ...)

Am I missing something?

Authentication steps

( Summary of Wikipeida page )

 Client Server ================================================================================================= 1) Client sends Client Hello ENCRIPTION: None - highest TLS protocol supported - random number - list of cipher suites - compression methods 2) Sever Hello ENCRIPTION: None - highest TLS protocol supported - random number - choosen cipher suite - choosen compression method 3) Certificate Message ENCRIPTION: None - 4) ServerHelloDone ENCRIPTION: None 5) Certificate Message ENCRIPTION: None 6) ClientKeyExchange Message ENCRIPTION: server public key => only server can read => if sever can read this he must own the certificate - may contain a PreMasterSecerate, public key or nothing (depends on cipher) 7) CertificateVerify Message ENCRIPTION: clients private key - purpose is to prove to the server that client owns the cert 8) BOTH CLIENT AND SERVER: - use random numbers and PreMasterSecret to compute a common secerate 9) Finished message - contains a has and MAC over previous handshakes (to ensure that those unincripted messages did not get broken) 10) Finished message - samething 

Sever knows

• The client has a public key for the certificate sent (step 7)

• The client certificate is valid because either:

  • It was signed by CA (verisign)
  • it was self-signed, but it is on the server trust network

• This is not a replay attack because a supposedly random number (step 1 or 2) is sent with each message

Customer knowledge

• The server has a public key for the certificate sent (step 6 from step 8)

• The server certificate is valid because either:

  • It was signed by CA (verisign)
  • he was self-signed, but he is in a client power of attorney

• This is not a replay attack because a supposedly random number (step 1 or 2) is sent with each message

Potential problem

• Suppose a customer trust store has certificates:

  • Server A
  • Server B (malicous)

• Server A has a host name of www.A.com

• Server B has the host name www.B.com

• Suppose a client tries to connect to server A, but server B starts a person in an average attack.

• Since server B:

  • has a public key for the certificate that will be sent to the client
  • has a "valid certificate" (certificate in trust)
• And since:
  • certificates do not have a host name in them

It seems that server B can easily pretend to server A.

Is there something I am missing?

Answer 1

Can you point to some text that says that JBoss does not need a hostname in the certificate, or is it just your observation? I assume that "hostname" means Common Name (CN) or Distinguished Name (DN) ??

Typically, an application should verify an X.509 certificate for:

Valid Date Range
Usage (e.g. server auth)
Trust Root Chains
CN == DNS name of the target host (it may be a different name, not just DNS)
Not canceled (using CRL or OCSP)

Technically, the application can ignore any of them and simply indicate that everything is fine with the certificate .... but this is bad :)

Answer 2

I think something is missing for you, but I'm not sure if I understand your reasoning.

However, when server B tries to start a person in an average attack, you say that he has a public key. This is true, but to establish an ssl connection, you must also have a private key that belongs to this public key. In addition, the certificate used is associated with the name dns (in the case of https). Thus, the client tries to connect to A, he types on www.a.com. Since we assume that B does not know the private key of A, he will have another key pair. He was never able to obtain a valid (i.e. trusted) certificate from a large CA associated with a domain that he does not own.

So B was never able to get a certificate with the common name www.A.com, for this reason B was not able to execute the person in an average attack.