it-swarm-es.com

¿Una conexión HTTPS establecida significa que una línea es realmente segura?

Desde el punto de vista de alguien que ofrece una aplicación web, cuando alguien se conecta con TLS (https) a nuestro servicio y envía los datos de autenticación correctos, ¿es seguro transmitir todos los datos confidenciales a través de esta línea, o puede ser que todavía haya escuchas?

Esta pregunta fue Pregunta de seguridad de TI de la semana.
Lea el 29 de julio de 2011 entrada del blog para más detalles o envíe el suyo Pregunta de la semana.

112
Peter Smit

Es importante comprender qué hace y qué no hace SSL, especialmente porque es una fuente muy común de malentendidos.

  • Encripta el canal
  • Aplica comprobación de integridad
  • Proporciona autenticación

Entonces, la respuesta rápida debería ser: "sí, es lo suficientemente seguro como para transmitir datos confidenciales". Sin embargo, las cosas no son tan simples.

  • Las versiones más nuevas de SSL - versión 3, o mejor aún: TLS, incluso TLS 1.2, son definitivamente mejores que las versiones anteriores. P.ej. SSL 2 fue relativamente fácil para MITM (Hombre en el medio). Entonces, primero depende de la versión del protocolo.
  • Tanto el cifrado de canales como la verificación de integridad son configurables en el protocolo, es decir, puede elegir qué algoritmos usar (conjunto de cifrado). Obviamente, si está utilizando RSA1024/SHA512, está mucho mejor ... Sin embargo, SSL incluso admite un modo de cifrado NULL, es decir, sin cifrado, simplemente envolviendo las solicitudes hasta el túnel a través del protocolo SSL. Es decir, sin protección. (Esto es configurable tanto en el cliente como en el servidor, el conjunto de cifrado seleccionado es el primer conjunto coincidente según el orden configurado).
  • La autenticación en SSL tiene dos modos: solo autenticación de servidor y autenticación mutua (certificados de cliente). En ambos casos, la seguridad garantizada por los certificados criptográficos es definitivamente lo suficientemente fuerte, sin embargo, la validez de la autenticación real es tan buena como sus comprobaciones de validez: ¿Se molesta incluso en verificar el certificado? ¿Aseguran su validez? Cadena de confianza? ¿Quién lo emitió? Etc.
  • Este último punto de autenticación es mucho más fácil en la web aplicaciones, en donde el cliente puede ver fácilmente el certificado del servidor, el ícono del candado es fácilmente visible, etc. Con Web Servicios, Por lo general, debe ser más explícito al verificar su validez (dependiendo de la plataforma que elija). Tenga en cuenta que este mismo punto ha disparado tantas aplicaciones móviles, incluso si el desarrollador de la aplicación recordó usar solo TLS entre el teléfono y el servidor, si la aplicación no verifica explícitamente los certificados, entonces el TLS está roto.
  • Si bien hay algunos ataques principalmente teóricos sobre la criptografía de SSL, desde mi punto de vista todavía es lo suficientemente fuerte para casi todos los propósitos, y lo será durante mucho tiempo.
  • ¿Qué se hace realmente con los datos en el otro extremo? P.ej. si se trata de datos súper sensibles, o incluso de tarjetas de crédito, no desea que estén en la memoria caché del navegador, ni en el historial, etc.
  • Las cookies (y, por lo tanto, la autenticación) se pueden compartir entre un canal SSL seguro y un canal HTTP no seguro, a menos que se marque explícitamente con el atributo "seguro".

Entonces, ¿respuesta más corta? Sí, SSL can es lo suficientemente seguro, pero (como con la mayoría de las cosas) depende de cómo lo use. :)

94
AviD

Aquí hay algunos problemas, el principal es la autenticación. Ambos extremos deben asegurarse de que están hablando con la persona o institución correcta para frustrar los ataques de intermediarios. Por su parte, es crucial que utilice un certificado SSL en el que confíe el navegador del usuario. Al hacerlo, el navegador del usuario puede estar seguro de que realmente está hablando con el sitio correcto. Una vez que se establece la conexión, puede estar seguro de hablar con ese usuario todo el tiempo y la conexión está encriptada, es decir, segura contra escuchas.

La autenticación en la otra dirección (es decir, asegurarse de hablar con el usuario real) generalmente se maneja fuera del protocolo SSL en el nivel de la aplicación, por ejemplo, nombre de usuario/contraseña, openID u otra forma de credenciales.

Como última nota, debe mencionarse que durante la conexión SSL, el cliente y el servidor de protocolo de enlace acuerdan un conjunto de cifrado y el cliente podría pretender hacer solo "cifrado nulo", es decir, no cifrar ninguno de los datos . Si su servidor acepta esa opción, la conexión usa SSL, pero los datos aún no están encriptados. Esto no es un problema en la práctica ya que las implementaciones de servidor generalmente no ofrecen el cifrado nulo como una opción.

23
Tronic

Además de lo que AviD enumera, SSL es tan seguro como la infraestructura DNS que lo dirigió a ese servidor y cualquier proxy corporativo en la ruta de comunicación.

Si se piratea la infraestructura DNS (envenenamiento de caché, etc.), el atacante podría someter a su usuario a muchos ataques.

Además, si el cliente está pasando por un software como Fiddler , o un proxy corporativo, ese software puede facilitar su conversación SSL.

Para mitigar esto, mire el "emisor" del certificado SSL. Si la conexión SSL pasa por un proxy, entonces el emisor será el del proxy. Si está pasando por una conexión directa, verá la CA relevante de confianza pública.

[Más información]

Un proxy HTTPS corporativo es algo que gestiona la conexión entre el navegador web y el Proxy (cuya dirección IP aparece en los registros de su servidor web). En ese caso, el contenido web (contraseña HTTPS también) se descifra y luego se vuelve a cifrar en el proxy corporativo y se presenta a su servidor.

Dependiendo de quién administra el proxy y cómo se usan sus registros, esto puede ser aceptable o algo malo desde su perspectiva.

Para obtener más información sobre cómo se realiza la intercepción SSL, consulte esto enlace :

Cuando el proxy SSL intercepta una conexión SSL, presenta un certificado de servidor emulado al navegador del cliente. El navegador del cliente emite una ventana emergente de seguridad para el usuario final porque el navegador no confía en el emisor utilizado por el ProxySG. Esta ventana emergente no se produce si el certificado de emisor utilizado por el proxy SSL se importa como una raíz confiable en el almacén de certificados del navegador del cliente.

ProxySG hace que todos los certificados configurados estén disponibles para su descarga a través de su consola de administración. Puede solicitar a los usuarios finales que descarguen el certificado del emisor a través de Internet Explorer o Firefox y lo instalen como una CA de confianza en el navegador de su elección. Esto elimina la ventana emergente de certificado para certificados emulados ...

Algunas empresas resuelven el problema emergente del certificado mencionado anteriormente mediante la implementación de los certificados raíz (del Proxy) en cada estación de trabajo a través de GPO. Aunque esto solo afectará el software que utiliza el almacén de certificados de Microsoft. Software como Firefox y Chrome necesita actualizarse de manera diferente.

20

Como SSL se basa en las Autoridades de certificación (CA), y básicamente cualquier organización puede convertirse en una CA, los ataques de intermediarios con certificados falsos pero firmados por CA siempre son posibles. Por lo tanto, si bien SSL sigue siendo una gran mejora sobre la no codificación, su seguridad está sobrevalorada debido al sistema CA dañado. En ese sentido, los certificados autofirmados serían tan seguros como cualquier certificado firmado por CA, sin embargo, los navegadores los consideran sospechosos.

11
Jörn Zaefferer

SSL es muy seguro, aunque alguien puede robar la cookie de sesión de alguien si ejecuta CUALQUIER página a través de una línea sin cifrar. Si pudiera, haría que el sitio fuera totalmente SSL. O posiblemente haga que la cookie solo envíe conexiones cifradas y tenga páginas públicas no seguras no específicas para ese usuario.

10
James T

Todavía existe la posibilidad de un ataque man-in-the-middle, que en su caso sería el usuario que se conecta a un tercero que dice ser su sitio y luego reenvía la solicitud. Por supuesto, un usuario inteligente debería notar la falta de una conexión SSL o un certificado incorrecto, pero la mayoría de los usuarios no están tan encendidos y son engañados por un favicon de candado.

Esto no es realmente un problema con SSL en sí mismo, solo algo a tener en cuenta. Puede asumir con seguridad que nadie puede espiar la conexión SSL entre su sitio y la fuente de la conexión. Sin embargo, no puede asegurarse de que la fuente de la conexión sea realmente el usuario.

9
Magnus

Dado que SSL encripta la transmisión, no se pueden espiar datos (ya que el certificado es de confianza).

Aunque el problema reside en dónde (y cuánto) está utilizando SSL en su aplicación web: digamos, por ejemplo, que necesita una conexión SSL solo para autenticar a su usuario (para permitir que envíen sus pares de usuarios cifrados/pases a su servidor) , cuando devuelva una cookie, debe tener en cuenta que podría ser fácilmente interceptada (como si su usuario estuviera en una conexión inalámbrica desprotegida).

El reciente drama de FireSheep tiene que ver con esto.

9
gbr

No. Análisis de tráfico todavía puede decirle mucho a alguien.

El análisis del tráfico es el proceso de interceptar y examinar mensajes para deducir información de patrones en la comunicación. Se puede realizar incluso cuando los mensajes están encriptados y no pueden desencriptarse. En general, cuanto mayor sea el número de mensajes observados, o incluso interceptados y almacenados, más se puede inferir del tráfico.


TLS generalmente se implementa para preservar la confidencialidad: un atacante no debe alcanzar un alto nivel de confianza sobre el contenido de la comunicación.

Asumiendo,

  1. un atacante conoce tu protocolo,
  2. un atacante sabe quién se comunica con quién
  3. el atacante no puede descifrar mensajes.
  4. no ocultas tu tráfico real en mucho tráfico sin sentido (chaff)

Un atacante probablemente puede saber cuándo está despierto y cuándo está dormido, independientemente del protocolo, y puede decir mucho más dependiendo de la naturaleza del protocolo que esté utilizando.


Si su protocolo es muy simple:

  1. Envía un mensaje "dispara las armas nucleares a ..." cuando quieres disparar armas nucleares
  2. No envía un mensaje cuando no quiere disparar armas nucleares.

Un intruso que no puede descifrar sus datos puede determinar por la mera presencia de un mensaje que desea disparar armas nucleares, aunque quizás no a quién.


Si su protocolo es más complejo:

  1. Pides un libro.
  2. Te mando el contenido.

Es posible que un atacante no pueda saber quién está leyendo "Guerra y paz" frente a "Atlas encogido de hombros" pero puede distinguir, basándose únicamente en el tamaño del mensaje, si está leyendo uno de los anteriores frente a los 55 de Kafka. página novela "La metamorfosis".

7
Mike Samuel

SSL realiza dos tareas básicas: autenticación y encriptación.

La autenticación se realiza por medio de autoridades de certificación (CA). Los navegadores vienen con una lista de certificados SSL para las claves de firma de las CA. Las CA firman certificados que describen la clave pública de una entidad. Por ejemplo, si fuera propietario de Google.com, se lo demostraría a Verisign y ellos firmarían mi certificado por un período de tiempo. Los problemas surgen con una CA que firma un certificado que no deben firmar. Esto puede ocurrir cuando alguien pretende poseer otro dominio, adquiere un certificado comodín que es demasiado amplio, o simplemente XKCDs la CA para emitir algo nefasto (¿gobiernos, tal vez?). Hemos visto casos de todo lo anterior, pero es bastante raro.

Si un certificado para un sitio está debidamente firmado y no existe un certificado falso en su cadena de confianza, entonces cuando se conecta a un sitio puede (para fines de discusión) estar seguro de que el certificado coincide. En circunstancias normales, esa conexión está encriptada. Eso evita que alguien lea sus datos.

Los certificados SSL son muy complejos y existen varios ataques contra implementaciones SSL. Lo que SSL puede hacer efectivamente es evitar que vea su tráfico en el Starbucks local cuando revisa su correo electrónico en GMail. Lo que no puede hacer es evitar que use un ataque MITM en el que le transmito todo sin SSL y su cliente no está configurado para molestarlo por el hecho de que nunca comenzó una sesión cifrada.

6
Jeff Ferland

Sin contar las diversas respuestas de otros sobre otros posibles problemas, suponiendo que esté utilizando SSL 3.0 y un cifrado seguro, debe ser seguro.

El uso de protocolos ssl más antiguos (2.0) o el uso de una clave de cifrado débil puede abrir vulnerabilidades.

4
Doozer Blake

SSL generalmente aumenta la seguridad al proporcionar:

  1. Autenticación del servidor (el usuario sabe que está hablando con el sitio "correcto")
  2. Integridad de los datos (el usuario y el servidor saben que el tráfico no se modifica en la ruta)
  3. (opcional, pero generalmente) Privacidad de datos (el usuario y el servidor saben que el tráfico no se intercepta en el camino)
  4. (opcionalmente, pero raro) Autenticación del cliente, si el cliente también tiene un certificado

Básicamente, solo hay dos tipos de certificado SSL, el certificado del servidor (que siempre está involucrado) y un certificado de cliente (que es opcional).

Esto es solo un boceto, y hay muchos ifs, ands y buts. En el escenario más típico, SSL basado en navegador, el esquema puede romperse en muchos casos sin romper la criptografía o el protocolo, sino simplemente confiando en que el usuario haga lo incorrecto (es decir, ignore las advertencias del navegador y se conecte de todos modos). Los ataques de phishing también pueden funcionar enviando al usuario a un sitio falso protegido por SSL, creado para parecerse al real en todos los aspectos, excepto la URL.

Dicho esto, SSL y su primo TLS siguen siendo muy útiles, ya que al menos permiten una comunicación segura, aunque lejos de ser infalible.

4
frankodwyer

@Vladimir tiene razón en que http://en.wikipedia.org/wiki/Forward_secrecy es deseable, pero tiene los detalles incorrectos. El servidor eligió este conjunto de cifrado entre los ofrecidos por el navegador. "cifrado con RC4_128 con SHA1 para la autenticación de mensajes" utiliza el cifrado RC4 de 128 bits y la verificación de integridad HMAC-SHA-1. (Los nombres de Ciphersuite en SSL/TLS hasta hace poco dicen SHA pero significan SHA-1 y en realidad HMAC-SHA-1.) "ECDHE_ECDSA como mecanismo de intercambio de claves" no se aplica a mensajes individuales , es parte (la mayoría) del apretón de manos que ocurre una vez al comienzo de la sesión: ECDHE usa la variante de curva elíptica de Diffie-Hellman en modo efímero (más algunos pasos adicionales que no son importantes aquí) para crear la sesión claves utilizadas para cifrado y HMAC; y el intercambio de claves ECDHE (solo) está firmado por la variante de curva elíptica del algoritmo de firma digital. (Nunca se puede cifrar nada directamente con DH o ECDH, solo hacen clave u otro pequeño acuerdo secreto).

2
dave_thompson_085

Cuando no está utilizando SSL, toda la comunicación se puede interceptar fácilmente; lo único que hay que hacer es iniciar el sniffer de paquetes (es decir, Wireshark).
SSL evita eso, todos los paquetes están encriptados, por lo que no hay forma de saber qué está enviando. Básicamente se utiliza para proteger contraseñas y contenido privado de la intercepción. Obviamente no quieres que otra persona lea tus correos electrónicos privados, ¿verdad?
En cuanto a la búsqueda en Google, simplemente lo hicieron para ocultar lo que la gente está pidiendo. Esto se debe a que algunos gobiernos son demasiado curiosos al respecto.

¿Cómo SSL aumenta la seguridad? No lo hace por sí mismo. Lo que hace es una combinación de cifrado (clave SSL) y PKI (Infraestructura de clave pública), principalmente certificados. OK, la pregunta era cómo. Por un lado, asegura su canal de comunicación (ver arriba), por otro lado, asegura que está hablando con un negocio legítimo: autentica el servidor. Entonces el canal es seguro y confiable.

Hay bastantes certificados SSL, ya que hay bastantes Servicios PKI . Básicamente, un servicio diferente necesita un tipo diferente de Certificado SSL. Por lo tanto, hay certificados para la firma de código, el cifrado y la firma de correo electrónico, los relacionados con la autenticación del servidor, etc.

2
Paweł Dyda

Cuando alguien se conecta con SSL (https) a nuestro servicio y envía los datos de autenticación correctos, ¿es seguro transmitir todos los datos confidenciales a través de esta línea, o puede ser que todavía haya escuchas?

El eslabón débil en esta cadena casi seguramente no es SSL, sino el usuario, que generalmente puede ser engañado para conectarse a un sitio intermedio falso ya sea mediante suplantación de identidad/suplantación de hipervínculos, o al presentar un certificado no válido y descartar la advertencia del navegador y proceder a conectar de todos modos.

Sin embargo, el sistema que describe es la mejor práctica de todos modos, no hay mucho más que pueda hacer (aparte de educar a sus usuarios para que tomen en serio las advertencias SSL si puede).

2
frankodwyer

La respuesta corta es no. Respuesta más larga: una colección de las respuestas anteriores más: si resolvemos la autenticación, por lo tanto, en el medio, que con la conexión SSL tradicional, una lista de alguien para el tráfico aún podría descifrarla más tarde si obtuvieran una clave secreta del servidor (piense de NSA y National Security Letters). Existe una opción en el protocolo TLS para usar el protocolo Diffie-Helman para asegurar el enlace de forma confidencial. Vea la siguiente imagen cuando accedo a gmail.com usando Chrome. connection security

Mire el texto RC4_128 con SHA1 para la autenticación del mensaje ECDHE_ECDSA. Esto lee:

  1. El servidor ofreció el canal SSL RC4_128b con SHA resumen
  2. Dentro de este túnel, cada mensaje está encriptado con curvas Ecliptic donde la clave se deriva usando la función Diffie-Helman, y se firma con el cifrado de Curvas Ecliptic usando Algoritmo de Firma Digital

En otras palabras, incluso si alguien tiene una clave privada del servidor SSL, los mensajes se cifraron con claves temporales que se descartan de la memoria poco después de su uso. Buena suerte NSA!

2
Vladimir Jirasek

¿Es seguro para el usuario o es seguro para usted? Asume un ataque de hombre en el medio. El atacante logra capturar el tráfico del usuario, se hace pasar por el usuario y se hace pasar por el usuario. Ese tipo de ataque generalmente fallaría, porque el certificado otorgado al usuario no sería correcto. Por ejemplo, el atacante le da al usuario un certificado autofirmado para su sitio web. Sin embargo, si el usuario actúa estúpidamente, puede aceptar ese certificado autofirmado. Entonces, el atacante puede leer y modificar todo el tráfico entre el usuario y usted, y que yo sepa, no hay forma de que detecte esto.

Entonces, si el espionaje y la modificación del tráfico perjudican al usuario, es realmente su propia culpa y su propio problema. Y de todos modos no puede evitarlo por completo, porque el MITM puede cortarlo por completo y simplemente hablar con el usuario que finge ser usted. Pero si el espionaje y la modificación del tráfico lo lastiman, entonces debe confiar en que el usuario no será estúpido, o también autenticarlo mejor (el usuario necesitaría un certificado, y puede verificarlo de una manera que el MITM no pueda falso).

2
gnasher729

Incluso las versiones más modernas de HTTPS que usan TLS pueden ser interceptadas fácilmente por un MitM (por ejemplo, un dispositivo Juniper configurado para este fin) si el cliente confía en la CA. En ese caso particular, no es seguro.

1
user3260912

Creo que la gente aquí no entiende la pregunta:

Si tiene una línea insegura y realiza una conexión SSH/SSL exitosa a través de esta línea, ahora le preguntará si es seguro asumir que la línea es "segura" y que los datos no cifrados se pueden pasar A LO LARGO de la conexión cifrada ( por ejemplo, a simple vista, no dentro de la conexión SSL/SSH cifrada).

Yo diría que no. En este caso, podría haber un espía pasivo que simplemente ignora los datos cifrados y guarda los datos no cifrados.

PERO puede estar seguro de que no hay espionaje activo (MITM), lo que significa que puede establecer de forma segura una conexión SSL/SSH no autenticada con el mismo origen/destino que la línea autenticada. Esto proporcionó que no haya escuchas selectivas que MITM ciertos conectores, PERO, sin embargo, el escucha no puede saber si va a autenticar la conexión o no, por lo que no puede saber qué conexión a MITM para evadir la detección. El MITMer haría, si MITM, MITM todas las Conexiones y espera que la gente haga clic en todos los cuadros de diálogo de autenticación simplemente.

Por lo tanto: si se conecta autenticado a un servicio SSL desde, digamos 123.123.123.123 a 24.24.24.24, también puede conectar de forma segura un cliente SSH desde 123.123.123.123 a 24.24.24.24 sin autenticar mutuamente la huella digital SSH, siempre que pueda confiar en todo el otro lado NAT enrutador o firewall.

Pero incluso si eso es seguro en general, existe IS un pequeño riesgo de que un espía simplemente conecte MITM al azar y espere no ser detectado, por lo tanto, dado que ya tiene una conexión autenticada a la IP de destino, ¿por qué? no use esa conexión autenticada para verificar mutuamente la huella digital SSH ¡Es simple como publicar la huella digital SSH correcta en un sitio web seguro SSL!

1
sebastian nielsen