¿Se pueden hacer proxy de las solicitudes SSL emitiendo un segundo certificado?

Esto es exactamente por lo que me enojé tanto en Bank of America cuando enviaron un enlace a myfraudprevention.com cuando pensaron que mi cuenta estaba comprometida. SSL solo funciona para verificar que un tercero de confianza haya validado que el sitio web que se está visitando pertenece al nombre de la URL que se está visitando. Si enviaba a alguien a su propio sitio web y ese sitio tenía un certificado, aún podría hacer que el sitio se pareciera a lo que quisiera, incluido un sitio de suplantación de identidad (phishing) que simula ser otra organización.

Lo único que le importaría a SSL es que usted es realmente el propietario de charliesbank.com. Bank of America estaba literalmente capacitando a sus usuarios para que fueran víctimas de phishing en un correo electrónico diseñado para ayudar a detener el fraude ...

La capacitación del usuario es la única forma de evitar esto actualmente. Si realmente verifica los detalles del certificado que se presenta, debe informarle más detalles sobre la organización a la que se expidió el certificado. Si el certificado SSL tiene Extended Validation y es la organización con la que desea hablar, eso significa que alguna autoridad de certificación los ha examinado y ha determinado que son la organización que dicen ser, pero actualmente el usuario debe entenderlo. Cómo funciona este proceso y hacer la verificación ellos mismos. También le corresponde al usuario verificar la URL a la que están conectados.

Probablemente no hay mucho que se pueda hacer para mejorar esto, ya que no hay forma de que la computadora sepa que el usuario realmente quería bobsbank.com pero visitó charliesbank.com. El icono podría reemplazarse con algo que muestre más detalles sobre el certificado, pero en general, esto causa más confusión para la mayoría de los usuarios que no entienden cómo funciona SSL.

El ataque se evita mediante el uso de certificados , es decir, los nombres . El navegador de Alice rechazará el certificado de Charlie, porque el navegador desea hablar con www.thebank.com y, por lo tanto, espera ver el nombre exacto www.thebank.com en el certificado del servidor presunto. El certificado de Charlie contiene www.evilcharlie.com , el nombre de su propio sitio web.

Para ejecutar su ataque, Charlie tendría que sobornar a una CA (una de las que el navegador de Alice confía por defecto) para que le expida un certificado que contenga www.thebank.com . Por supuesto, CA bueno no aceptará eso (cuando lo hacen, hace que las noticias ; tales contratiempos ocurren aproximadamente una vez al año en todo el mundo, lo cual no es tan frecuente).

  

¿Funciona este ataque

Sí, de hecho, hay soluciones comerciales para hacer exactamente eso. Aparentemente no con fines maliciosos.

  

y ¿hay alguna forma de prevenirlo?

Sí, no use una conexión a Internet que tenga tal proxy en su lugar. En general, estas instalaciones se encuentran en redes corporativas, redes de campus u otros lugares donde el operador de red desea examinar todo el tráfico, incluido el tráfico SSL.

Por lo general, estas instalaciones requieren que instale un certificado de autoridad de raíz SSL "falso" en su navegador, que se utiliza para firmar los certificados generados para realizar el ataque de hombre en el medio. Entonces ... no hagas eso. Aunque si el atacante ya tiene un certificado de CA instalado en su computadora, no sería necesario.

  

¿Funciona el ataque?

Sí el ataque funcionaría. Y a diferencia de algunas otras respuestas aquí, no se necesita ninguna modificación especial en el almacén local de certificados de CA del dispositivo que quiero atacar.

  

¿Hay alguna manera de prevenirlo?

La única manera en la que puedo pensar en abordar este problema es usar certificados de cliente / autenticación mutua TLS , o una "aplicación" que se conecta solo al sitio de confianza.

..el ataque

Un "Proxy de phishing y sustitución de certificado" funcionaría de la siguiente forma:

Supongamos que quería atacar a un banco llamado www.contoso.com y compro el nombre DNS www.contos0.com . Luego compro un certificado de control de dominio validado que simplemente verifica que poseo el control del dominio. No se necesita un certificado EV, aunque supongo que se podría adquirir uno.

Luego, el atacante obtiene un software TCP que esencialmente hace un eco de los datos y los reenvía al siguiente servidor. El proceso sucede a la inversa también y se realiza una sesión dúplex.

El ataque de phishing que se ve así:

Browser  <---->  contos0.com:443 (decrypt and rencrypt) <----> contoso.com

..la mitigación

Para sitios web / escritorios normales

Dado que su servidor web puede usar cualquier CA para generar certificados de cliente, puede:

1. Inscriba a los usuarios el certificado utilizando el elemento HTML5 KeyGen
2. O inscriba a los usuarios simplemente ofreciendo el certificado completo (clave pública y privada en un PFX combinado) para descargar.

He probado la interfaz de usuario para varios navegadores y considero que Keygen es más fácil de administrar para el usuario final, aunque necesita mejoras.

Para aplicaciones móviles

Los navegadores móviles casi nunca muestran la barra del navegador, por lo tanto, la mayoría de los usuarios no sabrán si están en un sitio de phishing, un sitio HTTPS o un sitio con un certificado EV.

• Cuando un usuario accede a su sitio web, puede redirigirlos a su aplicación de iOS, Android, Blackberry o Windows . Esto reforzará el buen comportamiento del usuario final y solo hará que inicie sesión con una aplicación "confiable".

• Certificados de cliente en un navegador web o una aplicación web

Los certificados SSL básicos y la conciencia humana básica deberían ser suficientes para proteger esto nuevamente. Pero las empresas modernas han degradado el proceso de emisión de un certificado SSL, y la nueva tecnología está confundiendo a la gente.

En el pasado, la obtención de un certificado SSL implicaba la verificación de la Autoridad de Certificación y una tarifa considerable. La comercialización del proceso ha reducido la calidad de la verificación y la introducción de certificados SSL de "solo validación de dominio" para los cuales se realiza una verificación mínima. Y así, los certificados SSL se han vuelto tan populares que la gente comenzó a considerarlos como un hecho básico, no como algo que debería verificarse . Los navegadores tampoco ayudaron al identificar claramente certificados de alta calidad.

Por lo tanto, Certificados de Validación Extendida (EV) se introdujeron para proporcionar la confianza de que el propietario del sitio web tiene un negocio confiable y tiene una identidad verificable. Un costoso y tedioso proceso de investigación desalienta a los malhechores a comprar certificados EV. Estos certificados vienen con cierta seguridad visual mejorada, esa larga barra verde con el nombre de la empresa.

Pero los certificados EV no resuelven el problema de confusión. Según un estudio de usabilidad de la pantalla del EV en Internet Explorer 7 de la Universidad de Stanford y Microsoft Research del EV en Internet Explorer 7:

  

Los participantes que recibieron sin capacitación en funciones de seguridad del navegador sí lo hicieron   No noté el indicador de validación extendida y no superó   el grupo de control.

mientras que

  

Se pidió a los participantes que leyeran el archivo de ayuda de Internet Explorer.   era más probable que clasificaran sitios reales y falsos como legítimos .