Portada
mis comunidades
otras secciones
![Las cabeceras TCP/IP son suficientes para saber lo que estás viendo en netflix, incluso con HTTPS [ENG]](https://cdn.mnmstatic.net/cache/2a/18/media_thumb_2x-link-2758730.jpeg?1491978486)
#44:
Conocer los hábitos de movimiento (GPS movil), de compra (Tarjetas), de intereses (FB, Google,Twitter,etc...ISP logs) y ahora que tipo de videos consumimos (películas comerciales de Van Damme o documentales de denuncia contra dictaduras...)
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.
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.
#14:
#8 Porque el problema está en el comportamiento de la codificación del vídeo. El byte-range de los paquetes de petición (es decir, en la petición se indica "cuántos bytes queremos recibir") coincide con el tamaño de los segmentos de vídeo. Basta con que alguien cree una base de datos de estos segmentos (que harían una especie de "identificador único") con un crawler, como es el caso, para que, analizando unos minutos, sepas qué vídeo estás viendo.
Podría bastar, como bien dicen, con aleatorizar los paquetes, recolocándolos en local.
Podría bastar, como bien dicen, con aleatorizar los paquetes, recolocándolos en local.
#25:
#18 Pero es que el cifrado no esta comprometido. Es un ataque de estadística para identificar un contenido si tienes los datos de todos los contenidos que sirve Netflix, basado en que el servidor comprime y envía las cosas de una manera predecible. Están adivinando donde hay una obra contando el numero de camiones hormigonera que pasan, por poner un ejemplo tonto...
#15:
Por lo que entiendo del artículo esto puede aplicarse para intentar deducir cualquier stream de bitrate variable, analizando los patrones, solo que es más sencillo tener los patrones de Netflix para comparar que los de Youtube (por la cantidad de videos disponibles).
Comentarios
Conocer los hábitos de movimiento (GPS movil), de compra (Tarjetas), de intereses (FB, Google,Twitter,etc...ISP logs) y ahora que tipo de videos consumimos (películas comerciales de Van Damme o documentales de denuncia contra dictaduras...)
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.
#44 Sal un ratito a la calle a que te de el aire, que te veo agobiado.
#62 razón no te falta
#69 Era una broma, no te lo tomes a mal. Tiene mucho sentido todo lo que dices.
Por lo que entiendo del artículo esto puede aplicarse para intentar deducir cualquier stream de bitrate variable, analizando los patrones, solo que es más sencillo tener los patrones de Netflix para comparar que los de Youtube (por la cantidad de videos disponibles).
#15 Entiendes bien
#18 Pero es que el cifrado no esta comprometido. Es un ataque de estadística para identificar un contenido si tienes los datos de todos los contenidos que sirve Netflix, basado en que el servidor comprime y envía las cosas de una manera predecible. Están adivinando donde hay una obra contando el numero de camiones hormigonera que pasan, por poner un ejemplo tonto...
#25 Si puedes identificar el contenido cifrado y es predecible la conexión esta comprometida es cuestión de tiempo que salga algo para descifrarlo
#30 ¿Pensando en el ataque criptografico a Enigma cuando los muy inútiles mandaron "feliz navidad"? Una cosa es que sepas el contenido, otra muy distinta que el algoritmo sea lo bastante débil como para romperlo sabiendo el contenido, y ahí ya no te lo sé valorar... pero no debería ser tan fácil, o hace tiempo que habríamos hecho algo mejor que el cifrado de HTTPS.
El cifrado https no tuvo pocos problemas a lo largo de la historia y no se puede decir que sea infalible.
#40 goto #2
#40 la contraseña de cifrado varía de sesión a sesión y de cliente a cliente. Asi que no habría un patrón claro aún conociendo el contenido.
#52 Al contrario, existe un patrón y muy grande... ¡todo el streaming que se descarga! Si tiene identificado que vídeo es, si no hacen nada para insertar diferencias entre el fichero que te bajas tu y el que me bajo yo, tenemos en común todo ese fichero.
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.
#96 ese ataque siempre se ha podido hacer. Cifras archivos de tu disco duro y miras el binario que se genera.
No se ha reportado ningún ataque exitoso contra AES, por mucha cantidad de archivos que hagas.
#30 tu eres tonto o no entiendes nada
#30 no, no puedes sacar esa conclusión de ahí.
No podrías descifrar contraseñas, emails, metadata con esta técnica. El cifrado no se ha roto en ningún momento.
#50 yo no dije que esa técnica rompiera el cifrado si no es cuestión de tiempo que utilicen eso para descifrarlo. La conexión con netflix esta comprometida.
#54 me parece super absurdo, peras con manzanas.
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.
#56 Absurdo eres tu, con un patron y predicción se puede descifrar mensajes codificados apartir de observar como se cifra algo conocido como es el caso y solo afectara a ese sitio , sin romper el algoritmo.
#57 voy a morder el anzuelo: ¿Como usas esta técnica para robar credenciales que no conoces?
Si te digo que es absurdo es porque es absurdo, no pasa nada por reconocer que te equivocas.
#58 Repito, si conoces como cifra algo conocido y con las suficientes muestras se puede llegar averiguar el contenido de otra cosa codificada utilizando la misma clave sin romper el algoritmo, los patrones, predicciones y el saber que esta codificando y enviando no se llevan bien con ningún algoritmo.
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.
#59 que mala suerte que la contraseña de cifrado cambie de sesión a sesión.
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.
#63 Si cambia clave te joden la marrana efectivamente, o vuelta a empezar. Pero se puede.
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.
#59 En futuro cualquier algoritmo de cifrado se romperá, es cuestión de tiempo. Pero estamos hablando de décadas o incluso siglos en el futuro (incluso teniendo en cuenta el aumento en la potencia de cálculo). Nadie dice que no se pueda romper. Para romperlo se utilizarán miles de técnicas diferentes, puede que entre ellas esté la que se comenta aquí para detectar patrones de bytes en los datos enviados. Es una técnica extremadamente conocida y documentada. Pero a día de hoy no hay nada ni se le espera y por ello se considera un algoritmo seguro. En el momento en que ya no sea así entonces dejará de considerarse seguro. Lo gracioso de ésto es que se sabe cuando deberíamos de dejar de usar un algoritmo concreto.
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.
#59 Si, pero ojo con eso. Robas esa cookie en concreto, en el momento en que esa cookie caduque ya no tienes un login. Y basta con que el atacado haga logout+login para caducar esa cookie, dejarte en tierra y que tengas que romper otra vez la sesión.
#97 si con peros dependiendo de cuando regenera la semilla, realmente secuestras la session y si se regenera la semilla se queda el fuera y el logout no vale, y si no tiene métodos de comprobación de una session por cuenta tampoco el login.
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.
#99 Touché. Iva por ahi, pero lo has explicado mejor...
#100 he implementado varias veces desde 0 control de sesiones de diferentes formas y con técnicas, desde seguras hasta modos paranoicos, también estoy al tanto de las "best practices" en el tema. Por ahí no difícilmente me pillas dudando
#9 lo de que las credenciales Netflix estén comprometidas no se deduce del artículo. Yo veo simplemente que por los patrones de chunks de video recibidos del server se puede inferir que video es, pero no que se haya roto el cifrado.
#13 se deduce que si el cifrado esta comprometido, si es previsible y deducible el contenido es fácil descifrar el algoritmo y por lo tanto descifrar todo el resto del trafico.
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.
#18 Ahi habla de las cabeceras tcp, y en esa parte de la trama tcp no viaja ninguna cookie, no te inventes conspiranoias
Cc/ #13
https://es.m.wikipedia.org/wiki/Segmento_TCP#Campos_de_la_cabecera_TCP
#71 ese ataque no descifra nada, pero compromete el cifrado dando lugar/posibilidad a algun ataque que pueda descifrar la comunicación. No entiendes lo que digo.
#18 Un algoritmo está roto cuando es posible descifrar sin conocer la clave. No es el caso.
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.
https://www.tutorialspoint.com/cryptography/block_cipher_modes_of_operation.htm
#82 Ha ha ha,@blackheart opinando sobre criptografía, como si hubiera estudiado nunca algo.
¿Alguien conoce un remedio casero contra los ataques de risa? ¡Rápido, porfa!
#83 toma, esto te vendrá bien
#84 ¿No estás bien? Lo mínimo que esperaba de tí es un meme de esos.
#82 Yo no he dicho en ningún lado que el algoritmo este roto, por que no lo esta, es un problema exclusivo de netflix y similares. He dicho que la seguridad de netflix esta comprometida y su cifrado, y no solo la privacidad. La clave difícilmente se puede averiguar, pero tampoco es necesaria.
@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..
#86
#86 En el fondo llevas razón, porque si eres capaz de deducir el texto claro de la comunicación (con el truco que sea), el que vaya cifrada no sirve de mucho.
#88 #86
¿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...
#89 en cualquier web sin fallo de este tipo ves una conexión al servidor solamente, ni la pagina ni nada. No sabes absolutamente nada.
Aun así las sesiones se cierran rápidamente por si las moscas.
#90 Tienes el mismo patrón que con los vídeos pero más evidente y aún menos factores (la página que visite el usuario primero va a ser el home en la mayoría de los casos): el tamaño de cada fichero. Si sabes que el último trozo de 352 bytes corresponde al último paquete de un recurso JS que te descargas, ya tienes la información en plano y en cifrado.
#91 no hables de lo que no entiendes anda.
#92 O dicho de otro modo: no sabes qué argumentar.
https://security.stackexchange.com/questions/5355/compute-the-aes-encryption-key-given-the-plaintext-and-its-ciphertext
https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks
https://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.
Viendo que Netflix sólo saca un grado C en el test de Qualys (SSL Labs) y siendo vulnerable a POODLE por usar aun SSL3 y claves DH/Diffie-Hellman débiles (ataque LogJam) creo que esto de la noticia es el menor de sus problemas.
https://es.wikipedia.org/wiki/Ataque_POODLE
http://omicrono.elespanol.com/2015/05/todo-lo-que-necesitas-saber-de-logjam-la-nueva-vulnerabilidad-en-ssl/
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:
https://go-to-hellman.blogspot.com.es/2017/01/googles-crypto-cookies-are-tracking.html
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
#6 ¿por que no?
#8 Porque el problema está en el comportamiento de la codificación del vídeo. El byte-range de los paquetes de petición (es decir, en la petición se indica "cuántos bytes queremos recibir") coincide con el tamaño de los segmentos de vídeo. Basta con que alguien cree una base de datos de estos segmentos (que harían una especie de "identificador único") con un crawler, como es el caso, para que, analizando unos minutos, sepas qué vídeo estás viendo.
Podría bastar, como bien dicen, con aleatorizar los paquetes, recolocándolos en local.
#14 #24 Gracias, no sé en que andaba pensando que no lo vi claro.
A costa de la eficiencia ¿sería posible que Netflix añadiera un padding en los segmentos para que no fueran tan fácilmente identificables?
#8 El problema es a nivel de paquetes de TCP/IP no a nivel de http.
#9 Éso es falso. Es un "problema" de privacidad en Netflix y ya está. No hay robos de cuentas netflix ni riesgo.
#17 ignorante de gatillo fácil.
#20
Demuéstramelo.
#21 a un paleto
#23 Reportado.@admin
#26 Me voy a poner a llorar si me banean
#34 Yo creo que a ti te ha molestado que te lleven la contraria. Como no sabes admitir humildemente que estás equivocado pues has hecho lo único que gente de tu edad sabe hacer: patalear e insultar. Un secreto y consejo para el futuro, a veces nos equivocamos y no pasa nada ni pierdes dignidad ni respeto.
Prueba a borrar tu cuenta.
De hecho , HTTPS y la compresión de datos no se llevan bien , como se sabe desde hace años con el ataque BEAST
Mientras no haiga porno en el netflix ése, no problemo...
#11 ¿Quieres dormir un poco más intranquilo con eso? Están atacando a Netflix porque es una manera fácil de hacer un titular viral, pero este problema afectaría a cualquier servidor de streaming con bitrate variable que no intente activamente evitar el problema. Pornhub, pornotube, xhamster... todas usan las mismas técnicas, así que todas son vulnerables a este ataque.
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)
#37 si te conectas a xvideos o similares,ya t digo yo que no es para ver un documental,así que tampoco hay tantísimo problema.
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
#43 https://dnscrypt.org/
#43 ...offtopic: tu no has probado una raspy 3, ¿verdad? Mira que decir que es demasiado lenta para tenerla de servidor proxy DNS...
#98 me encanta raspberry,tengo dos,pero no es gigabit,cosa que Orange pi pc2 si lo es,esa es la diferencia,a lo mejor lenta no es la mejor definición,si no que hay alternativas similares más rápidas para esa ejecución
Y yo me pregunto, ¿ no es posible añadir en el GET un número aleatorio en cada petición que no interfiera en los parámetros pero la codificación del GET en https resulte inidentificable?
Por ejemplo http:/ /xxxxxxx/restopath
#1 No
#1 https://es.wikipedia.org/wiki/Modelo_OSI
#22 Ejem... https://es.wikipedia.org/wiki/Transmission_Control_Protocol
OSI no despegó, aquí hablamos de TCP/IP. No me mezcles cosas, que ya es bastante técnico el tema...
#39 Yo creo que se refiere a que #1 sí está mezclando cosas. Los parámetros GET corresponden a la capa HTTP, que está en la capa de aplicación. TCP es la capa de transporte.
#39 TCP/IP es una implementación del modelo OSI, al igual que lo fue IPX/SPX y otros tantos.
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
#81 De eso nada. El modelo OSI venia diseñado desde Europa, cuando en el 1977 los británicos quisieron hacer un estandar dentro de ISO, y empezaron a maquinar algo que se publicó en 1984. Mientras los ingleses empezaban a poner cosas sobre el papel, TCP llevaba en marcha en DARPA desde 1973 con un modelo practico que se publica en 1981, con menos capas y más sencillo de implementar. Resultado: OSI se quedó en un cajon y en los libros de texto, y todo dios usa TCP, porque llegó primero y golpeó más fuerte.
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.
#95 Empieza por aprender la diferencia entre un modelo y una arquitectura antes de venir a dar clases que nadie te ha pedido, cansino del offtopic
#1 Esto es https, así que el contenido del get no se ve. Lo que yo entiendo es que lo que están analizando es el tamaño de los paquetes, no su contenido porque va cifrado. Como los datos van comprimidos, su contenido determina su tamaño esté cifrado o no. Cada película tendrá una secuencia de tamaños característica.
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.
#29 No está analizando ni el tamaño ni el contenido, únicamente las cabeceras.
#51 Claro, las cabeceras que contienen el tamaño que se transmitirá, ¿no?
#55 El fingerprint de la cabecera es el mismo que el de las cabeceras que él mismo ha preparado para cada peli, así reconoce lo que se está viendo. Eso entiendo yo.
#61 Pero... ¿al cambiar la clave de cifrado de una conexión https a otra no debería ser todo diferente? (Excepto el tamaño, claro)
#66 Echa un vistazo a lo que se manda/responde a Ntflx en la consola de desarrollo, yo ahora estoy en el curro.
#75 Lo que pasa es que al ir por https, lo único que puedes saber de los paquetes es la ip, puerto y tamaño del paquete. Poco más se puede ver en una comunicación cifrada. De heecho, los mismos datos enviados a un cliente y a otro van con claves diferentes (se crean en el momento de la conexión inicial) así que lo único que diferencia a un paquete de otro es el tamaño.
#76 Pues tienes razón... No comprendo entonces el mecanismo,
#78 Lo que yo entiendo es que la pinta la obtienen de la longitud de los paquetes en sí o tal vez del tiempo en que se manda cada uno, porque la compresión de cada película genera patrones distintos. Basta con atrapar unos cuantos paquetes y analizar sus tamaños y tiempos para saber de qué película se trata.
#1 Eso se puede pero no serviría de nada, no se basan en las URL si no en el ancho de banda, en cómo va variando. Forma una especie de huella dactilar del vídeo. Si se precargase el vídeo por adelantado, se bajaría tan rápido como se pudiese, pero no es el caso, se va llenando un buffer según la persona va "consumiendo", viendo, lo que está en el buffer. Ese buffer deduzco que tienen un tamaño que no se define en bytes si no en segundos de vídeo. Esos segundos unas veces ocupan más bytes que otros, depende de cómo sea el fotograma, cuánto consiga comprimirse. Al rellenarse el buffer porque ya has visto un trozo de vídeo, se recibirán más o menos bytes según la secuencia que se esté cargando. Si mides eso, cuántos bytes pasan por la conexión en función del tiempo, se puede representar como una curva característica de ese vídeo.
#31 aunque el buffer se definiese en bytes yo creo que el efecto es el mismo una vez avanzados los primeros minutos, así que quizá mi presunción es errónea. Con buffer definido en bytes al principio se llenaría a velocidad máxima y siempre hasta tener X bytes cargados, esa parte sería irreconocible, pero más adelante el buffer se vaciaría según la misma curva que dije en el otro comentario, y por tanto se rellenaría de la misma forma. Sería reconocible igual pasados unos minutos.
31 #36 En este caso el buffer es irrelevante, porque lo que se mira es la cantidad de datos recibidos desde el servidor entre dos solicitudes por parte del cliente. El problema está en que a Netflix le conviene enviar los vídeos en bloques de tamaño predefinido... y resulta que esos tamaños forman una huella dactilar de cada vídeo.
#67 ¿Serán bloques de x segundos?
#74 En el ejemplo del paper, envía bloques cada 4 segundos para un vídeo de 3830kbps (velocidad efectiva de red 5500kbps). Según el protocolo MPEG-DASH, cada bloque tiene que empezar con un keyframe, así que supongo que enviarán uno o unos pocos keyframes por paquete.
El tema del buffer es irrelevante, porque por mucho que el cliente tenga un buffer de 40 segundos, al pedir los bloques tendrá que pedir 10 bloques de 4 segundos cada uno, que tendrán el mismo tamaño identificable independientemente de si se transmiten de golpe o más espaciados en el tiempo.
Una solución sería añadir basura aleatoria a cada bloque, para que el tamaño de un mismo bloque no siempre fuese el mismo... pero eso es ancho de banda extra que hay que pagar, y no sé yo si Netflix estará por la labor.
#1 El problema no está en la petición GET, sino en los datos que envía Netflix.
En concreto, al usar codificación VBR con transmisión sobre DASH, Netflix transmite el vídeo en "bloques completos"... cada uno con un tamaño diferente debido al VBR, en un orden determinado en función del vídeo que sea. Basta con hacerse una base de datos con la lista de los tamaños de los bloques de todos los vídeos de Netflix (lo cual resulta que es bastante fácil), y con solo mirar qué secuencias de tamaños de bloques te envía Netflix, al cabo de x bloques se puede deducir qué vídeo es el único que tiene esa secuencia, y por tanto estás viendo.
#60 Netflix tiene porno?
#1 Tu añades un GET con un numero aleatorio. La petición *de subida* llega al servidor. El servidor te envía el fichero de vuelta, y como ya hemos pasado la fase de handshake inicial, la clave que protege la conexion en ese momento es simetrica para ambos canales, tanto el de subida como el de bajada.
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.
¿En la encriptacion de whatsapp se podria saber si un usuario manda a otro o a un grupo un video determinado a partir de la firma del tráfico?
¿O conociendo un clip de video determinado saber si determinados usuario lo está enviando?
Esto me suena a ataque replay o algo así.
#94 Si eres Whatsapp si puedes saberlo.
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)
#10 No. Sólo que pueden saber qué película estás viendo y cuándo. Y como en USA ahora los ISP pueden vender esos datos, que los aprovechen para mandarte propagandas de "enlarge your penis" si ves mucho porno.
¿Que consecuencias tiene esto?
#3 Un aumento en el valor de las acciones de papel albal, está clarísimo.
#5 Los problemas de privacidad e intimidad, no son cuestiones tontas y paranoides. No me gustaría que se hiciese público por alguien TODO lo que veo por internet, y estoy seguro que a ti tampoco, no se si sabes a lo que me refiero... Y NO, NO ES ANDA ILEGAL
#12 Todo lo que veo por internet no, estoy de acuerdo. Aunque yo no veo nada eXXXcitante ni eXXXtraño.
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.
#19 La competencia de video en streaming, por ejemplo. Para analizar lo que triunfa y establecer futuras estrategias de produccion
#35 No veo problema para mi, en todo caso beneficio ya que lo que hagan mejorará.
Excepto si detectan que veo MyHyV...
#12 La mayoría de gente con redes sociales ya les hace ese trabajo gratis publicando las series o pelis que ven en Twitter o facebook, o bien analizando tus busquedas o visitas a webs. Bastante más fácil que sniffar tu tráfico https y aplicar el algoritmo este.
#12 no, es porno.
#3 Ninguna. Sólo un problema de privacidad en el futuro (que terceros puedan saber que contenido estás viendo en netflix).
#7 Correcto, a veces me expreso mal y consideraba obvio lo de la privacidad. Preguntaba más bien por posibles robos de información personal, o usurpación de cuentas. Cosas de este tipo.
#3 #10 Que los ISP y otros pueden saber lo que estas viendo y tus gustos.
Tu conexión segura a netflix esta también comprometida, pudiendo un atacante robar tus credenciales/cookies para acceder a tu cuenta
Tendriaa que hacer que el proceso analizara previamente el tráfico de Netflix sabiendo lo que esta viendo para encontrar coincidencias
#16 Disponen de una base de datos para ello.
Chico, asómate al salón y te ahorras las tonterías.
Estoy pensando que esto tiene implicaciones a varios niveles y a la vez es muy tonto.
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.
#46 tu algoritmo empezara a tener problemas cuando haya varios archivos con el mismo tamaño.
Además estas suponiendo que no hay ninguna ltra conexión con el servicio mientras.
¿Así que mi vecino el pirata de WiFis se va a enterar de lo que estoy viendo en streaming? Oh the humanity!