verificación SSL del nombre de host del servidor https

3

Recientemente encontré que una biblioteca que estoy usando (específicamente Apache HTTPClient) cuando está configurada para verificar el nombre de host del servidor remoto con el CN del certificado, parece que está haciendo una comparación de cadenas.
Es decir. si el certificado se ha emitido a una dirección IP y el usuario escribe un nombre en su lugar, por ejemplo, https://secureserver/
pero el IP < - > secureserver (mapas, por ejemplo, configurados en el archivo del host de Windows), falla la verificación quejándose de que

javax.net.ssl.SSLException: hostname in certificate didn't match: 
    <secureserver> != <10.4.5.1>  

¿Es esta la forma en que normalmente se implementa en todas las bibliotecas? Es decir. Me equivoco al esperar que una búsqueda inversa de secureserver a 10.4.5.1 . que es el CN del certificado que debió haber ocurrido?

Gracias

    
pregunta Jim 17.08.2011 - 21:13
fuente

3 respuestas

3

enlace Criptografía de clave pública / privada . Por lo tanto, el cliente utiliza la clave pública del servidor para cifrar la información que solo el servidor puede descifrar.

En este nivel simple, el atacante puede engañar al cliente para que le hable en lugar del servidor real, utilizando la clave pública del atacante. El atacante luego desencripta la información enviada usando su clave privada y la reenvía al servidor real. Esto se denomina Man in the middle attack .

Para evitar este tipo de ataque, SSL utiliza el certificado. Un certificado es básicamente una clave pública con información de identidad adjunta. Esos certificados pueden ser firmados por las autoridades de certificación para confirmar la información de identidad.

El cliente debe verificar que el nombre en el certificado coincida con el servidor con el que quiere hablar. En el caso de un navegador web normal, este es el nombre de dominio que se muestra en la barra de direcciones. Sin esta verificación, el atacante podría simplemente enviar cualquier certificado.

El DNS no es seguro, por lo que en muchas situaciones se puede manipular fácilmente. Si el navegador relajara la verificación para aceptar una dirección IP que pertenece al nombre de dominio en cuestión, confiaría en el DNS inseguro .

Aparte de eso, el uso de direcciones IP en certificados SSL no es válido. Por lo tanto, incluso si escribe la dirección IP en la barra de direcciones, el navegador debe rechazar el certificado. Pero un certificado puede contener una lista de nombres de dominio para los cuales es válido.

    
respondido por el Hendrik Brummermann 17.08.2011 - 22:15
fuente
3

Sí, creo que se equivocó al esperar que el proceso de validación del nombre del certificado haría cualquier resolución de nombre, resolución inversa u otra asignación para usted. La coincidencia que se lleva a cabo es prácticamente una cosa literal que se realiza en la capa de la aplicación (lo siento, mala etiqueta. Me refiero al código de la biblioteca SSL llamado por la aplicación cuando digo "capa de la aplicación"; en OSI, probablemente sea la capa de Sesión o Presentación , pero es todo parte de la aplicación ejecutable).

No creo que encuentre un controlador de biblioteca java para agregar la asignación de nombres que está buscando, porque el protocolo SSL / TLS realmente trata de hacer coincidir los nombres literales (y luego asegurarse de que el certificado y la criptografía aspectos de autoridad están en su lugar).

Creo que puedes usar la etiqueta subjectAltName para generar un certificado que coincidirá de manera válida con varios nombres, pero es un enfoque opuesto al que estás viendo.

    
respondido por el gowenfawr 17.08.2011 - 21:56
fuente
2

El punto de SSL es que el mundo exterior es hostil (al menos potencialmente). No puede esperar que el DNS devuelva respuestas verdaderas e inalteradas, porque cualquier atacante que pueda afectar su conexión (y usted cree que existen tales personas, porque esa es la razón por la que usa SSL) también podría alterar las respuestas del DNS. Todo el ejercicio consiste en confiar en un conjunto específico de "anclajes de confianza" (también conocido como "CA raíz") y en construir a partir de eso, y solo a partir de eso.

Por lo tanto, el cliente SSL requerirá que el nombre del servidor deseado esté presente en el certificado del servidor, no en nada indirecto como una dirección IP en la que dicho nombre fue mapeado a través de un mecanismo potencialmente inseguro como DNS.

Nota: conceptualmente, se puede usar cualquier tipo de "identidad", siempre que lo que el cliente espera sea igual a lo que se encuentra en el certificado . En HTTPS , se supone que "lo que espera el cliente" se describe adecuadamente en la URL , más precisamente la nombre del servidor de la URL. Los navegadores web muestran ese nombre de manera proeminente (estoy usando Chromium en este momento; muestra la URL en la barra de URL como texto gris, con el nombre del servidor resaltado en un tono más oscuro). Uno podría imaginar una convención en la que el cliente "conoce" la dirección IP de destino (codificada o conocida de una fuente confiable, no de una solicitud de DNS), y espera que esa dirección IP aparezca en el certificado; Los certificados X.509 pueden contener direcciones IP (consulte el tipo de nombre iPAddress en Subject Alt Name extensión). Sin embargo, las implementaciones existentes no coinciden con las direcciones IP, coinciden con los nombres. Así que fue escrito , y tiene sentido, porque se pueden verificar nombres por personas, y las direcciones IP pueden cambiar bastante al migrar o expandir infraestructuras.

    
respondido por el Thomas Pornin 09.08.2013 - 19:26
fuente

Lea otras preguntas en las etiquetas