it-swarm-es.com

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

A menudo se dice que las conexiones HTTPS SSL/TLS están encriptadas y se dice que son seguras porque la comunicación entre el servidor y yo está encriptada (también proporciona autenticación del servidor), por lo que si alguien olfatea mis paquetes, necesitarán miles de millones de años para descifrar si usan un bruto fuerza en teoría.

Supongamos que estoy en un wifi público y hay un usuario malintencionado en el mismo wifi que detecta cada paquete. Ahora supongamos que estoy intentando acceder a mi cuenta de gmail usando este wifi. Mi navegador realiza un protocolo de enlace SSL/TLS con el servidor y obtiene las claves para usar para el cifrado y descifrado.

Si ese usuario malicioso 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 a mi nombre?

148
Calmarius

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

Así,

  • los datos son seguros porque están firmados por el secreto maestro y los números pseudoaleatorios
  • el secreto maestro y los números pseudoaleatorios son seguros porque utiliza 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 en secreto
    • 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
    • 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 que:

  1. confía en los certificados que vienen con su computadora,
  2. solo tiene que autorizar los certificados en los que confía.
109
waiwai933

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 "regular". 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 redirigen desde allí. Por ejemplo, navegas hasta http://example.org/, y haga 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, haciendo que el enlace Email NO redirija a HTTPS, pero tal vez a otro lugar. Por ejemplo, si hace clic en el enlace Email en la página de inicio de example.org, ¿notará que lo llevó a http://mail.exxxample.org/? (como ejemplo). Usted podría, alguien más podría no.
  • Si el usuario secuestra su conexión, pero proporciona su propio certificado SSL falso en lugar de los de example.org: su navegador ¡lo hará muestra un error de que el certificado no es válido. Sin embargo, la mayoría de los usuarios simplemente harán clic en esto, permitiendo al atacante MITM a su sitio seguro, a través de SSL.
  • Otro aspecto a considerar, no asuma que el punto de acceso público está configurado de forma segura. Como esta pregunta muestra , los enrutadores pwned son demasiado comunes y pueden causar mucho más daño irrelevante de su SSL.
48
AviD

Una sesión que se realiza por completo a través de HTTPS es bastante segura, ya que todas las solicitudes del navegador y las páginas transmitidas por el servidor están encriptadas.

Sin embargo, cuando se accede a través de HTTPS, muchos sitios solo llevarán a cabo 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í es segura, pero su navegador transmite la ID de sesión utilizada por el servidor para identificarlo para esa sesión. Esto reduce la carga en el servidor web (porque el cifrado/descifrado requiere mucha 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 encriptada.

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

22
Alex Howell

Dado 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íficos, usted preguntó: "Si ese usuario malicioso 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 Diffie y Hellman lo publicaron por primera vez. TLS utiliza un protocolo de intercambio de claves, como Diffie-Hellman, pero más sofisticado para proteger de los ataques del hombre en el medio. El protocolo permite a dos personas que nunca antes han intercambiado información calcular una clave secreta que nadie que vea todos los mensajes puede calcular.

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

Ahora esas notas al pie.

  • Asumimos que el protocolo SSL/TLS es correcto. Con la mayoría de los protocolos criptográficos involucrados, los errores se encuentran y corrigen de vez en cuando. SSL/TLS tenía 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 solucionado (RFC 5746) y la solución está en varias etapas de despliegue (En su caso, el error permitió que un usuario malintencionado enviara paquetes a su nombre pero no leyera 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 podría ver su solicitud y enviar su propia respuesta utilizando su propio certificado. Entonces verifique 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 previa sabe que al hacer clic en el botón de inicio de sesión lo redirigirá a una conexión HTTPS, un usuario malintencionado activo podría despojar esta funcionalidad. en tu red Por lo tanto, solo inicie sesión en páginas que ya sean HTTPS (a menos que sepa cómo detectar si se ha modificado la página de inicio de sesión).
13
PulpSpy

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

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

  • Asegúrese de que el sitio tenga un certificado válido. No haga clic en las advertencias. No acepte 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.

2
D.W.

HTTPS es bastante resistente al descifrado del rastreo de paquetes. Sin embargo, el lado de autenticación del servidor depende de un método algo débil de distribución de 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 era emitido a un impostor . Ver Bruce Schneier's artículo sobre el tema - en la práctica, para sitios web públicos en general, no tenemos nada mejor.

2
RedGrittyBrick

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 el medio de la ruta de comunicación, lo que limita un poco la amenaza :-)

2
Rory Alsop

Completamente, en la práctica. El cifrado comienza con las personas SSL raíz (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, solo sus apretones de manos más débiles/mayores tienen ese problema.

1
tobylane

La mayoría se está olvidando del aspecto del usuario y también de cómo podrían usar esa PC en el punto de acceso. La mayoría de las personas usan contraseñas similares en otros sitios, pueden blog, ... etc. Es posible que estos no sean tan seguros como HTTPS/SSL gmail al que podría estar conectando. Problema que veo por seguridad, la mayoría de las personas irán a otros sitios y expondrán 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 no encriptada, ojalá tenga un VPN al que pueda conectarse después de eso, lo que agregará una capa adicional de seguridad.

1
IrqJD

La conexión es bastante segura en lo que respecta a las conexiones seguras (ssl). Siempre que se use con conciencia:

  • No debe haber redireccionamiento de HTTPS a HTTP
  • Algunos sitios usan cmd HTTP sobre páginas HTTPS también, no debería haber ninguna información confidencial transmitida sobre eso
  • Los servidores https configurados débiles y los navegadores obsoletos siguen siendo explotables incluso a través de sockets seguros
0
8zero2.ops