2008-09-26 12 views
6

Repaso algún código de cliente que heredé para realizar una comunicación segura a través de HTTPS, y parece que no está comprobando el nombre común en el certificado del servidor (por ejemplo, ' CN = "example.com" 'contra la URL real que se solicita. Esto es probablemente deliberado, ya que se requiere que nuestra aplicación cliente hable con varios entornos, por lo tanto, después de contactar un portal inicial (por ejemplo, example.com/main) y el usuario que elige un entorno, la aplicación se redirecciona a una IP específica, por lo que todas las solicitudes futuras se parecen a "http://127.0.0.1/page".Implicaciones de seguridad de deshabilitar la comprobación de nombre común para HTTPS

Sin embargo, siendo un novato de SSL, no estoy seguro de las implicaciones de deshabilitar esta verificación. Mi primera reacción sea ​​que sería más fácil realizar algún tipo de man-in-the-middl Ataque, ya que alguien más podría simplemente copiar nuestro certificado y pretender ser uno de nuestros servidores. Pero si estuviéramos haciendo una comprobación de nombre común, podrías hacer lo mismo con la configuración de DNS personalizada de todos modos, así que no parece que nos gane nada. ¿Hay otros ataques que nos dejen abiertos a lo que no seríamos de otra manera?

Gracias

Respuesta

0

Para hacer lo mismo con la "configuración de DNS personalizados" el atacante debe explotar un servidor DNS (la suya o de un cliente) al punto example.com a una IP que controla, en lugar de sólo la copia de la certificado. Si es posible, crearía todas las aplicaciones específicas como subdominios de example.com y usaría un certificado comodín (* .example.com) para poder validar el CN.

9

Alguien más no puede simplemente copiar su certificado y usarlo porque no tienen su clave privada.

Si no verifica que el CN ​​del certificado no coincide con el nombre de dominio, entonces simplemente pueden crear su propio certificado (y que lo firme un CA de confianza para que parezca válido), utilícelo en lugar del suyo , y realizar un hombre en el ataque medio.

Además, debe comprobar que el certificado proviene de una CA de confianza. El trabajo de la CA consiste en asegurarse de que solo pueda obtener un certificado con el CN ​​= si realmente controla ese dominio.

Si omite cualquiera de estos controles, entonces corre el riesgo de sufrir un ataque MITM.

Consulte también this answer para obtener un enfoque diferente que funcionará si tiene suficiente control sobre el cliente.

+0

No es que puedan crear su propio certificado autofirmado, pero pueden usar cualquier certificado que obtengan de una CA confiable, independientemente del dominio. –

+0

Son ambas posibilidades: si no están revisando el CN, probablemente tampoco estén controlando al Emisor. – AviD

+0

Sí, había olvidado la parte de la clave privada. Gracias. – user22627

4

Si controla el código del cliente, puede restringir las CA fiables a las suyas. Entonces, la verificación de dominio es menos importante: cualquiera de sus servidores puede pretender ser otro.

Si no controla el código del cliente, un certificado firmado por una CA confiable puede sustituir al suyo.

+0

Sí, eso tiene sentido: ya tenemos un certificado raíz de toda la organización, así que puedo incorporarlo en el cliente y deshacerme de los certificados de CA estándar para que solo se acepten los firmados por nuestra raíz. Gracias. – user22627

0

La verificación del nombre de host (verificando la parte del CN) garantiza que el otro extremo de la conexión (servidor) tenga un certificado SSL con el nombre de dominio que escribió en la barra de direcciones. Normalmente, un atacante no podrá obtener dicho certificado.

Si no verifica la parte de nombre de host, alguien (alguien sentado en cualquiera de los enrutadores o servidores proxy a través del cual pasa la solicitud) podría hacer un hombre en el ataque medio. O alguien podría explotar algunos ataques de DNS.

3

$ 0.02: el uso de CN para los nombres de host está obsoleto, en su lugar se deben usar los nombres alternativos del sujeto X.509.

+0

¿Alguna posibilidad de una referencia? :) –

+1

@ThomasBratt: http://tools.ietf.org/html/rfc2818#section-3.1 – Bruno

2
  • Verificar el certificado en sí mismo y que se puede encadenar a un certificado de CA en el que ya confía le permite comprobar que el certificado es auténtico y válido.
  • Verificar el nombre de host en el certificado le permite comprobar que está hablando con el servidor con el que deseaba hablar, siempre que haya verificado que el certificado es válido. (. Comprobación de que la parte remota está precisamente la celebración de la clave privada de ese certificado se realiza dentro del SSL/TLS apretón de manos)

Si quieres una analogía con el pasaporte/ID comprobación de la gente:

  • Verificar el certificado es como verificar que un pasaporte o una forma de identificación sea genuino. Puede decidir qué formas de ID quiere aceptar de una persona (por ejemplo, pasaporte, permiso de conducir, tarjeta de personal, ...) y qué países emisores de su confianza pueden verificar su autenticidad.
  • Verificar que la ubicación remota es la que tiene la clave privada es similar a verificar que la imagen en el pasaporte/ID coincide con la cara de la persona que tiene delante.
  • Verificar el nombre de host es como comprobar que el pasaporte pertenece a la persona cuyo nombre es el que está buscando.

Si no verifica el nombre de host, cualquier persona con un pasaporte válido que considere genuino podría acudir a usted y reclamar que es el que está buscando (por nombre).

En circunstancias muy limitadas, donde solo confía en una CA específica o un certificado autofirmado en el que permite que cualquier certificado potencial suplante a cualquier otro en el conjunto completo de certificados en los que confía, puede ser aceptable ignorar esta verificación , pero esto es muy raro y no es una buena práctica.

Verificar que el nombre en el pasaporte coincida con el nombre de la persona que está buscando se considerará de sentido común; hazlo también por certificados. Si no lo hace, cualquier persona que tenga un certificado en el que confíe como genuino se haga pasar por otro certificado en el que pueda confiar y, por lo tanto, posiblemente realice ataques MITM.

Las reglas de verificación del nombre de host HTTPS están definidas en RFC 2818 Section 3.1 (también más recientemente en una especificación de "mejores prácticas", RFC 6125, no mucho implementado todavía).

En resumen, el nombre de host debe estar en una entrada DNS de nombre alternativo del sujeto (aunque puede recurrir al CN del DN del sujeto donde no hay SAN en el certificado). Cuando usa una dirección IP, la dirección IP debe estar en una entrada de dirección IP de SAN (aunque algunos navegadores le permitirán salirse con la dirección IP en el CN ​​del DN del asunto).

Cuestiones relacionadas