Portada
mis comunidades
otras secciones
#10:
#5 Pero esta modalidad de ataque está relacionada con análisis de patrones de tráfico TCP y HTTP: paquetes, fragmentación; orden, frecuencia e interrelación de peticiones y respuestas (flujos); número y tamaño de los objetos de una página, etc. En ningún caso está relacionado con la "mística" criptográfica de TLS/SSL
De hecho, ya había pruebas de concepto de esto desde hace tiempo y algunos llevamos tiempo tratando con "apaños" que eluden el problema: tokens invisibles distribuidos aleatoriamente por la página, recursos externos (imágenes, CSS, javascript) desordenados -y falseados- en cada petición, etc. A eso hay que sumar ofuscación en el lado de cliente vía Javascript, cookies "mutantes", headers de relleno para hacer padding, peticiones falsas, etc. Había un paper de hace ya varios años que trataba todo esto esto.
No es nada nuevo, lo nuevo parece ser el grado de éxito y precisión conseguidos en esta investigación. Pero la alerta es anterior y ya deberían estar implementadas las contramedidas... deberían estar implementadas si no fuera porque la mitad de los fingenieros del mundo se dedican ahora a hacer inseguras apps para móviles y creen que Diffie-Hellman eran los padres putativos de Tom y Jerry.
De hecho, ya había pruebas de concepto de esto desde hace tiempo y algunos llevamos tiempo tratando con "apaños" que eluden el problema: tokens invisibles distribuidos aleatoriamente por la página, recursos externos (imágenes, CSS, javascript) desordenados -y falseados- en cada petición, etc. A eso hay que sumar ofuscación en el lado de cliente vía Javascript, cookies "mutantes", headers de relleno para hacer padding, peticiones falsas, etc. Había un paper de hace ya varios años que trataba todo esto esto.
No es nada nuevo, lo nuevo parece ser el grado de éxito y precisión conseguidos en esta investigación. Pero la alerta es anterior y ya deberían estar implementadas las contramedidas... deberían estar implementadas si no fuera porque la mitad de los fingenieros del mundo se dedican ahora a hacer inseguras apps para móviles y creen que Diffie-Hellman eran los padres putativos de Tom y Jerry.
#18:
#11
" coger el text encriptado y a base de fuerza bruta encontrar algunas relaciones de g, de forma que cuando aparezca un texto encriptado concreto, saben cual es el texto en plano que se corresponde. "
Eso es lo que entendí yo que han hecho... pero si los que hacen las aplicaciones lo hacen bien no serviría de nada ese ataque.
En la jerga criptográfica se llama "sal" (salt) a unos datos añadidos que hacen que un mismo origen tenga diferentes resultados al cifrarlo. Por ejemplo, al cifrar "MiPassword" le añado "Sal1" la primera vez, "Sal2" la segunda vez, etc... de forma que tendríamos "MiPassword+Sal1" y "MiPassword+Sal2" ... y el resultado del cifrado será XXXXXXXXXX la primera vez y será YYYYYYYYY la segunda vez. El atacante al ver YYYYYYYYY no se da cuenta de que la clave sí es "MiPassword" porque ve un cifrado diferente... El servidor descifra XXXXXXXXXX como "MiPassword+Sal1", le quita la sal y usa ese password para dejarle entrar. Y al que mire el tráfico cifrado no le sirve de nada.
(otro ejemplo de "sal" puede ser la fecha y hora exacta: 31/01/2014-22:30:15.23 )
" coger el text encriptado y a base de fuerza bruta encontrar algunas relaciones de g, de forma que cuando aparezca un texto encriptado concreto, saben cual es el texto en plano que se corresponde. "
Eso es lo que entendí yo que han hecho... pero si los que hacen las aplicaciones lo hacen bien no serviría de nada ese ataque.
En la jerga criptográfica se llama "sal" (salt) a unos datos añadidos que hacen que un mismo origen tenga diferentes resultados al cifrarlo. Por ejemplo, al cifrar "MiPassword" le añado "Sal1" la primera vez, "Sal2" la segunda vez, etc... de forma que tendríamos "MiPassword+Sal1" y "MiPassword+Sal2" ... y el resultado del cifrado será XXXXXXXXXX la primera vez y será YYYYYYYYY la segunda vez. El atacante al ver YYYYYYYYY no se da cuenta de que la clave sí es "MiPassword" porque ve un cifrado diferente... El servidor descifra XXXXXXXXXX como "MiPassword+Sal1", le quita la sal y usa ese password para dejarle entrar. Y al que mire el tráfico cifrado no le sirve de nada.
(otro ejemplo de "sal" puede ser la fecha y hora exacta: 31/01/2014-22:30:15.23 )
#5:
Que yo sepa:
- el http permite interceptar el tráfico desde siempre, sin importar lo que haga la NSA.
- Snowden ha desvelado que la NSA es capaz de vigilar el tráfico por https. Antes se pensaba que era seguro, aunque había dudas. Algo que basa su seguridad en que "todavía no está inventado un algoritmo de factorización asequible de primos" no es la panacea en cuanto a seguridad.
- el http permite interceptar el tráfico desde siempre, sin importar lo que haga la NSA.
- Snowden ha desvelado que la NSA es capaz de vigilar el tráfico por https. Antes se pensaba que era seguro, aunque había dudas. Algo que basa su seguridad en que "todavía no está inventado un algoritmo de factorización asequible de primos" no es la panacea en cuanto a seguridad.
#4:
Relacionada: Al RSA se le caduca el carné joven: el más común de los sistemas de cifrado ya no es tan seguro como antes
Del post:
'Lo que hemos mencionado con anterioridad demuestra que el protocolo no es seguro, pero también hay que advertir que no resulta sencillo poder realizar esto.'
Vamos, que no lo es al 100%... tampoco voy a perder el sueño por eso.
Del post:
'Lo que hemos mencionado con anterioridad demuestra que el protocolo no es seguro, pero también hay que advertir que no resulta sencillo poder realizar esto.'
Vamos, que no lo es al 100%... tampoco voy a perder el sueño por eso.
Comentarios
Aquí esta explicado algo mejor: http://arxiv.org/abs/1403.0297
Relacionada: Al RSA se le caduca el carné joven: el más común de los sistemas de cifrado ya no es tan seguro como antes
Al RSA se le caduca el carné joven: el más común d...
hojaderouter.comDel post:
'Lo que hemos mencionado con anterioridad demuestra que el protocolo no es seguro, pero también hay que advertir que no resulta sencillo poder realizar esto.'
Vamos, que no lo es al 100%... tampoco voy a perder el sueño por eso.
Que yo sepa:
- el http permite interceptar el tráfico desde siempre, sin importar lo que haga la NSA.
- Snowden ha desvelado que la NSA es capaz de vigilar el tráfico por https. Antes se pensaba que era seguro, aunque había dudas. Algo que basa su seguridad en que "todavía no está inventado un algoritmo de factorización asequible de primos" no es la panacea en cuanto a seguridad.
#5 Pero esta modalidad de ataque está relacionada con análisis de patrones de tráfico TCP y HTTP: paquetes, fragmentación; orden, frecuencia e interrelación de peticiones y respuestas (flujos); número y tamaño de los objetos de una página, etc. En ningún caso está relacionado con la "mística" criptográfica de TLS/SSL
De hecho, ya había pruebas de concepto de esto desde hace tiempo y algunos llevamos tiempo tratando con "apaños" que eluden el problema: tokens invisibles distribuidos aleatoriamente por la página, recursos externos (imágenes, CSS, javascript) desordenados -y falseados- en cada petición, etc. A eso hay que sumar ofuscación en el lado de cliente vía Javascript, cookies "mutantes", headers de relleno para hacer padding, peticiones falsas, etc. Había un paper de hace ya varios años que trataba todo esto esto.
No es nada nuevo, lo nuevo parece ser el grado de éxito y precisión conseguidos en esta investigación. Pero la alerta es anterior y ya deberían estar implementadas las contramedidas... deberían estar implementadas si no fuera porque la mitad de los fingenieros del mundo se dedican ahora a hacer inseguras apps para móviles y creen que Diffie-Hellman eran los padres putativos de Tom y Jerry.
"Se trata de una explicación bastante matemática que nosotros vamos a tratar de simplificar para que sea fácil de ver. Los investigadores han sacado en conclusión que se puede descubrir los datos cifrados que se envían haciendo uso de este protocolo mediante patrones de conocimiento. Esto quiere decir que durante un tiempo determinado, el cual deberá ser suficiente para poder generar una muestra amplia, un atacante puede descifrar los datos haciendo uso de estos y el patrón anteriormente construido.
Para realizar esto, se ayudan de una distribución matemática que les ayuda a construir un mapa, creando una relación entre el tráfico que es analizado y los elementos del patrón que se han construido.
Esto es posible siempre y cuando el atacante sea capaz de acceder a las mismas páginas del usuario y también ser capaz de capturar el tráfico web que el usuario genera, algo que sería fácil relativamente si nos encontramos en una red WiFi pública."
Es decir, que nos puede espiar el ISP y nos pueden espiar las agencias gubernamentales que tienen a los ISP bajo su jurisdicción.
Y aún así, lo que reconocen son patrones, que no es algo a extrañar. Por simplificar (mucho) si https encripta en tu ordenador lo que envías con cierta función f(texto plano) = texto encriptado, el servidor a su vez tendrá una función g(texto encriptado) = texto plano.
Lo que hace la NSA es coger el text encriptado y a base de fuerza bruta encontrar algunas relaciones de g, de forma que cuando aparezca un texto encriptado concreto, saben cual es el texto en plano que se corresponde.
No es bueno, pero como dice #10 tampoco es una novedad. Más me preocupa que obligó a Lavabit a darle sus certificados para tener ellos la clave directamente.
#14 Excepto que obvias un pequeño detalle que por suerte a #11 no se le ha escapado:
"Es decir, que nos puede espiar el ISP y nos pueden espiar las agencias gubernamentales que tienen a los ISP bajo su jurisdicción."
El problema aquí no es que te espíe tu vecino al que le gorroneas el Wi-Fi, es que te espía alguien que está más arriba en la cadena trófica.
#11
" coger el text encriptado y a base de fuerza bruta encontrar algunas relaciones de g, de forma que cuando aparezca un texto encriptado concreto, saben cual es el texto en plano que se corresponde. "
Eso es lo que entendí yo que han hecho... pero si los que hacen las aplicaciones lo hacen bien no serviría de nada ese ataque.
En la jerga criptográfica se llama "sal" (salt) a unos datos añadidos que hacen que un mismo origen tenga diferentes resultados al cifrarlo. Por ejemplo, al cifrar "MiPassword" le añado "Sal1" la primera vez, "Sal2" la segunda vez, etc... de forma que tendríamos "MiPassword+Sal1" y "MiPassword+Sal2" ... y el resultado del cifrado será XXXXXXXXXX la primera vez y será YYYYYYYYY la segunda vez. El atacante al ver YYYYYYYYY no se da cuenta de que la clave sí es "MiPassword" porque ve un cifrado diferente... El servidor descifra XXXXXXXXXX como "MiPassword+Sal1", le quita la sal y usa ese password para dejarle entrar. Y al que mire el tráfico cifrado no le sirve de nada.
(otro ejemplo de "sal" puede ser la fecha y hora exacta: 31/01/2014-22:30:15.23 )
#18 Y como ha sabido el servidor la regla que usas para descifrar la clave?
#22
El que hace la aplicación diseña el código: el del servidor y lo que ocurre en tu navegador con cosas como javascript... Por ejemplo, la regla puede ser que los Password no pueden usar el caracter "-" y todo lo que va después del "-" es la sal y se descarta. El servidor recibe XXXXXX, lo descifra y ve "MiPassword-2014031017393000"
Sabe que hasta el - es la contraseña = "MiPassword" y el resto es la sal, que lo podrá usar (por ejemplo, para saber que no es una fecha demasiado antigua... Si esa fecha no concuerda con otra cosa quizá por ahí también detecta que es fraude) o bien simplemente ignorarlo.
#23 el tema salt no es tan obvio siempre, ya que si lo haces tan obvio la NSA también lo verá a la que analice las trazas.
#29
No comprendo eso que dices.
#32 ya veo que lo he escrito fatal:
si quieres analizar el tráfico a n sitios, primero analizarás que tipo de cifrado y salt usan, y si es tan obvio como pasarlo en otra request, un timestamp, etc, pues apenas añades dificultad.
#33
A ver, el atacante analiza el tráfico entre mi IP y la IP de mi banco, por ejemplo. Ve cosas cifradas, cosas como aSSsSsSCDSSSAaac ¿cómo puede saber el tipo de sal que usa la aplicación del banco? El atacante se conecta también al mismo banco y cuando él se conecta ve djkcbnfifbasdilbihaldb es decir, otros datos cifrados diferentes.
Aunque la sal sea sencilla, basta que sea diferente para que el resultado de cifrar cambie completamente.
Es cierto que la sal que he mencionado es sencilla y quizá no de tanta dificultad como otras, sólo era un ejemplo, pero, aún así pareces decir que lo que dije es fácil de romper y no creo que sea así. Aparte de que todo esto esto es más complejo y más fuerte de lo que hemos hablado. Hay una clave simétrica, que es diferente para cada uno que se conecte y un cifrado asimétrico para intercambiar dicha clave y creo que todo eso está bien diseñado... No creo que fuese necesario hacer en cada aplicación lo que he comentado... seguramente ya lo hace el protocolo HTTPS.
#18 positivo sólo por esto: "(otro ejemplo de "sal" puede ser la fecha y hora exacta: 31/01/2014-22:30:15.23 )"
#10 esta investigación de "unos investigadores":
> tal y como han comprobado unos investigadores
> Los investigadores han sacado en conclusión que se puede descubrir los datos cifrados
> Sin embargo, los investigadores adelantan
http://mnmstatic.net/cache/06/5f/417609-1392311145-80.jpg
#13 Me alegra que aún seas capaz de hacer copypaste con los ojos arrancados. Serás digno objeto de alguna investigación.
#19 también hay ciegos que usan ordenadores y el texto lo manejan, lo complicado son las imágenes.
Creo que la calidad de la redacción es pésima y esa (insistente) forma de hablar de "unos investigadores" más.
Pero lo cierto es que te tengo que pedir disculpas porque ahora no sé por qué te he referenciado, me parece que me han bailado los números.
#5
'Algo que basa su seguridad en que "todavía no está inventado un algoritmo de factorización asequible de primos" no es la panacea en cuanto a seguridad.'
Lo de la dificultad de factorización es algo en lo que se basa RSA solamente y RSA no es lo que se usa para HTTPS.
Por otro lado, todo cifrado asimétrico se debe basar en la dificultad de algo... Estaría bien que se probase matemáticamente que dicha dificultad es completamente segura, es decir, no sólo que no se ha encontrado sino que sea imposible... cosa que creo que no se ha hecho pero no descartaría que quizá se demuestre algún día (salvo, quizá algoritmos cuánticos).
#16 los indicios dicen que sí, que existe el algoritmo para hacer de manera asequible la descomposición de un producto de dos primos gigantescos. O eso, o Snowden miente, o la NSA está exenta de cumplir ciertos teoremas matemáticos. Como dices, afecta a gran parte de los cifrados. ¿ Apostamos que a todos los populares y gratuitos ?
#17 sip, sorry, error de bulto. Gracias por el apunte.
#26
No se a qué indicios te refieres...
Lo que sabemos (Snowden y demás) es que la NSA espía, de ahí a que exista una forma muy eficiente de factorizar va un abismo muy grande.
Por ejemplo, una de las formas sencillas que usa la NSA es pedir a las empresas (Facebook, Google, etc) que les de ciertos datos o cierto acceso a sus bases de datos... Como ves, esto no tiene nada que ver en absoluto con debilidad de algoritmos.
Otra de las formas, muy cercana a lo que dices de "gran parte de los cifrados", "populares y gratuitos" ... tiene que ver con la forma de generar claves (los pares de números primos que se multiplican)... al parecer se descubrió que una empresa supuestamente controlada (o manipulada) por la NSA había hecho software muy usado y lo había hecho mal a propósito. Nuevamente, esto no tiene que ver con la debilidad de la factorización... concretamente sí tiene que ver con primos, pero no por un "algoritmo mágico" sino con una trampa, un timo.
Por último, comentar que sí existe una forma conocida de factorizar mucho más rápido: mediante computación cuántica. Lo que pasa es que no creo realmente que la capacidad de las computadoras cuánticas haya llegado a ser la necesaria: por lo que he visto, para claves RSA de 1024 bits se necesitarían unos 1538 qubits y lo máximo que sabemos que existe son computadores de 512 qubits (los de la empresa D-Wave) y, además, la publicidad es engañosa y ni siquiera es cuántico puro, así que dudo que estos sirviesen... Aparte, RSA no se usa mucho en los navegadores actuales, míralo, ya verás, se usan Curvas Elípticas de tipo Diffie Hellman, así que un algoritmo mágico para factorizar no creo que sirva mucho para descifrar la gran mayoría de HTTPS que usamos hoy.
#28 Me refiero a esto:
http://alt1040.com/2013/09/edward-snowden-nsa-gchq
Yo lo he dado por cierto. ¿ Quizá no debía ?
#30
Puede ser cierto, pero no asegura lo que tú dijiste en #26
Dice:
"crean vulnerabilidades secretas en los cifrados de estos servicios, lo que comúnmente se conoce como "puertas traseras", que podrán ser accedidas por la NSA o GCHQ"
Esto no significa que tengan un algoritmo mágico para factorizar. ¡¡Más bien confirma todo lo contrario!!
Con un algoritmo para factorizar tomarían la clave pública de la empresa, factorizan y tienen la clave privada. Con la privada ya pueden descifrar los datos que circulan... Por tanto, no necesitarían crear vulnerabilidades en ningún software ni puertas traseras ni nada de eso.
Nota: lo de crear puertas traseras lo podrá hacer la NSA si la empresa usa software propietario (ej: Windows, OSX, ... o servidores de aplicaciones o Bases de Datos, etc)
" La filtración que proviene de Snowden solo da a conocer que esto le permite a estos organismos el saltarse fácilmente protocolos como el HTTPS o SSL, que tantos consideramos como seguros."
Esto parece contradecir la frase que escribieron antes... o está muy mal expresado. Quizá sea sólo una frase desafortunada del que escribió el artículo, quizá quería decir que aunque HTTPS sea seguro, con la puerta trasera de la que hablaban antes acceden a la información cuando se descifra en el destino.
Y, aunque sea cierto que puedan descifrar cualquier conexión HTTPS eso no significa que tengan un algoritmo mágico para factorizar... Como comenté antes, puede ser que la clave pública generada por muchas empresas no sea tan aleatoria como promete el software que genera esas claves. O puede ser que la implementación de HTTPS/TLS/SSL de cierto software sea defectuosa a propósito.
#31 >
Sip, mi impresión ahora es la misma. De todas formas, el rumor de que quizá la nsa es capaz de descifrar todos estos cifrados viene de muy antiguo, desde que se pusieron bajo dominio público. No es algo que haya nacido a raíz de lo de Snowden ni en épocas recientes. No es que quiera desconfiar, es que me tira el escepticismo "científico". La geometría algebraica da muchas formas distintas de cifrar. Limitar los métodos a los basados en claves de productos de primos grandes parece reducirse mucho el campo.
#35
Tu escepticismo es bueno.
"La geometría algebraica da muchas formas distintas de cifrar. Limitar los métodos a los basados en claves de productos de primos grandes parece reducirse mucho el campo."
Ten en cuenta que no se limitan a los productos de primos grandes, que yo sepa eso sólo se usa en RSA y RSA apenas se usa hoy en día... Se usa más Curvas Elípticas de tipo Diffie Hellman, que no se si será el tipo de cosas a las que te refieres cuando hablas de geometría algebraica. Pero es lo que se usa... nadie se limita hoy en día a los productos de números primos sino al contrario, eso está desfasado y no se usa para casi nada.
#5 Sólo una mínima corrección: los primos no se pueden factorizar; es no poder factorizarlos lo que les hace primos. Más bien habría que decir "factorización EN números primos".
la nsa haciendo de las suyas, hace falta desarrollar nuevos protocolos más seguros, esto es una situación de ataque a los derechos inaguantable
Entonces, si abro una pagina de compra por Internet con HTTPS y doy mi tarjeta de crédito "estoy vendido" ¿no?
#1 solo si tu tarjeta es de gran interés para la nsa
#1 #3 si es para pagar mis atrasos, perfecto
#1 No, solo se puede "adivinar" las páginas web que visitas.
#6 Gracias. Me "había acojonado"
En OpenBSD para comprobar la integridar de los ficheros, usan SHA256 en vez de MD5.
"Esto es posible siempre y cuando el atacante sea capaz de acceder a las mismas páginas del usuario y también ser capaz de capturar el tráfico web que el usuario genera, algo que sería fácil relativamente si nos encontramos en una red WiFi pública."
Vamos, que el titular es sensacionalista. Si te conectas desde tu casa o usando tu movil como un punto de acceso no debería haber problemas.
El algoritmo lo diseñaron ellos, asi que que esperabais ??? jajaja, cuanto incauto.
#21 ¿¿ "ellos" ?? Quieres decir que los que diseñan protocolos seguros de forma totalmente abierta, criticable, y con código abierto, visibles por miles de expertos, etc... lo hacen con trampas que podrían ser descubiertas y nadie se dio cuenta????
¿Han aportado alguna prueba de concepto?