Portada
mis comunidades
otras secciones
#6:
#3 El parche se publica (curiosamente) en el ciclo de actualizaciones programadas de Microsoft; el día 12 de la semana pasada, segundo marte de mes. https://technet.microsoft.com/library/security/MS15-055 ¡Qué casualidad!
Entonces veo algo curioso, en la página de los investigadores que prueba el bug en tu navegador: https://weakdh.org/ "This study was performed by computer scientists at Inria Nancy-Grand Est, Inria Paris-Rocquencourt, Microsoft Research, Johns Hopkins University, University of Michigan, and the University of Pennsylvania". Cualquiera diría que juegan con ventaja.
Entonces veo algo curioso, en la página de los investigadores que prueba el bug en tu navegador: https://weakdh.org/ "This study was performed by computer scientists at Inria Nancy-Grand Est, Inria Paris-Rocquencourt, Microsoft Research, Johns Hopkins University, University of Michigan, and the University of Pennsylvania". Cualquiera diría que juegan con ventaja.
#4:
Logjam nos muestra una vez más porqué es una idea terrible debilitar la criptografía de manera intencionada, justamente lo que el FBI y algunas agencias de seguridad quieren hacer ahora. Eso es exactamente lo que EE.UU. hizo durante los 90, con restricciones a la exportación de claves y ahora tenemos esa puerta trasera abierta de par en par, amenazando la seguridad de gran parte de la web.
Algo completamente de esperar en mi experiencia laboral que llevo viendo en productos como los servidores de aplicaciones de IBM Websphere y otros, que para poder encriptar por https vienen con las librerías de java "limitadas" para que no se puedan usar certificados digitales con una encriptación suficientemente fuerte.
Al final si estás fuera de EEUU te puedes bajar las "java jce unrestricted policy files" para poder usar este tipo de certificados que en EEUU están prohibidos, pero la puerta trasera abierta está ahí si no lo haces y además muchos servidores utilizados están en EEUU usando certificados para la encriptación del https que son de risa
Algo completamente de esperar en mi experiencia laboral que llevo viendo en productos como los servidores de aplicaciones de IBM Websphere y otros, que para poder encriptar por https vienen con las librerías de java "limitadas" para que no se puedan usar certificados digitales con una encriptación suficientemente fuerte.
Al final si estás fuera de EEUU te puedes bajar las "java jce unrestricted policy files" para poder usar este tipo de certificados que en EEUU están prohibidos, pero la puerta trasera abierta está ahí si no lo haces y además muchos servidores utilizados están en EEUU usando certificados para la encriptación del https que son de risa
#27:
Cabecera:
Expertos en seguridad han encontrado un fallo en el algoritmo de cifrado Diffie-Hellman
En la noticia:
Sin embargo, parece que hay varios problemas con cómo se ha implementado el Diffie-Helman
Ya me extrañaba a mí que a estas alturas encontraran un fallo de diseño en el Diffie-Hellman...
Expertos en seguridad han encontrado un fallo en el algoritmo de cifrado Diffie-Hellman
En la noticia:
Sin embargo, parece que hay varios problemas con cómo se ha implementado el Diffie-Helman
Ya me extrañaba a mí que a estas alturas encontraran un fallo de diseño en el Diffie-Hellman...
#3:
"Microsoft ya ha lanzado un parche para Internet Explorer y se espera que lo mismo ocurra con Chrome, Firefox"
Los errores en el software libre se resuelven antes por la comunidad bla bla bla
Los errores en el software libre se resuelven antes por la comunidad bla bla bla
Comentarios
#7 No, si no digo que no inviertan, lo que digo es que es normal que saquen antes el parche.
Logjam nos muestra una vez más porqué es una idea terrible debilitar la criptografía de manera intencionada, justamente lo que el FBI y algunas agencias de seguridad quieren hacer ahora. Eso es exactamente lo que EE.UU. hizo durante los 90, con restricciones a la exportación de claves y ahora tenemos esa puerta trasera abierta de par en par, amenazando la seguridad de gran parte de la web.
Algo completamente de esperar en mi experiencia laboral que llevo viendo en productos como los servidores de aplicaciones de IBM Websphere y otros, que para poder encriptar por https vienen con las librerías de java "limitadas" para que no se puedan usar certificados digitales con una encriptación suficientemente fuerte.
Al final si estás fuera de EEUU te puedes bajar las "java jce unrestricted policy files" para poder usar este tipo de certificados que en EEUU están prohibidos, pero la puerta trasera abierta está ahí si no lo haces y además muchos servidores utilizados están en EEUU usando certificados para la encriptación del https que son de risa
No tengo miedo, todos mis datos son letrados.
#1
#1 lo he pillado una vez he salido de la noticia y me he puesto a hacer otras cosas jajajajj
#1 Jajajajajajajaja Muy bueno.
#1 Aún así es mejor si los encriptas... y pones una losa bien grande encima
#1 Letras: 1 Ciencias: 0
"Microsoft ya ha lanzado un parche para Internet Explorer y se espera que lo mismo ocurra con Chrome, Firefox"
Los errores en el software libre se resuelven antes por la comunidad bla bla bla
#3 Eso de excluir a Safari en la lista...
por no decir que IE no se mejora entre versión y versión, solo sacan parches de seguridad. Normal que tengan a sus equipos más "libres" de carga.
#5 Es normal que excluyan a Safari, están hablando de navegadores...
#3 El parche se publica (curiosamente) en el ciclo de actualizaciones programadas de Microsoft; el día 12 de la semana pasada, segundo marte de mes. https://technet.microsoft.com/library/security/MS15-055 ¡Qué casualidad!
Entonces veo algo curioso, en la página de los investigadores que prueba el bug en tu navegador: https://weakdh.org/ "This study was performed by computer scientists at Inria Nancy-Grand Est, Inria Paris-Rocquencourt, Microsoft Research, Johns Hopkins University, University of Michigan, and the University of Pennsylvania". Cualquiera diría que juegan con ventaja.
#6 Pues no, yo diría que si Microsoft ha patrocinado la investigación, es que invierte en seguridad
#12 Si, resentido, gordo, sucio, sin sexo, devorador de pizza y con la cara llena de granos que me estallo contra la pantalla. Anda, goto #7 , don rey del destape.
#14 ¿A qué va a ir allí? A empezar otra vez la argumentación totalmente lógica y loable que habéis tenido hasta tu último comentario? :
Tu insinuas que no es cierto que los errores en el SL se solucionen con anterioridad
Él comenta que en este caso, si tenían un poco de ventaja, pues había gente de MS estudiando el fallo
Tu comentas que MS invierte en seguridad
Él te da la razón
Tu lo envías a un punto anterior de la conversación
¿¿Por qué??
#18 Es lo que tiene el sistema de comentarios anidados de Menéame: 14 responde a 12, pero enlaza a 7, por lo que, como 7 es menor que 12, Menéame le anida en 7 en vez de en 12 que es done 14 quería responder... y si ahora llego a poner enlaces a cada uno de los comentarios que acabo de citar, imagínate el lío
#14 eso lo has dicho tu solito, estoy metido en el mundo de la informática y se de sobra que no por ser programador o similar ya tienes que encasquetarte en ese perfil que tu solo te has sacado de la manga.
Y por cierto, Microsoft invierte en seguridad porque queda bien y es su obligación, constantemente tiene que sacar parches para sus S.O., como para no invertir en seguridad... Entonces nos iría Windows a pedales día si día también.
#43 Si estás "metido en el mundo de la informática" tienes que saber de sobra que todos los fabricantes de software sacan parches para sus sistemas casi "constantemente". Anda que no me he tirado rato actualizando paquetes en Ubuntu, Reh Hat.. Que un fabricante actualice es no solo bueno, sino deseable. Y no solo es para corregir, también para añadir nuevas funcionalidades.
En cuanto a la velocidad.. A mi me va estupendamente W7 en un pc con casi 10 años, un core duo. Ahora mismo estoy probando la beta de Visual Studio 2015 en esta maquina. Y tambien tengo un IIS y un SQL 2014, entre otras cosas. A lo mejor es que como también eres de "el mundo de la informática", se te ha colado un virus, un rootkit o similar mientras consumías pr0n.
#45 estas asumiendo gratuitamente que demonice a microsoft, ni mucho menos; soy usuario de Windows 7 y después de XP para mi es el sistema que mejor ha ido de los que ha sacado. He instalado montones de Win7 en equipos de todos los colores, y hay que decir que va muy bien. Yo solo estoy criticando que se les ponga medallas por sacar parches, como si en el resto de S.O. no se hiciera y fuera algo excepcional de Microsoft. De la parte final de tu comentario, sin comentarios...
#6 y #7 A ver, esto que dices de que curiosamente se publica después de que haya salido el parche, etc. Es lo que ocurre casi siempre. Es parte de lo que se llama o conoce por Responsible Disclosure. Lo normal es que los que buscan vulnerabilidades contacten con las empresas implicadas e incluso pacten con ellos una fecha e incluso ayuden un poco a orientar el arreglo y demás. Y esto ocurre aunque no haya patrocinios ni la investigación haya sido pagada o hecha por la empresa ni nada. Otra cosa es cuando la empresa de turno pasa del tema y demás, pero vamos, ese margen se da la mayoría de veces. Después de eso el que ha descubierto la vulnerabilidad publica el tema, se lleva la gloria y el dinero, etc. No veáis conspiraciones donde no las hay.
#31 ¿Responsible Disclosure es sacar el parche y dejar a los otros navegadores en bragas? ¿Crees que el resto ha pasado olímpicamente? Y no, no es lo que pasa casi siempre, generalmente Microsoft tarda más en sacar los parches (normal) pues salen una vez al mes, concretamente el segundo martes de cada mes, y solo cambian esa política en algunos 0 day, mientras el resto de navegadores pueden sacar su parche a los pocos días y por eso este caso canta como una almeja. El debate va de quién ha tenido la ventaja para sacar antes el parche porque un usuario ha utilizado esta "prueba empírica" para atacar al software libre.
#36 Generalmente se esperan semanas, y sí, eso incluye esperar al segundo martes de mes de microsoft más de una vez. Cada persona que encuentra vulnerabilidades es un mundo, pero sí, así es. Me toca de bastante cerca y esto es lo que hay. ¿ Que pueda haber alguno que no lo haga ? Sí, pero lo que aveces pasa es que se habla con las empresas y o tardan demasiado o pasan directamente.
#31 Yo ya tengo mi gorro de papel de aluminio en la cabeza, no sea que Steve Ballmer se toque mientras escucha mis pensamientos..
cc/ #6
#46 Deberías aprender a aceptar que otro tiene la razón, no hablo de conspiranoias, tú te has jactado de que el software propietario da respuesta antes y yo te he demostrado que fácilmente puede ser porque estaban trabajando directamente en el error, hasta aquí todo normal, pero esta respuesta te acaba de dejar en evidencia.
Me pregunto por qué en todas las entradas relacionadas con tecnología está el típico #3 (probable programador resentido) que viene a hablarnos de las maravillas del software privativo frente al libre con una ironía infumable... Y tan desmontable como que 3 comentarios más abajo #6 ya le ha destapado.
#12 estoy contigo, siempre sale el tema y en ocasiones acaba eclipsando el argumento inicial.
#13 Fanboys everywhere...
#19 vaya, ¿fanboy es ahora evidenciar que el software libre es tan bueno como el privativo? O que si esta vez Microsoft ha demostrado que puede buscar vulnerabilidades no quiere decir que ya el software privativo sea 100 veces mejor "porque mira como investigan"...
#44 No, es por tender a discusiones infinitas alejándose del tema original del meneo. PD: Soy bastante fanboy del SL, pero intento controlarme.
#3 Los parches de Microsoft, cuando se trata de solventar debilidades de la implementación de un algotitmo de cifrado
son una pura cuestión de fe.
El creyente la instala satisfecho, el ateo ni se plantea usar este sistema operativo, y el agnóstico es consciente de que nunca sabrá si están cerrando una puerta trasera o añadiendo otra nueva.
#3 No sé de dónde saca la gente que los errores en el software libre se resuelven antes. Se resuelven cuando se descubren, con los recursos de que se disponga, ni más ni menos. Lo bueno es que si es software libre podrás acceder a los cambios y comprobar tú mismo que efectivamente se han realizado, hacen bien su trabajo y no hay sorpresas raras, además de que se harán públicos con su consiguiente explicación detallada al respecto.
Cabecera:
Expertos en seguridad han encontrado un fallo en el algoritmo de cifrado Diffie-Hellman
En la noticia:
Sin embargo, parece que hay varios problemas con cómo se ha implementado el Diffie-Helman
Ya me extrañaba a mí que a estas alturas encontraran un fallo de diseño en el Diffie-Hellman...
Debo votar errónea. Dice: "en este caso se debe principalmente a un fallo en el protocolo TLS en sí". Pues no puede ser. Diffie-Hellman es un protocolo (no un algoritmo) de intercambio de claves. No depende para nada de TLS (ni de sus versiones antiguas).
El protocolo, tal y como sale en Wikipedia:
Alice and Bob agree to use a prime number p = 23 and base g = 5 (which is a primitive root modulo 23).
Alice chooses a secret integer a = 6, then sends Bob A = ga mod p
A = 56 mod 23 = 8
Bob chooses a secret integer b = 15, then sends Alice B = gb mod p
B = 515 mod 23 = 19
Alice computes s = Ba mod p
s = 196 mod 23 = 2
Bob computes s = Ab mod p
s = 815 mod 23 = 2
Alice and Bob now share a secret (the number 2).
Nada que ver pues.
#9 y así salen esponjosas las magdalenas?
#10 Solo si las amasas dando golpes con la cabeza (pero si suena hueco, no lo hagas, no vaya a romperse).
#9 no puede ser. Diffie-Hellman es un protocolo (no un algoritmo) de intercambio de claves. No depende para nada de TLS (ni de sus versiones antiguas).
Pues no. Es TLS el que depende (en la mayoría de sus implementaciones, otras emplean RSA) y el que incluye el Diffie-Hellman.
Debo votar errónea.
Sin acritud, pero ¿no te parece un poco presuntuoso votar errónea siendo evidente que no dominas el tema?
#11 Correcto, uno de los algoritmos especificados para una de las etapas de TLS es diffie-hellman, si este último tiene un fallo, el protocolo tiene un fallo. Es un poco confuso, pero creo que es así.
Ahora, si hacen una nueva versión del protocolo sin permitir dicho algoritmo, ya será otra cosa.
#11 #20 A ver si entendemos algo.
TLS dependerá de Diffie-Hellman, pero Diffie-Hellman (el protocolo) no tiene ningun fallo.
Esta es la parte básica. Memorizadla. Captadla. Interiorizadla.
Ahora volved a leer la notícia con más cuidado.
Ok. Ahora quizás podríais haber leido que el problema está en algunas de sus implementaciones.
SI vais más allá y os informais un poco más, vereis que ess problemas de implementación son debidos a la causa más típica y tópica en criptografía: La implementación fué hecha por gente que no sabe, pues esos problemas con las claves son conocidos desde hace muchos años.
Y si estais interesados en esto de la criptografía sería bueno leer algun libro. Actualmente se recomienda:
http://cacr.uwaterloo.ca/hac/
es de gratis
#25 TLS dependerá de Diffie-Hellman, pero Diffie-Hellman (el protocolo) no tiene ningun fallo.
Verás... Diffie-Hellman es un método de establecimiento de claves, asín, en abstracto, y la implementación que se hizo en varios sabores del TLS tiene un fallo. Obviamente si el motor de tu coche tiene un fallo mecánico es un fallo del motor de tu coche, no de los motores de combustión en general.
Está muy bien que hayas leído unos enlaces y ya te hayas dado cuenta de la tontería que dijiste en Diffie-Hellman es un protocolo (no un algoritmo) de intercambio de claves. No depende para nada de TLS (ni de sus versiones antiguas). Si te hace ilusión retorcerlo para hacer catarsis, pues muy bien, donde dijiste "digo" dices "leete este enlace que yo me acabo de enterar". Pero vamos, que me alegro de que hayas aprendido algo.
Hay que ser un poquito más humilde, hombre. Si te equivocas y te corrigen educadamente, pues aprendes y (ya sería la hostia) agradeces. Pero no vengas encima ahora de "os voy a dar unas clases"... Enga, un saludete
#42 Lo que dije es exacto. No sé donde está tu error de interpretación, pero no tengo ganas de buscarlo.
#50 No hace falta que lo busques, está aquí: es un protocolo (no un algoritmo)
#20 "si hacen una nueva versión del protocolo sin permitir dicho algoritmo"
O... podrían no usar todos la misma clave, que es por lo que rompiendo una sola clave puedes meterte en el 66% de VPNs, y no permitir claves "export-grade", que están capadas justo para poder romperlas fácilmente.
Vamos, dos cosas bastante obvias, pero que muchos pasan por alto y luego ponen el grito en el cielo.
#9 Sin saber mucho del tema, yo creo que alice no debería enviar fotos intimas a nadie. Ningún canal, ni protocolo, es totalmente seguro.
Dado que veo muchos comentarios un tanto desencaminados, os recomiendo que le echéis un ojo a:
- La fuente de la información (quienes publicaron el fallo): https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
- El paper técnico: https://weakdh.org/imperfect-forward-secrecy.pdf
- Los comentarios publicados por la gente del proyecto OpenSSL en relación al fallo publicado, y los cambios por venir en el proyecto: https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
Luego.. seguimos hablando de microsoft, de si TLS es o no vulnerable, de si el algoritmo tiene o no un fallo, y si es o no clave para que la explotación del fallos ea viable, la decisión de la administración Clinton en relación con el tamaño máximo de clave.
Señores, otros medios están titulando la noticia como "el fallo que la NSA podría haber estado usando para romper VPNs" (http://www.theregister.co.uk/2015/05/20/logjam_johns_hopkins_cryptoboffin_ids_next_branded_bug/)
#22 Sé de lo que hablo, aunque puede que no me haya explicado bien. El hecho de poder romper el protocolo de intercambio de claves diffie-hellman es uno de los métodos posibles para romper el cifrado TLS. Aunque tienes razón, la parte de la frase "ya tienen capacidad de romper el siguiente cifrado que va a sustituir a diffie-hellman." es incorrecta. Gracias por hacérmelo ver a pesar del tono con el que lo haces.
#22 Y por cierto, hablando de conspiranoias, de la web orignal: "The regime was established by the Clinton administration so the FBI and other agencies could break the encryption used by foreign entities."
#26 Parcialmente, aun hay paises a donde estan prohibidas de exportar.
"Logjam nos muestra una vez más porqué es una idea terrible debilitar la criptografía de manera intencionada, justamente lo que el FBI y algunas agencias de seguridad quieren hacer ahora. Por ello ahora tenemos esa puerta trasera abierta de par en par, amenazando la seguridad de gran parte de la web." Jajajja, este amigo vive en los mundos de yupi.
Vamos a ver, las restricciones a la exportación de criptografía compleja (entre otras tecnologías) por parte de los EEUU tiene la única finalidad de mantener la supremacía tecnológica especialmente en el terreno militar.
A EEUU la 'seguridad' de gran parte de la red se la trae floja, lo que les preocupa son sus sistemas críticos.
Estoy convencido que la NSA conocía dicha vulnerabilidad y, por supuesto, la utilizaba.
Si ahora ha salido, ha sido porque no han podido comprar a este grupo de investigadores, o bien porque ya tienen capacidad de romper el siguiente cifrado que va a sustituir a diffie-hellman.
Un tema muy interesante, os recomiendo que si os sorprende busquéis en google o me preguntéis.
#21 no se que puñetas estas diciendo, diffie-hellman no es un metodo de cifrado, es un algoritmo de intercambio de claves. Anda inventarte conspiranoias de cosas del las que entiendas mínimamente o leete los meneos que comentas
#22
#21 Las restricciones a la exportación de criptografía se eliminaron hace tantos años que ya me falla la memoria.