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

112

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 haya ¿Sigues escuchando a escondidas?

  

Esta pregunta fue Cuestión de la semana sobre seguridad de TI .
  Lea el 29 de julio de 2011 entrada de blog para obtener más detalles o envíe su propia pregunta de la semana.

    
pregunta Peter Smit 11.11.2010 - 22:41
fuente

18 respuestas

94

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

  • Encripta el canal
  • Aplica la verificación de integridad
  • Proporciona autenticación

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

  • Las versiones más recientes 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 de MITM (Man in the middle). Entonces, primero depende de la versión del protocolo.
  • Tanto el cifrado del canal como la comprobación de integridad se pueden configurar 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, no hay 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 la verificación de validez: ¿Se molesta siquiera en verificar el certificado? ¿Aseguras su validez? ¿Cadena de confianza? ¿Quién lo emitió? Etc.
  • Este último punto de autenticación es mucho más fácil en las aplicaciones web , en las que el cliente puede ver fácilmente el certificado del servidor, el icono del candado se puede ver fácilmente, etc. Con los servicios web , por lo general, debe ser más explícito al verificar su validez (según 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 en su mayoría teóricos a la criptografía de SSL, desde mi punto de vista es bastante 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 es super sensible, o incluso datos de tarjeta de crédito, no querrá eso en el caché, historial, etc. de los navegadores.
  • Las cookies (y, por lo tanto, la autenticación) se pueden compartir entre un canal seguro, SSL y un canal HTTP no seguro, a menos que se marque explícitamente con el atributo "seguro".

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

    
respondido por el AviD 11.11.2010 - 22:59
fuente
22

Hay algunos problemas aquí, el principal es la autenticación. Ambos extremos deben estar seguros de que están hablando con la persona o institución adecuada para frustrar los ataques del hombre en el medio. 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 establecida la conexión, puede estar seguro de estar hablando con ese usuario todo el tiempo y la conexión está cifrada, es decir, segura contra escuchas ilegales.

La autenticación en la otra dirección (es decir, asegurarse de que está hablando 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 o alguna otra forma de credenciales.

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

    
respondido por el Tronic 11.11.2010 - 22:54
fuente
19

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 la infraestructura de DNS está pirateada (envenenamiento de caché, etc.), el atacante podría someter a su usuario a muchos ataques.

Además, si el cliente está utilizando un software como Fiddler , o un proxy corporativo, ese software puede facilitar su SSL conversacion.

Para mitigar esto, mira el "emisor" del certificado SSL. Si la conexión SSL está pasando 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 administra 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 (la 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 administre el proxy y de cómo se utilicen sus registros, esto puede ser aceptable o malo desde su perspectiva.

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

  

Cuando el proxy SSL intercepta un SSL   Conexión, presenta un emulado.   certificado de servidor al cliente   navegador. El navegador del cliente emite un   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 emisor   certificado utilizado por SSL Proxy es   importado como una raíz de confianza en el   almacén de certificados del navegador del cliente.

     

El ProxySG hace todo configurado   certificados disponibles para descargar   A través de su consola de gestión. Usted puede   Pedir a los usuarios finales que descarguen el emisor.   Certificado a través de Internet Explorer   o Firefox e instalarlo como un confiable   CA en su navegador de elección. Esta   elimina el certificado emergente para   certificados emulados ...

Algunas compañías evitan el problema emergente de certificados mencionado anteriormente al implementar los certificados raíz (del Proxy) en cada estación de trabajo a través de GPO. Aunque esto solo afectará al software que utiliza el almacén de certificados de Microsoft. Los programas como Firefox y Chrome deben actualizarse de manera diferente.

    
respondido por el random65537 07.12.2010 - 23:44
fuente
12

Como SSL se basa en las Autoridades de Certificación (CA), y básicamente cualquier organización puede convertirse en una CA, siempre son posibles los ataques de intermediarios con certificados falsos y firmados por la CA. Entonces, mientras que SSL sigue siendo una gran mejora en comparación con la no encriptación, su seguridad está sobrevaluada debido a que el sistema de CA no funciona. En ese sentido, los certificados autofirmados serían tan seguros como cualquier certificado firmado por una CA, pero los navegadores los marcarán como sospechosos.

    
respondido por el Jörn Zaefferer 11.11.2010 - 22:57
fuente
10

SSL es muy seguro, aunque alguien puede robar la cookie de sesión de alguien si ejecuta CUALQUIER página en una línea no cifrada. Si pudieras, haría el sitio all-SSL. O posiblemente, la cookie solo envíe las conexiones cifradas y tenga páginas públicas no seguras que no sean específicas para ese usuario.

    
respondido por el James T 11.11.2010 - 22:45
fuente
9

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

Esto no es realmente un problema con SSL en sí, solo es algo a tener en cuenta. Puede asumir con seguridad que nadie puede escuchar 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.

    
respondido por el Magnus 11.11.2010 - 22:52
fuente
9

Dado que SSL cifra la transmisión, no se pueden escuchar 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 permitirles enviar pares de usuario / paso cifrados a su servidor), luego, cuando envíe una cookie, debe tener en cuenta que podría interceptarse fácilmente (como si su usuario estuviera en una conexión inalámbrica no protegida).

El reciente drama de FireSheep tiene que ver con esto.

    
respondido por el gbr 11.11.2010 - 23:02
fuente
6

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

La autenticación se realiza por medio de las 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 yo fuera propietario de Google.com, se lo demostraría a Verisign y 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 ser propietario de otro dominio, adquiere un certificado de comodín que es demasiado amplio, o simplemente XKCDs para que la CA emita algo Viciosos (¿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 ningún certificado falso en su cadena de confianza, entonces cuando se conecte a un sitio, puede (con fines de discusión) estar seguro de que el certificado coincide. En circunstancias normales, esa conexión está encriptada. Eso evita que alguien lea tus datos.

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

    
respondido por el Jeff Ferland 27.04.2011 - 23:18
fuente
6

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

  

El análisis de 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 cifrados y no se pueden descifrar. 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.

Suponiendo,

  1. un atacante conoce tu protocolo,
  2. un atacante sabe quién se está comunicando con quién
  3. el atacante no puede descifrar mensajes.
  4. no oculta su tráfico real en una gran cantidad de tráfico sin sentido (chaff)

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

Si tu protocolo es muy simple:

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

Un intruso que no pueda descifrar sus datos puede determinarse por la mera presencia de un mensaje que desea disparar armas nucleares, aunque tal vez no a quién.

Si su protocolo es más complejo:

  1. Usted pide un libro.
  2. Te envío el contenido.

Es posible que un atacante no pueda decir quién está leyendo "Guerra y paz" contra "Atlas Shrugged" pero puede distingue, basado puramente en el tamaño del mensaje, si están leyendo una de las primeras novelas de 55 páginas de Kafka "La metamorfosis".

    
respondido por el Mike Samuel 01.09.2014 - 19:00
fuente
4

Sin contar las diversas respuestas de otros sobre otros problemas potenciales, suponiendo que esté utilizando SSL 3.0 y un cifrado seguro, debería ser seguro.

El uso de los protocolos ssl más antiguos (2.0) o el uso de una clave de cifrado débil podría abrirte a vulnerabilidades.

    
respondido por el Doozer Blake 11.11.2010 - 22:59
fuente
4

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 está modificando en ruta)
  3. (opcionalmente, pero típicamente) Privacidad de datos (el usuario y el servidor saben que no se está interceptando el tráfico en la ruta)
  4. (opcionalmente, pero raro) Autenticación del cliente, si el cliente también tiene un certificado

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

Esto es solo un boceto, y hay muchos ifs, ands y buts. En el escenario más típico, el SSL basado en navegador, el esquema puede romperse en muchos casos sin romper la criptografía o el protocolo, pero 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 con SSL, creado para parecerse al real en todos los aspectos, pero la URL.

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

    
respondido por el frankodwyer 27.04.2011 - 20:54
fuente
2
  

Cuando alguien se conecta con SSL   (https) a nuestro servicio y envía el   Datos de autenticación correctos, ¿es   Seguro para transmitir todos los datos sensibles.   sobre esta linea, o puede ser que   todavía hay escuchas ilegales?

El eslabón débil en esta cadena es casi seguro que no es SSL, pero el usuario, que generalmente puede ser engañado para que se conecte a un sitio intermedio falso, ya sea a través de la suplantación de la web / suplantación de hipervínculos, o presentando un certificado no válido y descartando el navegador y procediendo a conectarse de todos modos.

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

    
respondido por el frankodwyer 19.04.2011 - 16:59
fuente
2

Cuando no está utilizando SSL, todas las comunicaciones pueden ser fácilmente interceptadas, lo único que debe hacer es lanzar el sniffer de paquetes (es decir, Wireshark).
SSL lo impide, 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 interceptación. Obviamente, no quieres que otra persona lea tus correos privados, ¿verdad?
En cuanto a la búsqueda de 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 más arriba), por otro lado, se asegura de que está hablando con una empresa legítima: autentica el servidor. Así que el canal es seguro y confiable.

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

    
respondido por el Paweł Dyda 27.04.2011 - 20:55
fuente
2

La respuesta corta es no. Respuesta más larga: una recopilación de las respuestas anteriores más: Si resolvemos la autenticación, por lo tanto, el hombre en el medio, con la conexión SSL tradicional, alguien que esté atento al tráfico podría descifrarlo más tarde si obtiene una clave secreta del servidor (piense en NSA y en Cartas de seguridad nacional). Hay 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.

Mire el texto RC4_128 con SHA1 para la autenticación de mensajes ECDHE_ECDSA. Esto dice:

  1. El servidor ofreció el canal SSL RC4_128b con resumen SHA
  2. Dentro de este túnel, cada mensaje está cifrado con curvas eclípticas, donde la clave se deriva mediante la función Diffie-Helman, y se firma con el cifrado de curvas eclípticas utilizando el algoritmo de firma digital

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

    
respondido por el Vladimir Jirasek 10.10.2013 - 22:15
fuente
2

@Vladimir tiene razón en que enlace 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 autenticación de mensajes" usa RC4 encriptación de 128 bits y 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 el mecanismo de intercambio de claves" no se aplica a los mensajes individuales, es parte (la mayoría) de Apretón de manos que se produce 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 las claves de sesión utilizadas para el 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 puede cifrar nada directamente con DH o ECDH, solo hacen una clave u otro acuerdo secreto).

    
respondido por el dave_thompson_085 14.02.2014 - 02:27
fuente
2

¿Es seguro para el usuario o es seguro para usted? Supongamos un ataque de hombre en el medio. El atacante se las arregla para capturar el tráfico del usuario, pretende ser usted para el usuario y pretende ser el usuario para usted. Ese tipo de ataque normalmente 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. Así que ahora el atacante puede leer y modificar todo el tráfico entre el usuario y usted, y por lo que sé, no hay forma de que lo detecte.

Entonces, si la indagación y la modificación del tráfico perjudican al usuario, eso es realmente su culpa y su propio problema. Y no puedes evitarlo por completo de todos modos, porque MITM te puede excluir por completo y solo hablar con el usuario que pretende ser tú. Pero si la indagación y la modificación del tráfico le hacen daño, debe confiar en que el usuario no será estúpido, o mejor autenticar al usuario también (el usuario necesitaría un certificado, y puede verificarlo de una manera que el MITM no pueda falso).

    
respondido por el gnasher729 26.03.2014 - 18:07
fuente
1

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 pregunta si es seguro asumir que la línea es "segura" y que los datos no cifrados se pueden pasar ADEMÁS del 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 una escucha pasiva que simplemente ignore los datos cifrados y guarde los datos no cifrados.

PERO puede estar seguro de que no hay escucha activa (MITM), lo que significa que puede establecer de forma segura una conexión SSL / SSH no autenticada con la misma fuente / destino que la línea autenticada. Esto no proporcionó ningún detector selectivo que ciertos conectores MITM, pero, sin embargo, el intruso 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, si lo hace 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, digamos 123.123.123.123 a 24.24.24.24, también puede conectar de forma segura un cliente SSH de 123.123.123.123 a 24.24.24.24 sin autenticar mutuamente la huella digital de SSH, siempre que pueda confíe en todo lo que hay detrás del enrutador o firewall NAT del otro lado.

Pero incluso si eso significa seguro, existe un pequeño riesgo de que un intruso escuche las conexiones MITM al azar y espere que no se detecte, por lo que, como ya tiene una conexión autenticada con la IP de destino, ¿por qué no usar esa conexión autenticada? mutuamente verificar la huella digital SSH? ¡Es tan simple como publicar la huella digital SSH correcta en un sitio web con seguridad SSL!

    
respondido por el sebastian nielsen 01.09.2014 - 18:39
fuente
0

HTTPS TLS / SSL incluso los más actualizados pueden ser fácilmente escuchados por un dispositivo Juniper configurado como MITM. No es seguro.

enlace

    
respondido por el user3260912 10.07.2017 - 16:48
fuente

Lea otras preguntas en las etiquetas