¿HTTPS o HTTPS dentro de VPN para seguridad WIFI?

Con respecto a los comentarios de su 'jacking de sesión' sobre la respuesta de Terry Chia:

El jacking de sesión y la técnica que utiliza Firesheep es apuntar a los inicios de sesión del sitio HTTP que tienen lugar a través de una conexión de red compartida, es decir: WiFi. Esto se logra al interceptar las cookies de sesión que el sitio envía después de que se inicie sesión correctamente. Si la conexión utiliza SSL [también conocido como HTTPS], estas cookies no pueden ser leídas por un tercero.

Cuando su navegador indica "no todo en esta página es seguro", significa que se cargó algún recurso a través de una conexión HTTP simple. Esto no significa necesariamente que eres vulnerable, ya que generalmente es simplemente un archivo de imagen o un archivo CSS / JS incluido.

En cuanto a las VPN, solo debe confiar en la conexión VPN tanto como confía en el proveedor. Es decir, si está utilizando un servicio gratuito como HotSpotShield, será mejor que esté de acuerdo con que puedan interceptar cada paquete que les envíe. Además, dado que instala su software de cliente VPN, no hay nada que les impida instalar también certificados falsificados de SSL de raíz / intermedios en su computadora que les permitirán desprenderse de la protección SSL si así lo desean.

En resumen, es mejor que no utilice una VPN que no haya configurado usted mismo, y asegúrese de que sus inicios de sesión y datos importantes se transmitan a través de conexiones protegidas SSL / TLS, por ejemplo: HTTPS, IMAPS, POPS, etc. .

No entiendes las tecnologías que has mencionado.

Primero, identifiquemos las amenazas de navegar en una red wifi pública. Cualquiera que esté en la misma red que usted podrá detectar los paquetes que envíe. Esto significa que cualquier información no cifrada que envíe a través de redes wifi públicas puede verse comprometida fácilmente.

Este problema es mitigado por HTTPS. Lo que hace HTTPS es encapsular la comunicación HTTP dentro de una capa SSL. Lo que esto significa es que cualquier dato enviado entre su navegador y el sitio web está encriptado. HTTPS también garantiza que el sitio web es quien dice que son a través de certificados.

Hotspot Shield crea un túnel VPN entre su computadora y su puerta de enlace de Internet. Cualquier tráfico entre su computadora y la puerta de enlace será encriptado. Sin embargo, cualquier tráfico de datos entre la puerta de enlace y otros sitios web aún puede ser detectado, a menos que se estén comunicando a través de HTTPS.

Para su caso de uso, yo diría que una simple conexión HTTPS será suficiente.

El La pregunta a la que te vinculas (en un comentario) no habla realmente sobre las debilidades en HTTPS. La distribución de correo electrónico no tiene nada que ver con HTTPS.

Es importante comprender las debilidades relacionadas con HTTPS y SSL / TLS antes de pasar a soluciones alternativas, algunas de las cuales pueden presentar problemas similares.

• El problema de la renegociación (CVE-2009-3555) estaba relacionado directamente con el protocolo TLS. Hubo mitigaciones utilizando las opciones de configuración (deshabilitando la renegociación), y desde entonces ha habido una solución (RFC 5746). (A pesar de que es una falla, creo que fue bastante difícil de explotar de manera consistente).

• El problema CRIME puede solucionarse desactivando la compresión TLS.

• El problema de BEAST se puede mitigar de varias maneras, en particular, actualizando a TLS 1.1 o superior.

La mayoría de estos problemas requieren algunos cambios de configuración o cambios de opciones en la forma en que ciertas aplicaciones usan sus bibliotecas SSL / TLS. Sin embargo, si está actualizado con su software, debería estar bien.

La especificación completa de SSL / TLS es muy modular, por lo que si se encuentran ciertas debilidades con ciertos conjuntos de cifrado, por ejemplo, a menudo hay otras opciones disponibles. La configuración correcta y actualizada es esencial para cualquier sistema de seguridad.

La mayoría de las personas que dicen que "SSL está roto" de hecho se dirigen al sistema PKI (es decir, el modelo de certificado). La especificación TLS en realidad no exige el uso de certificados X.509, pero es cierto que el HTTPS sobre TLS implica el uso de certificados X.509.

Las PKI y los certificados tratan de verificar la identidad de la parte remota. Esta es una solución técnica a un problema que ocurre en la vida cotidiana (el banco verifica su identificación en el escritorio, ...). El aspecto técnico es solo una parte del problema. Los AC están lejos de ser perfectos, pero ofrecen un sistema que es manejable. Modelar la confianza es en realidad un problema muy difícil.

Recuerde que, en última instancia, comprobar que el HTTPS se usa y se usa con la parte correcta es responsabilidad del cliente y su usuario . Los servidores pueden, en el mejor de los casos, decirles a los clientes que utilicen HTTPS, ya que la redirección podría no ser segura. Siempre depende del usuario comprobar. (Es cierto que también es un problema de la GUI, para dar al usuario la información correcta, con la menor confusión posible).

La comparación de HTTPS (y SSL / TLS) a las VPN no tiene sentido. Estos sistemas tienen dos propósitos diferentes. HTTPS trata de asegurar la comunicación entre el cliente / navegador y el servidor. Las VPN tratan de unir dos subredes.

Hay una serie de tecnologías VPN, con sus ventajas y desventajas. Al igual que todas las soluciones de seguridad, deben configurarse y usarse correctamente para que sean efectivas.

• VPN que usan SSL / TLS (como OpenVPN): en principio, pueden sufrir algunos de los mismos problemas que SSL / TLS con HTTPS cuando se trata de verificar los certificados. Dicho esto, la autenticación de certificado de cliente es más común en este entorno (lo que hace que los ataques MITM también sean detectables por el servidor con SSL / TLS, esto también se aplica a HTTPS, pero los certificados de cliente son más raros allí).

• VPN que usan IPsec y certificados. Una vez más, la verificación de identidad también puede ser un problema allí. Una forma de abordar esto es reducir la cantidad de certificados de CA en los que confía la implementación de IPsec. En general, esto es más manejable para una VPN porque estás usando menos VPN que los sitios web remotos en general, pero el problema fundamental sigue siendo.

• VPN usando IPsec y secreto compartido. Esto podría funcionar bien si el secreto compartido no se compartiera tan ampliamente (y se mantuviera más secreto). Parece que algunas universidades (por ejemplo) publican su secreto compartido de VPN ampliamente, lo que potencialmente puede abrir la puerta a los ataques MITM .

Si verifica su certificado correctamente, agregar una VPN en su conexión HTTPS generalmente no agrega ninguna seguridad real. Hay una pequeña ventana en la que puede ayudar: cuando una CA en la que confía (voluntariamente o por defecto en su sistema operativo / navegador) se ha visto comprometida y se puede usar un certificado deshonesto en la sección de red que de otra manera podría protegerse con una VPN. Esto también puede ayudar en esa sección de la red con clientes mal implementados .