Autenticación SSL con certificados: ¿deberían los certificados tener un nombre de host?

Question

Versión rápida de la pregunta

Gmail, TD (banco canadiense), Royal Bank (banco canadiense) todos usan ssl. Al inspeccionar sus certificados todos ellos tienen

Common Name (CN) mail.google.com 

o más en general:

Common Name (CN) <url> 

Es esto necesario para evitar que el hombre en los ataques medias?

Resumen

JBoss permite a los clientes y servidores para la autenticación mediante certificados y SSL. Una cosa que parece extraña es que no está obligado a dar su nombre de host en el certificado.

Creo que esto significa que si el Servidor B está en su almacén de confianza, Sever B puede pretender ser el servidor que ellos quieran.

(Y del mismo modo: si el cliente B se encuentra en el almacén de confianza ...)

Me estoy perdiendo algo aquí?

autenticación Pasos

(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's 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 sabe

• El cliente tiene la clave pública del certificado enviado (paso 7)

• del cliente certificado es válido porque cualquiera de los:

  • que haya sido firmado por una CA (Verisign)
  • ha sido autofirmado pero es en almacén de confianza del servidor

• No es un ataque de repetición debido, presumiblemente, el número aleatorio (etapa 1 o 2) se envía con cada mensaje

cliente sabe

• el servidor tiene la clave pública del certificado enviado (paso 6 con el paso 8)

• El certificado del servidor es válido ya sea porque:

  • que haya sido firmado por una CA (VeriSign)
  • se ha auto-firmado, pero está en almacén de confianza del cliente

• no es un ataque de repetición porque presu Mably el número aleatorio (etapa 1 o 2) se envía con cada mensaje

Problema potencial

• Supongamos almacén de confianza del cliente tiene certs en ella:

  • servidor A
  • Servidor B (malicous)

• servidor A tiene el nombre de host www.A.com

• servidor B tiene el nombre de host www.B.com

• supongamos lo siguiente: El cliente intenta conectarse al servidor A, pero el servidor B lanza un hombre en el medio ataque.

• Desde el servidor B:

  • tiene una clave pública para el certificado que se envía al cliente
  • tiene un "certificado válido" (un certificado en el almacén de confianza)
• Y desde:
  • certificados no tienen un nombre de host feild en ellos

Parece que el servidor B puede pretender ser el servidor A fácilmente.

¿Hay algo que me falta?

Answer 1

¿Puedes indicar un texto que dice que JBoss no necesita un nombre de host en el certificado o simplemente es tu observación? Supongo que por 'nombre de host' te refieres al nombre común (CN) o al nombre distinguido (DN) ??

Normalmente una aplicación debe comprobar un cert X.509 para:

fecha Válido gama
uso (por ejemplo; auth servidor)
Cadenas a una raíz de confianza
CN == nombre DNS del objetivo host (que podría ser otro nombre, no sólo DNS)
no revocados (CRL o el uso de un OCSP)

Técnicamente, una aplicación puede optar por ignorar cualquiera de ellos y simplemente indican t todo está bien con el certificado ... pero eso es malo :)

Answer 2

Creo que te estás perdiendo algo, pero no estoy seguro si entiendo tu razonamiento.

Sin embargo, cuando el servidor B intenta lanzar un hombre en el ataque medio, dices que tiene una clave pública. Esto es cierto, pero para configurar una conexión SSL, también debe tener una clave privada que pertenezca a esa clave pública. Además, el certificado utilizado está acoplado al nombre dns (en el caso de https). Entonces, un cliente intenta conectarse a A, escribe en www.a.com. Como suponemos que B no conoce la clave privada de A, tendrá otra pareja de teclas. Nunca podría recibir un certificado válido (es decir, de confianza) de una CA importante que esté acoplado a un dominio que no le pertenece.

Así que B nunca pudo obtener un certificado con el nombre común www.A.com, por esta razón, B no pudo realizar un hombre en el ataque medio.