Tiene que ver con la compresión VBR (variable bit rate) que genera un resultado predecible, sobre todo en la parte de rango de bytes de los comandos HTTP GET que se alinean perfectamente con los límites de segmentos de vídeo. Para el estudio se analizaron 42 vídeos de Netflix. Para probar el algoritmo, se elegieron al azar 100 películas de Netflix y se analizó el tráfico (https) generado. De media el programa tardó menos de 4 minutos en identificar el vídeo que se estaba viendo, y más de la mitad estaban identificados antes de 2:30.
|
etiquetas: netflix , tcp/ip
Por ejemplo http:/ /xxxxxxx/restopath
Tu conexión segura a netflix esta también comprometida, pudiendo un atacante robar tus credenciales/cookies para acceder a tu cuenta
Podría bastar, como bien dicen, con aleatorizar los paquetes, recolocándolos en local.
De lo más importante de un algoritmo de encriptación es que no sea predecible y algo que rompe la cabeza a todos los expertos aun hoy dia por la imposibilidad de números aleatorios reales entre otras cosas. Y es por eso que cuando es predicible o se observa una pauta, o identificar un contenido el algoritmo esta roto.
Pero, sinceramente, que alguien sepa que veo Stranger Things o 13 reasons why, me la trae un poco al pairo!
Básicamente porque... qué persona decente no ve eso? Es una manera de detectar posibles lacras de la sociedad!!
Eso y que vean los videoclips de la Sabater.
Sobretodo lo de la Sabater.
Demuéstramelo.
La única manera de evitar esto sería agrandar artificialmente los paquetes, lo cual no sería muy bueno y la verdad no se si la necesidad de privacidad es tan grande como para justificarlo.
Y la pagina a la que te conectabas ya se sabe cual es, solo había que estar al loro cuando hiciste la resolución de nombre de dominio para conectarte, y esa conexión no va cifrada*. O ponerte un ruter que traiga configurado que se conecte a un servidor tuyo para hacer la resolución de nombres. ¿Cuantos aquí han cambiado el servidor DNS que usa su ruter? ¿Y de los que lo habéis cambiado, cuantos habéis puesto uno que no sea 8.8.8.8 o 8.8.4.4?
Vamos, que no. Que olvidaos, que aunque usen HTTPS, ya no hay forma de esconder que contenido estas consumiendo. Otro torpedo en la linea de flotación de la privacidad en Internet, y ya van...
(*: juraría que una de las cosas chulas que trae el protocolo de onion routing Tor es que las peticiones de resolución de nombres se hacen a traves de la red, lo que impide saber no solo a que maquina, que IP, te conectas, sino a que pagina web dentro de esa maquina te conectabas)
Prueba a borrar tu cuenta.
OSI no despegó, aquí hablamos de TCP/IP. No me mezcles cosas, que ya es bastante técnico el tema...
#40 goto #2
Luego es lo que dices el 90% utiliza los DNS de Google,así que imagínate.
De todas maneras tener otros DNS salvo que sea de un servidor propio puede confeccionar una base de datos con la navegación y cuanta gente tiene los conocimientos y ganas para montarse un servidor DNS propio? Una alternativa buena podría ser un servidor DNS a través de una raspberry,pero la velocidad está bastante capada,lo que haria más lenta la red local,para casos así aconsejo una orange pi
Todo parece inocente pero son herramientas en poder de los gobiernos/grandes empresas, el simple hecho de tener ese poder extra y rezar por el comportamiento ético de los responsables es una muy mala estrategia como la historia nos indica, cuando se tiene poder se aprovecha siempre a su favor;
Pueden ser perfiles brutales de tendencias políticas, redes de contactos, intereses y status socio-economico que al estar automatizado y bajo coste es una 'extra' útil para miles de casos y que no nos beneficia. Los equilibrios teóricos de la democracia se van a la mierda, mas aún, si cabe.
Me explico, si yo pongo un servidor público en el que tengo 4 ficheros para descargar, A B C y D, y los 4 miden distinto, da igual que los sirva por HTTPS porque como A,B,C,D son conocidos, sabiendo simplemente la longitud de la descarga un tercero puede saber si se ha descargado A,B,C o D.
Podría hacerse que los 4 midiesen lo mismo (o no, depende del formato), pero sería una putada si A mide 8 bytes y D mide 8 gigas :))
Ahora mismo no tengo solución general (*), pero si podría ser una recomendación concreta que si alguien pusiese un servidor con algunos archivos comprometedores y otros no, debería de hacer algo para proteger la privacidad, quizás haciendo eso, que todos midan igual.
(*) podría haber soluciones parciales del lado del cliente para descargas genéricas, tal como volver a pedir partes del fichero a sabiendas de que ya se tienen, simplemente para distorsionar la huella.
Excepto si detectan que veo MyHyV...
No podrías descifrar contraseñas, emails, metadata con esta técnica. El cifrado no se ha roto en ningún momento.
Además estas suponiendo que no hay ninguna ltra conexión con el servicio mientras.
Si se rompiera el RSA/AES, no solo Netflix estaría comprometida. Sino todas las transacciones bancarias del mundo.
Pero esque este exploit no afecta en nada a estos algoritmos.
Si te digo que es absurdo es porque es absurdo, no pasa nada por reconocer que te equivocas.
Luego solo tienen que interceptar la comunicación donde el cliente envía la cookie que lo identifica en sus servidores. Y esas son las credenciales que robas.
De esa forma solo puedes acceder a la comunicación de ese cliente y en ese servidor, no a otro.
Lo haré cuando me confirméis que me equivoco, de momento lo que decis tu y el otro campeón no vale para nada.
Eso que dices siempre se ha podido hacer, coges una película la encriptas y miras a ver si puedes distinguir un patrón para romper el cifrado.
Eso llevan intentandolo hace años con AES y no han conseguido nada.
Como comentaba otro usuario este mismo hilo el ataque BEAST, o algo similar se podría utilizar apoyado en esto para descifrar el contenido. Y en SSL si que se ha conseguido varias veces descifrar por patrones, no es la primera vez que encuentra una debilidad de repeticion/patrones y de forma general y han puesto a cuatro patas la conexión https, no como esta que solo en principio afecta a netflix y otras similares, aun más grave.
Detectar patrones de la manera descrita en el articulo no supone en absoluto un problema de seguridad para Netflix ni para youtube ni para cualquier banco del mundo o web del mundo. Punto.
Un saludo, campeón.
Cc/ #13
es.m.wikipedia.org/wiki/Segmento_TCP#Campos_de_la_cabecera_TCP
es.wikipedia.org/wiki/Ataque_POODLE
omicrono.elespanol.com/2015/05/todo-lo-que-necesitas-saber-de-logjam-l
El caso es que en el estudio se basa en una herramienta de la Universidad de Priceton llamada OpenWMP, que por cierto ya fue usada para comprobar como las cripto-cookies de Google espiaba a los usuarios de Google Chrome:
go-to-hellman.blogspot.com.es/2017/01/googles-crypto-cookies-are-track
El tema es que la suma de usar Silverlight por parte de Netflix, la información necesaria de la cabecera de un archivo MPEG4 y el DASH (tráfico streaming dinámico adaptativo variable sobre HTTP) permite hace una casi identificación perfecta sobre un vídeo. Al parecer mayor es esta identificación cuanto más largo sea el vídeo y menos fluctue la conexión a Internet.
En cualquier caso dicen que especialmente el estudio serviría para Netflix, no para otros sitios, por su distinto tratamiento del contenido.
Salu2
El modelo OSI es abstracto, teórico, no implementa ningún protocolo en concreto, sino que sirve de base para otros modelos.
A ver si hacemos los deberes antes de reprochar, porque efectivamente, se trata de un tema técnico, no basta con soltar lo primero que se le ocurra a uno.
Como bien dice #45 estoy mostrando a #1 que el problema está a otro nivel
Si lo que quieres decir es que algún día se acabará por romper. Es muy fácil que tengas razón, con todos los algoritmos criptográficos existentes.
Si lo que quieres decir es que conociendo el texto claro es más facil averiguar la clave (known plaintext attack) esto no es cierto con los algoritmos modernos, pues en sus especificaciones está el ser resistente a este tipo de ataque.
Si lo que quieres decir es que conociendo una pareja de texto claro y texto cifrado, sabiendo que se usa la misma clave, sería posible encontrar correspondencias en otro texto distinto, no eres el primero en pensarlo. Para eso que se usan los modos de operación.
www.tutorialspoint.com/cryptography/block_cipher_modes_of_operation.ht
¿Alguien conoce un remedio casero contra los ataques de risa? ¡Rápido, porfa!
@blackheart no tiene ni puta idea eso esta claro, y es bastante bocas para lo ignorante que es, que se dedique solo a negativizar que es para lo único que vale y llamar a papa admin..
¿Acaso no es conocida la página principal de tu banco? ¿Y los recursos javascript estáticos? ¿Y los banners, animaciones e incluso vídeos que contiene? Porque ahora mismo todo eso se tiene que cargar por HTTPS.
Íbamos a estar ahora hablando de Netflix...
Aun así las sesiones se cierran rápidamente por si las moscas.
security.stackexchange.com/questions/5355/compute-the-aes-encryption-k
crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-
en.wikipedia.org/wiki/Known-plaintext_attack
En resumen: la muestra en claro te sirve para validar la clave, pero sigues necesitando probar todas las claves por fuerza bruta para ver cual era la original.
¿O conociendo un clip de video determinado saber si determinados usuario lo está enviando?
Esto me suena a ataque replay o algo así.
Y como sutilmente te he resaltado, es jodido de cojones que algo se base en otra cosa que tardó 3 o 4 años en empezar a aparecer...
Suspenso en historia de la informática. A Junio y ni me rechistes.
EDIT: #81 A otro nivel y en otra galaxia, pero bueno... me sacas OSI para hablar de HTTP que va sobre TCP. Carambola a cuatro bandas.
Me recuerda un poco a esos ataques contra el paquete de datos para conectarte a una Wifi. Uno solo es irrompible, pero si juntas suficientes paquetes, se vuelve vulnerable... aqui lo veo parecido, si puedo saber que te mandaban, aunque venga cifrado, a partir de un volumen de datos tan grande que los dos tenemos, yo creo que se podria atacar al cifrado de la sesión.
Me explico....
La mayoría de aplicaciones web no regeneran la semilla en cada petición, tampoco es recomendable pero si es recomendable regenerarla cuando accedes a partes delicados como cuando cambias las preferencias, con lo cual te quedarías tu la nueva valida y el fuera de la session por invalida.
El tio se quedaria desconectaría por invalido y el logout no lo reconoceria y tu no tendrías problemas, luego hacer login muchos permiten dos sesiones con la misma cuenta. Claro que posiblemente sitios muy delicados como bancos no permitan eso, pero aun así posiblemente si vas a preferencias, cambias contraseña/email evitas el logout de el y lo pones en un aprieto hasta que contacte con la web.