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.
Es importante entender qué hace y qué no hace SSL, especialmente porque es una fuente muy común de malentendidos.
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.
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. :)
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 que se establece 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.
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.
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.
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.
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.
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 que envíen pares de usuarios / pases 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.
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.
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,
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:
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:
Es posible que un atacante no pueda decir quién está leyendo "Guerra y paz" contra "Atlas Shrugged" pero puede distingue, basándose puramente en el tamaño del mensaje, si están leyendo una de las primeras novelas de 55 páginas de Kafka "La metamorfosis".
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 protocolos ssl más antiguos (2.0) o el uso de una clave de cifrado débil podría abrirte a vulnerabilidades.
SSL generalmente aumenta la seguridad al proporcionar:
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.
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 la advertencia del 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).
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.
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:
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!
@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).
¿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).
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!
HTTPS TLS / SSL incluso los más actualizados pueden ser fácilmente escuchados por un dispositivo Juniper configurado como MITM. No es seguro.
Lea otras preguntas en las etiquetas web-application tls