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
Podría bastar, como bien dicen, con aleatorizar los paquetes, recolocándolos en local.
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.
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
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.
No podrías descifrar contraseñas, emails, metadata con esta técnica. El cifrado no se ha roto en ningún momento.
Por ejemplo http:/ /xxxxxxx/restopath
Prueba a borrar tu cuenta.
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
Ten en en cuenta que si tu le envías un mensaje a Bob, Whatsapp tiene que saber donde tiene que entregarlo así que aunque no pueda leer el contenido del mensaje si sabrá que habéis estado en contacto
Los vídeos creo que también saben quienes los comparten, aunque no pueden acceder al contenido del vídeo(cifrado con AES)
OSI no despegó, aquí hablamos de TCP/IP. No me mezcles cosas, que ya es bastante técnico el tema...
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.
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.
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.
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.
#40 goto #2
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.
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.
¿Alguien conoce un remedio casero contra los ataques de risa? ¡Rápido, porfa!
Aun así las sesiones se cierran rápidamente por si las moscas.
¿O conociendo un clip de video determinado saber si determinados usuario lo está enviando?
Esto me suena a ataque replay o algo así.
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.
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
Cc/ #13
es.m.wikipedia.org/wiki/Segmento_TCP#Campos_de_la_cabecera_TCP
@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..
Demuéstramelo.
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)
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.
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.
Si el servidor no añade nada que sirva de grano de sal y se limita a mandarte el archivo, el chorro de paquetes de bajada con el streaming del video estará codificado con la misma clave que la petición que le has mandado tu, con tu GET, tus parametros, y tu cookie de sesion. Rompe una de las dos y tienes la otra... ahí está el peligro, que tu puedes añadir un "&aleatorio=dalealegriaatucuerpomacarena" a la url si quieres, el servidor va a ignorar ese parámetro. Pero en la respuesta de vuelta es donde esta el riesgo de que rompan la clave.
Mira, no lo hizo el mismo equipo, no lo hicieron en la misma universidad, no lo hicieron en el mismo continente, y por más que te empeñes eran competidores, no "uno se basaba en el otro". Los dos son modelos y arquitecturas distintos que resuelven el mismo problema de dos formas distintas, y si te bajaras del burro dos minutos y buscases en google te darías cuenta de hasta que punto la cagas mezclando churras y merinas para luego intentar separarlas diciendo que una es madre de la otra.
Offtopic: dale al botón de ignorar, que no te cobran por ello. Si pretendes que me calle porque no soportes que te diga que eres un bocachancla, vas fresco.
¿12 horas dices? ¿de verdad crees que he leído tu respuesta según la has escrito y he estado 12 horas pensando en tí? Si de verdad crees eso, eres más tonto de lo que crees. Tengo vida más allá de mnm y tú no eres el centro de ella
Qué osada es la ignorancia...
Ale, chavalín, sigue troleando contra molinos, perdón, gigantes, como si tuvieses algo que demostrar, o como si a alguien le importases lo más mínimo. Un beso.
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.
Excepto si detectan que veo MyHyV...
Además estas suponiendo que no hay ninguna ltra conexión con el servicio mientras.
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
¿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...