¿Se puede hackear SSL en una red wifi pública?

La longitud de las claves SSL varía entre 40 y 56 bits, que pueden encontrarse con algunos conocimientos técnicos y utilizarse para falsificar un certificado activo.

Los rastreadores de paquetes en una red pública pueden recuperar la longitud de la clave utilizada, pero no la clave en sí. Se necesitarían conocimientos técnicos para falsificar o reemplazar un certificado activo.

Wikipedia informa al menos 7 vectores de ataque (conocimientos técnicos) para SSL:

SSL 2.0 tiene fallas en una variedad de formas:

[199]

  • Se utilizan claves criptográficas idénticas para la autenticación y el cifrado de mensajes. (En SSL 3.0, los secretos MAC pueden ser más grandes que las claves de cifrado, por lo que los mensajes pueden permanecer a prueba de manipulaciones incluso si las claves de cifrado están rotas. [4])
  • SSL 2.0 tiene una construcción MAC débil que utiliza la función hash MD5 con un prefijo secreto, lo que lo hace vulnerable a ataques de extensión de longitud.
  • SSL 2.0 no tiene ninguna protección para el apretón de manos, lo que significa que un ataque de degradación de hombre en el medio puede pasar desapercibido.
  • SSL 2.0 utiliza la conexión TCP cercana para indicar el final de los datos. Esto significa que los ataques de truncamiento son posibles: el atacante simplemente falsifica un FIN de TCP, dejando al destinatario sin darse cuenta de un mensaje de fin de datos ilegítimo (SSL 3.0 soluciona este problema al tener una alerta de cierre explícita).
  • SSL 2.0 asume un servicio único y un certificado de dominio fijo, que choca con la característica estándar de alojamiento virtual en servidores web. Esto significa que la mayoría de los sitios web están prácticamente impedidos de usar SSL.

SSL 2.0 está deshabilitado de forma predeterminada, comenzando con Internet Explorer 7,

[200]

Mozilla Firefox 2,

[201]

Opera 9.5,

[202]

y Safari. Después de enviar un “ClientHello” TLS, si Mozilla Firefox descubre que el servidor no puede completar el protocolo de enlace, intentará volver a usar SSL 3.0 con un SSL 3.0 “ClientHello” en formato SSL 2.0 para maximizar la probabilidad de éxito Apretón de manos con servidores más antiguos.

[203]

La compatibilidad con SSL 2.0 (y cifrados débiles de 40 y 56 bits) se ha eliminado por completo de Opera a partir de la versión 10.

[204]

[205]

SSL 3.0 [ editar ]

SSL 3.0 mejoró a SSL 2.0 al agregar cifrados basados ​​en SHA-1 y soporte para autenticación de certificado.

Desde el punto de vista de la seguridad, SSL 3.0 debe considerarse menos deseable que TLS 1.0. Las suites de cifrado SSL 3.0 tienen un proceso de derivación de clave más débil; La mitad de la clave maestra establecida depende completamente de la función hash MD5, que no es resistente a colisiones y, por lo tanto, no se considera segura. Bajo TLS 1.0, la clave maestra que se establece depende de MD5 y SHA-1, por lo que su proceso de derivación no se considera actualmente débil. Es por esta razón que las implementaciones de SSL 3.0 no se pueden validar bajo FIPS 140-2.

[206]

En octubre de 2014, se informó la vulnerabilidad en el diseño de SSL 3.0, lo que hace que el modo de operación CBC con SSL 3.0 sea vulnerable al ataque de relleno (ver #POODLE attack).

Un investigador ha encontrado una forma convincente de piratear el protocolo SSL (Secure Sockets Layer) utilizado para proteger los inicios de sesión en una variedad de sitios web, incluidos el comercio electrónico y los sitios bancarios.

Usando una aplicación especialmente creada, ‘SSLstrip’, un investigador que se hace llamar Moxie Marlinspike demostró a Black Hat Arlington, asistentes de Va en la conferencia del pasado fin de semana, cuán vulnerables eran muchas conexiones SSL a un hombre en el medio involucrado pero inteligente (MitM) ataque donde un pirata informático podría enviar el tráfico de los usuarios que acceden a https: // inicios de sesión seguros.

Para demostrar la utilidad del ataque a un hipotético criminal, afirmó que el pirateo le había dado acceso a 117 cuentas de correo electrónico, 16 números de tarjeta de crédito, 7 inicios de sesión de PayPal y más de 300 otros “inicios de sesión seguros misceláneos” en un 24- período de hora Los sitios involucrados incluyeron Ticketmaster, Paypal, LinkedIn, Hotmail y Gmail.

Lo inteligente es que el ataque no necesitaba tocar el tráfico SSL cifrado en absoluto, simplemente explotar el hecho de que los usuarios casi nunca llaman a https directamente, sino que acceden a eso llamando primero a una página web http convencional. Ese hecho hace posible monitorear y mapear el tráfico entre el navegador y el sitio web antes de que el SSL se configure de forma segura, colocándose entre los dos para que ninguno de los sitios sepa que algo anda mal.

Según Marlinspike, el truco también puede superar la posibilidad de que el navegador genere advertencias de certificado no válidas desde el sitio proxy falso, incluso transmitiendo datos convincentes si los favicons falsos como el candado tradicional https. La única señal de que algo está mal sería la falta de la dirección https: // en la barra de herramientas, algo que pocos usuarios probablemente notarían, dijo.

“Muchas veces la seguridad de HTTPS se reduce a la seguridad de HTTP, y HTTP no es seguro”, dice Marlinspike en su resumen de presentación. “Si queremos evitar los diálogos de la muerte, comencemos con HTTP, no con HTTPS”.

Es importante destacar que los indicadores visuales que ayudan a los usuarios comunes a detectar tales ataques deben enfatizarse una vez más, anulando algunos años en los que los desarrolladores, incluidos los desarrolladores de navegadores, han minimizado dicho refuerzo.

“Una vez que tenemos el control de eso, podemos hacer todo tipo de cosas para reintroducir los indicadores positivos que la gente podría perderse”, dice.

Hace unas semanas se informó de un hack indirecto en la infraestructura web segura, mediante el cual se utilizó una falla en el algoritmo de cifrado MD5 para engañar a las autoridades de certificación para que aceptaran un certificado falso como algo real.

Esta historia, “Investigador muestra cómo hackear SSL” fue publicada originalmente

No. Todas las conexiones a los sitios https son privadas y los paquetes están encriptados. Ningún hombre en el medio puede ver el contenido real del paquete. Vea a continuación, esta es la captura de pantalla real de man-in-the-middle usando Wireshark:

(La captura de pantalla anterior la tomo solo con fines ilustrativos)

Puede ver que todos los paquetes están encriptados y nadie, excepto usted y el servidor, puede ver los datos privados.

Si alguien dice que man-in-the-middle puede ver sus datos cuando el sitio web usa TSL, ¡entonces él / ella es un experto en seguridad falso o un hacker charlatán!

Siga adelante y use los sitios web de TSL sin muchas preocupaciones. Pero tenga cuidado de navegar por los sitios web que no tienen conexión privada (TSL / SSL). No hay ningún daño en navegar por sitios que no son de TSL que no desean su información personal, o inicio de sesión o contraseñas.

Gracias.

EDITAR: K. Scott Helms tiene otro ángulo. Si el DNS de su / IPS se vio afectado, entonces es posible hacer un ataque de man-in-the-middle. Aún así, su navegador puede advertirle sobre la validez del certificado, como él lo ha señalado fácilmente.

Es mucho más fácil para alguien que quiere obtener acceso a sus datos cifrados engañándolo que atacando directamente el cifrado TLS / SSL. La forma más común de hacerlo es un ataque Man-in-the-middle que te hace creer que te estás conectando al sitio seguro al que deseas acceder pero que está enviando todo tu tráfico a través de un proxy u otro sistema primero. Esto puede permitir que el sistema MTM presente una copia del tráfico de su banco (por ejemplo) mientras graba toda la información que envía y recibe sin tener que descifrar su sesión TLS. Los detalles técnicos varían según el tipo de ataque exacto, pero en general no haría cosas como la banca en línea en un punto de acceso público.

Una gran señal de advertencia es si su navegador indica un error de certificado, generalmente un dominio no coincidente o un certificado autofirmado, que indica que el MTM está inyectando su propio certificado en su navegador en lugar del certificado de su banco (o lo que sea).

Como otros han indicado, los ataques MitM son posibles, pero quizás no muy probables. Sin embargo, puede esquivar fácilmente el riesgo utilizando una VPN. También es probable que se comunique con servidores sin SSL, tal vez a través de banners publicitarios o iframes, por lo que sería mejor prevenir que curar.

Seguir las reglas de seguridad de sentido común lo protegerá contra la mayoría de las amenazas en línea. Aquí están mis 6 trucos de seguridad súper simples favoritos: https://safecontrols.blog/2017/0