¿Es seguro visitar los sitios web de HTTPS en un punto de acceso público?

HTTPS es seguro a través de puntos de acceso públicos. Solo se transmiten una clave pública y los mensajes cifrados (y estos también están firmados por certificados raíz) durante la configuración de TLS , el capa de seguridad utilizada por HTTPS. El cliente utiliza la clave pública para cifrar un secreto maestro, que luego el servidor descifra con su clave privada. Todos los datos están encriptados con una función que utiliza el secreto maestro y los números pseudoaleatorios generados por cada lado.

Por lo tanto,

• los datos están seguros porque están firmados por el secreto principal y los números pseudoaleatorios
• el secreto maestro y los números pseudoaleatorios son seguros porque utiliza el cifrado de clave pública-privada cuando se produce el protocolo de enlace TLS
• el cifrado de clave pública-privada es seguro porque:
  • las claves privadas se mantienen secretas
  • el cifrado de clave pública-privada está diseñado para ser inútil sin la clave privada
  • Se sabe que las claves públicas son legítimas porque están firmadas por certificados raíz, que, a su vez,
  • vino con tu computadora
  • o fueron autorizados específicamente por usted (¡preste atención a las advertencias del navegador!)

Por lo tanto, sus conexiones y datos HTTPS están seguros siempre y cuando:

1. confía en los certificados que vienen con su computadora,
2. usted se encarga de autorizar únicamente los certificados en los que confía.

Respuesta corta: depende.

SSL / TLS en sí mismo no es más vulnerable a través de una conexión wifi pública, que a través de internet "normal". Fue diseñado para ser utilizado en canales abiertos.

Sin embargo, hay algunos otros aspectos a considerar:

• A menudo, los usuarios no navegan directamente al sitio HTTPS, comienzan en el sitio HTTP y se redirigen desde allí. Por ejemplo, navega a http://example.org/ y hace clic en el enlace Email , que lo redirige a https://mail.example.org/ . Dado que la página HTTP original no está encriptada, ese usuario malintencionado puede modificar su tráfico, lo que hace que el enlace Email NO se redirija a HTTPS, sino a otro lugar. Por ejemplo, si hiciste clic en el enlace Email en la página principal de example.org, ¿te darías cuenta de que te llevó a http://mail.exxxample.org/ ? (como ejemplo). Usted podría, alguien más podría no hacerlo.
• Si el usuario secuestra su conexión, pero proporciona su propio certificado SSL falso en lugar del de example.org, su navegador mostrará un error, de que el certificado no es válido. Sin embargo, la mayoría de los usuarios solo harán clic para permitir que el atacante acceda a MITM en su sitio seguro, a través de SSL.
• Otro aspecto a considerar, no asuma que el punto de acceso público está configurado de manera segura. Como muestra esta pregunta , los enrutadores con pwned son demasiado comunes y pueden causar mucho más daño irrelevante para su SSL.

Una sesión que está completamente sobre HTTPS es bastante segura, ya que todas las solicitudes del navegador y las páginas transmitidas por el servidor están cifradas.

Sin embargo, cuando se accede a través de HTTPS, muchos sitios solo realizarán el paso de autenticación a través de HTTPS y luego volverán a HTTP durante el resto de la sesión. Por lo tanto, su contraseña en sí misma es segura, pero el identificador de sesión utilizado por el servidor para identificarlo para esa sesión se transmite de forma clara por su navegador. Esto reduce la carga en el servidor web (debido a que el cifrado / descifrado es un uso intensivo de la CPU) pero hace que el sitio sea mucho menos seguro. Gmail es seguro porque usa HTTPS para toda la sesión, pero Facebook y muchos otros sitios no.

Así es como herramientas como Firesheep pueden secuestrar las cuentas de los usuarios cuando un atacante está compartiendo una red inalámbrica no cifrada. .

Puede protegerse de este ataque usando una VPN para encriptar todos los datos de la sesión, o usando solo redes que tengan encriptación fuerte por usuario, como WPA-PSK (WEP usa la misma clave para cada usuario, y así que no ofrece protección contra este ataque).

Ya que las respuestas parecen estar por todas partes (sí, no, podría ser, debería ser), permítanme reiterar primero la respuesta de @ waiwai933: es segura.

Para ser específico, usted preguntó: "Si ese usuario malintencionado olfateó todos mis paquetes entrantes y salientes. ¿Puede calcular las mismas claves y leer mi tráfico cifrado también o incluso enviar mensajes cifrados al servidor en mi nombre?" La respuesta es no y no. Con una nota al pie.

La razón por la que no puede calcular las mismas claves parece paradójica, y de hecho fue un gran avance en la criptografía cuando fue publicada por primera vez por Diffie y Hellman. TLS usa un protocolo de intercambio de claves, como Diffie-Hellman, pero más sofisticado para protegerlo de los ataques del hombre en el medio. El protocolo permite a dos personas que nunca han intercambiado información antes de calcular una clave secreta que nadie puede ver en todos los mensajes.

Una vez que tenga una clave secreta compartida, puede usarla para cifrar su tráfico. Como el usuario malintencionado no conoce la clave, no puede cifrar el tráfico que parece provenir de usted.

Ahora esas notas al pie.

• Estamos asumiendo que el protocolo SSL / TLS es correcto. Con la mayoría de los protocolos criptográficos involucrados, los errores se encuentran y se corrigen de vez en cuando. SSL / TLS tuvo un error reciente (mencionado en algunas respuestas como una razón por la que no es seguro), sin embargo, se ha solucionado temporalmente y ahora fix (RFC 5746) y la solución se encuentra en varias etapas de implementación. (En su escenario, el error permitía a un usuario malintencionado enviar paquetes en su nombre pero no leer su tráfico). Siempre es posible que el atacante sepa cómo romper TLS / SSL debido a un error no publicado en el protocolo.
• Un punto obvio pero que vale la pena repetir: el usuario malintencionado puede ver su solicitud y enviar su propia respuesta utilizando su propio certificado. Así que revisa el certificado.
• Quizás otro punto obvio: solo puede estar seguro de que SSL / TLS se usará para páginas futuras si la página actual es HTTPS. Por ejemplo, si está en una página HTTP que quiere que inicie sesión, y por experiencia anterior, sabe que hacer clic en el botón de inicio de sesión lo redirigirá a una conexión HTTPS, esta funcionalidad podría ser eliminada por un usuario malicioso activo. en su red. Solo inicie sesión en páginas que ya sean HTTPS (a menos que sepa cómo detectar si la página de inicio de sesión se ha modificado).

HTTPS es bastante resistente al descifrado de la detección de paquetes. Sin embargo, el lado de autenticación del servidor depende de un método un tanto débil para distribuir certificados de CA y las CA no hacen mucho en términos de verificación de identidades. Hace algunos años, un certificado de Microsoft se emitido a un impostor . Consulte el artículo de Bruce Schneier sobre el tema . En la práctica, para sitios web de público en general, no lo hacemos. tener algo mejor.

En la práctica, SSL y TLS tienen problemas, pero están relacionados con el tipo de ataque Man In the Middle. Para ver un ejemplo de problema de renegociación de TLS MITM, consulte aquí

Por supuesto, este ataque requiere que el atacante esté en medio de la ruta de comunicación, lo que limita un poco la amenaza :-)

Si le preocupa navegar de forma segura en algún sitio a través de una red insegura, los mejores pasos que puede tomar para garantizar la seguridad son:

• Asegúrese de que el sitio utiliza HTTPS, no HTTP.

• Asegúrese de que el sitio tenga un certificado válido. No hagas clic en las advertencias. No aceptes certificados inválidos.

• Use HTTPS Everywhere o Force-TLS para asegurarse de que está utilizando una conexión HTTPS (es decir, cifrada con SSL) para todo lo relacionado con ese sitio.

Enteramente, en la práctica. El cifrado comienza con la gente de SSL ssl (Verisign, Thawte, etc.) y, por lo tanto, es adecuado para líneas inseguras. AFAIK TLS no tiene un problema con los ataques de hombre en el medio, sus únicos apretones de manos más débiles / antiguos tienen ese problema.

La mayoría está olvidando el aspecto del usuario y cómo podrían usar esa PC en el punto de acceso también. La mayoría de las personas usan contraseñas similares en otros sitios, pueden bloguear, ... etc. Es posible que no sean tan seguros como el gmail HTTPS / SSL al que puede conectarse. Problema que veo por la seguridad, la mayoría de las personas irá a otros sitios para exponer un programa de rastreo de paquetes con información suficiente para acceder a algunas de sus cuentas. Lo mejor es como se mencionó si está utilizando una conexión inalámbrica sin cifrar, ojalá tenga un vpn al que pueda conectarse después de eso, lo que agregará una capa adicional de seguridad.

La conexión es bastante segura en lo que respecta a las conexiones seguras (ssl). Proporcionado, si se usa con conocimiento:

• No debe haber redirección de HTTPS a HTTP
• Algunos sitios también usan HTTP cmd sobre las páginas HTTPS, no debería haber ninguna información confidencial transmitida a través de eso
• Los servidores https con configuración débil y los navegadores desactualizados aún son explotables incluso a través de sockets seguros

La respuesta de ordenación es, por lo que sabemos, si HTTPS está configurado correctamente, está seguro el 99% del tiempo. Eso es un gran si. No es tan simple como simplemente ver HTTPS en tu navegador. SSL-Strip todavía funciona en algunos sitios / navegadores seguros.

No olvidemos que antes de SSL-Strip, nadie pensó que una herramienta así pudiera funcionar. La ciberseguridad es un campo en constante cambio y un juego de whak-a-mole, por así decirlo. En algún momento aparecerá un nuevo exploit que te permitirá realizar el ataque que mencionas en cualquier sitio. Mira el estándar WPA2 "irrompible". No tan irrompible después de todo. Será parcheado pero no hace mucho por las personas hackeadas antes de esa fecha.

Actualmente hay una forma de descifrar el tráfico SSL configurado correctamente. Requiere obtener acceso a una CA y emitir certificados de plena confianza. Tu navegador no detectará un ataque de MiTm usando eso. La buena noticia es que es extremadamente difícil de lograr ... por ahora. El uso de una VPN no garantiza la seguridad porque la propia VPN podría ser el atacante Mitm.

Básicamente, cualquier cosa en línea puede ser hackeada en algún momento. Hay cosas que puede hacer (VPN, navegador actualizado, etc.) para minimizar el riesgo, pero nunca está 100% seguro. No dejes que nadie te diga lo contrario.