Portada
mis comunidades
otras secciones
#9:
La NSA no desactivó la criptografía en Internet. Simplemente existen muchos - demasiados - servidores inseguros, que no es lo mismo.
¿Nos protege la criptografía en Internet? La respuesta corta es si. La larga: lee y aprende por qué hay muchos servidores inseguros que no te protegen contra el espionaje de la NSA.
Interesante pero sensacionalista.
¿Nos protege la criptografía en Internet? La respuesta corta es si. La larga: lee y aprende por qué hay muchos servidores inseguros que no te protegen contra el espionaje de la NSA.
Interesante pero sensacionalista.
#3:
El caso es que aún queriendo permanecer al margen y proteger tu privacidad, cada vez es más difícil; y nuestros propios gobiernos (que no son los EE.UU., son todos en general) hacen que tengas que presentar formularios y declaraciones por internet, que los pagos no puedan ser en efectivo, que tengas que usar claves y sitios inseguros,... y lo que es peor, si alguien te espía, no recibe castigo alguno.
#8:
#2 Si, esperaba un articulo lleno de cagadas como la mayoría de artículos de divulgación que se leen sobre estos temas. Pero no, este consigue explicar las cosas de forma sencilla sin decir casi ninguna burrada.
La única burrada es cuando dice "aunque la base de los algoritmos RSA y DH son diferentes, muchos en la comunidad criptográfica siempre han creído que son matemáticamente similares en cuanto a fortaleza, de modo que si te cargas uno también puedes cargarte el otro".
Los ataques descritos no se cargan los ALGORITMOS sino las malas IMPLEMENTACIONES de dichos algoritmos, que no los siguen de forma apropiada. Los algoritmos en principio siguen siendo seguros si se ejecutan correctamente.
La única burrada es cuando dice "aunque la base de los algoritmos RSA y DH son diferentes, muchos en la comunidad criptográfica siempre han creído que son matemáticamente similares en cuanto a fortaleza, de modo que si te cargas uno también puedes cargarte el otro".
Los ataques descritos no se cargan los ALGORITMOS sino las malas IMPLEMENTACIONES de dichos algoritmos, que no los siguen de forma apropiada. Los algoritmos en principio siguen siendo seguros si se ejecutan correctamente.
#2:
Muy completito y básico a la vez (explicación de ese tipo de "man in the middle" por ej y en general todo el artículo: vulnerabilidades, números primos, lo de Apache..)
Lo que no se pueda desencriptar hoy fácilmente se had dentro de x tiempo (véase el ej de los 100 dólares de Amazon, pero con nuevos ordenadores más rápidos)
Favoriteo.
Lo que no se pueda desencriptar hoy fácilmente se had dentro de x tiempo (véase el ej de los 100 dólares de Amazon, pero con nuevos ordenadores más rápidos)
Favoriteo.
#4:
Es como los controles de seguridad de los aeropuertos, pero en remoto: arbitrarios, ilegales, nadie sabe realmente a que responden y anulan todos los derechos personales.
#23:
#9 Da un poco igual que los servidores sean seguros o no. Algo que la gente no entiende es la cantidad de autoridades certificadoras que hay en un equipo instaladas por defecto, sin que el usuario las escoja.
Cualquier autoridad certificadora de tu sistema puede validar cualquier servidor en cualquier momento, te fías completamente de ellas.
Para los liberales, diré que hay autoridades que dependen de entidades gubernamentales de distintos países. Para los comunistas que las hay que son empresas privadas, muchas de ellas multinacionales. ¿Antisemita? StarSSL está localizada en Israel y da certificados gratis. Puedes pillar a cualquiera.
Si la NSA u otras agencias similares quieren pincharte solo tienen que hablar con... la "Agencia Catalana de Certificacio" (acabo de mirar mi almacén y me ha hecho gracia que esté esa y no la española) y pedirle "por favor" que les emitan un certificado para gmail.com (más el trabajo técnico de desviar el tráfico hacia el servidor real, pero eso ya no es un problema criptográfico sino técnico).
Cualquier autoridad certificadora de tu sistema puede validar cualquier servidor en cualquier momento, te fías completamente de ellas.
Para los liberales, diré que hay autoridades que dependen de entidades gubernamentales de distintos países. Para los comunistas que las hay que son empresas privadas, muchas de ellas multinacionales. ¿Antisemita? StarSSL está localizada en Israel y da certificados gratis. Puedes pillar a cualquiera.
Si la NSA u otras agencias similares quieren pincharte solo tienen que hablar con... la "Agencia Catalana de Certificacio" (acabo de mirar mi almacén y me ha hecho gracia que esté esa y no la española) y pedirle "por favor" que les emitan un certificado para gmail.com (más el trabajo técnico de desviar el tráfico hacia el servidor real, pero eso ya no es un problema criptográfico sino técnico).
#5:
hace no mucho tuve una discusion con un usuario de aqui, el insistia en que el https era segurisimo, que si bla bla... yo le insistia que habia bugs conocidos y otros muchos que no conocemos, ademas de que los gobiernos controlan el trafico en la red, que es una falsa sensacion de seguridad. El creia estar seguro. En fin...
Comentarios
La NSA no desactivó la criptografía en Internet. Simplemente existen muchos - demasiados - servidores inseguros, que no es lo mismo.
¿Nos protege la criptografía en Internet? La respuesta corta es si. La larga: lee y aprende por qué hay muchos servidores inseguros que no te protegen contra el espionaje de la NSA.
Interesante pero sensacionalista.
#9 Da un poco igual que los servidores sean seguros o no. Algo que la gente no entiende es la cantidad de autoridades certificadoras que hay en un equipo instaladas por defecto, sin que el usuario las escoja.
Cualquier autoridad certificadora de tu sistema puede validar cualquier servidor en cualquier momento, te fías completamente de ellas.
Para los liberales, diré que hay autoridades que dependen de entidades gubernamentales de distintos países. Para los comunistas que las hay que son empresas privadas, muchas de ellas multinacionales. ¿Antisemita? StarSSL está localizada en Israel y da certificados gratis. Puedes pillar a cualquiera.
Si la NSA u otras agencias similares quieren pincharte solo tienen que hablar con... la "Agencia Catalana de Certificacio" (acabo de mirar mi almacén y me ha hecho gracia que esté esa y no la española) y pedirle "por favor" que les emitan un certificado para gmail.com (más el trabajo técnico de desviar el tráfico hacia el servidor real, pero eso ya no es un problema criptográfico sino técnico).
#23, te he votado positivo pero luego pensando no lo veo tan claro. Es fácil de hacer que desde el navegador salte alguna alarma o algún aviso en caso de que 2 entidades certificadores diferentes firmen una misma dirección de internet.
#25 ¿Cómo? El certificado que recibes te dice que está firmado por una ¿Contactas con todas las demás (unas cuantas) para verificar si tienen ese servidor autenticado y con qué certificado? ¿Mediante qué servicio compruebas eso si no tienes un certificado emitido por ellas? ¿Y si cambio de CA por lo que sea? ¿Entiendes como funciona la CA?
#36, explicación: para resolver el problema del que hablas bastaría simplemente con que el navegador guardase un índice con las direcciones https que se han visitado hasta el momento y con que entidad certificadora se ha certificado cada una. Si en algún momento esa entidad certificadora cambia (lo que ocurriría en la mayor parte de los ataques ), el navegador podría avisarte: "He, cuidado, esta dirección antes la certificaba y ahora lo hace ". Algo parecido ocurre con cuando haces conexiones ssh con los clientes, guardan las claves del servidor, y te avisan cuando estas cambian, es más, podría avisar cuando el servidor cambia de certificado.
#46 Osea, que no ves tan claro que HTTPS sea vulnerable desde las CA porque los navegadores y/o el protocolo HTTPS podrían idearse de otra manera... pues vale.
La cosa es ¿Se hace ahora? ¿No ves claro lo que he dicho? No he dicho nada de si se puede mejorar o no el sistema, he hablado de como funciona ahora y que consecuencias tiene ahora.
#49, solo estaba pensando en el alto, ignoro si esa medida de seguridad existe o no.
Ahora hilando más fino, despues de repensarlo mejor, creo que el problema del que hablas no solo sería fácilmente identificable, si no que es algo demasiado arriesgado para una entidad certificadora. En el momento en el que un navegador detectase que una misma dirección ha sido firmada por 2 entidades diferentes (cosa muy sencilla de hacer), sería suficiente como para que saltase alguna alarma (no necesariamente alarmas al usuario final), de forma que se detectaría fácilmente a una entidad que ha firmado a "gmail.com" cuando no debía, como tu explicas. Es decir, que una entidad certificadora firme a la NSA una dirección "x", es muy arriegado para ellos, ya que es algo fácil de detectar y algo muy fácil de demostrar (el certificado con la firma es una prueba irrefutable del hecho). La noticia sería suficientemente fuerte como para que no pasara desapertivida, esa entidad dejaría de ser confiable y muchas preguntas se le exigirían que respondiese ¿Quien y porqué le pidio a esa entidad la firma? (ya no se si con implicaciones legales o no).
El caso es que aún queriendo permanecer al margen y proteger tu privacidad, cada vez es más difícil; y nuestros propios gobiernos (que no son los EE.UU., son todos en general) hacen que tengas que presentar formularios y declaraciones por internet, que los pagos no puedan ser en efectivo, que tengas que usar claves y sitios inseguros,... y lo que es peor, si alguien te espía, no recibe castigo alguno.
Muy completito y básico a la vez (explicación de ese tipo de "man in the middle" por ej y en general todo el artículo: vulnerabilidades, números primos, lo de Apache..)
Lo que no se pueda desencriptar hoy fácilmente se had dentro de x tiempo (véase el ej de los 100 dólares de Amazon, pero con nuevos ordenadores más rápidos)
Favoriteo.
#2 Si, esperaba un articulo lleno de cagadas como la mayoría de artículos de divulgación que se leen sobre estos temas. Pero no, este consigue explicar las cosas de forma sencilla sin decir casi ninguna burrada.
La única burrada es cuando dice "aunque la base de los algoritmos RSA y DH son diferentes, muchos en la comunidad criptográfica siempre han creído que son matemáticamente similares en cuanto a fortaleza, de modo que si te cargas uno también puedes cargarte el otro".
Los ataques descritos no se cargan los ALGORITMOS sino las malas IMPLEMENTACIONES de dichos algoritmos, que no los siguen de forma apropiada. Los algoritmos en principio siguen siendo seguros si se ejecutan correctamente.
#8 Solo por ser pejigueras: Se trata de implementaciones correctas de protocolos con problemas de seguridad. El protocolo es standard. Es el protocolo en sí lo que permitía el ataque.
Los protocolos se someten a análisis de seguridad, al igual que los algoritmos. Lo que se deduce de esta vulnerabilidad, que ni mucho menos es la primera, es que el análisis de protocolos es un arte complicadillo.
Pasa lo mismo que para encontrar un error en un texto grande. Quién lo lee por primera vez encontrará cosas que quién lo ha leido muchas veces ya ni ve.
#8 Correcto, me falto la palabra divulgación. Creo que está bien explicado con algo más de lo habitual. También esto es mnm que, aunque pedimos calidad, sigue siendo un site generalista.
#20 para nada "pejigueas", matizas. Firmado un luserdeesos
Gracias a ambos por vuestras aportaciones (son de las que si las lees bien y te interesa el tema con las palabras clave que habéis escrito el que quiera encuentra )
#20 Jajaja, joder si que estas hilando fino
Habría que leerse el documento del protocolo para ver el detalle. En el caso de bajar de clave de 1024 a 512 si que es correcto según el protocolo... pero obviamente es un protocolo viejuno de cuando no se rompían tan fácil las claves de 512 y tienes razón que esa parte es culpa del protocolo desactualizado.
PERO la implementacion incorrecta en ambos casos viene cuando el servidor reutiliza claves. No puedo asegurarlo sin buscar documentación oficial, pero casi seguro que el protocolo especifica generar una clave por usuario. Eso requiere un cojon de CPU si tienes chorrocientos usuario simultáneos, así que para ahorrar pasta muchas empresas reutilizan claves, con lo cual simplifica mucho la labor del atacante.
Adicionalmente, parece que también esta mal la parte cliente, que acepta bajar de 1024 a 512 sabiendo que tu no has pedido eso:
-Cliente: Vamos a usar clave de 1024
-Servidor (tras ser atacado por el MITM): Toma, la clave de 512 que me has pedido.
-Cliente: OK, todo guay ---> ERROR!! Deberia decir "que mierda es esta, yo te pedi 1024).
Es mas complicado que esto ya que hay como 3-4 niveles de encriptacion durante el establecimiento de la conexión segura. La clave que se reutiliza incorrectamente NO es directamente la que se le manda a los usuarios. A cada usuario se le manda una... que a su vez ha sido generada con otra reutilizada, de ahí el problema.
Para mas info (ya no tan nivel divulgacion pero se entiende mas o menos):
http://robertheaton.com/2014/03/27/how-does-https-actually-work/
http://robertheaton.com/2015/04/06/the-ssl-freak-vulnerability/
#27 La idea de estas cosas es que alguien que puede interceptar la conexión y sustituir un mensaje por uno suyo, no tendrá la capacidad de impersonar a uno de los conversadores.
Sucede pero que los protocolos permiten cambios y repeticiones a realizar en caso de errores de comunicación, para recuperar la sesión cuando el interlocutor tiene problemas, o para adaptarse a velocidades menores, etc. El atacante usa eso de forma que metiendo un mensaje suyo por el medio consigue que el protocolo decida bajar el nivel de criptografía. El protocolo permite eso porque debe, pero falla en exigir un paso o un dato que solo uno de los conversadores puede hacer o saber. Es un error, y el atacante lo aprovecha.
Ese error está ahí, pues porque nadie había caido antes en eso.
Eso acaba en una nueva verión del protocolo con el error corregido. Llevamos ya un montón de versiones. A veces es muy sencillo el cambio. A veces es realmente complicado pues hay que mantener la compatibilidad com implementaciones anteriores y hay que hacer auténticas chapuzas, como usar un campo para lo que no estaba previsto.
Tanto RSA, como Diffie-Hellman son algoritmos de clave pública (cara) que se usan para establecer una clave simétrica (barata). La clave barata es nueva siempre, pero la clave pública es fija siempre. Mal iríamos si no. Un servidor genera una clave pública, obtiene (pagando) un certificado de una autoridad (o sea, Symantec), y usa esa clave firmada por esa autoridad hasta que expira. No se genera para cada conexión ¿qué seguridad habría en una clave no firmada?
#8 No es ninguna burrada. Lee bien el texto que tú mismo has entresacado.
El problema del logaritmo complejo (romper DH) se cree que es formalmente idéntico al de factorizar un entero grande (romper RSA). El ataque LOGJAM aplica este principio aprovechando una debilidad (mantener el mismo primo "p" en las implementaciones) que también aprovecha FREAK (se mantiene el mismo módulo N en las implementaciones).
Es decir, la puerta de atrás es la misma y por tanto, puesto que los algoritmos son similares en su estructura intrínseca, el ataque que te sirvió para uno también sirve para otro. Son dos elementos los que juegan: misma puerta trasera sí, pero también misma estructura de "resistencia" en el algoritmo.
Los algoritmos en principio siguen siendo seguros si se ejecutan correctamente.
Pero esta afirmación tuya no es desmentida por el texto que has señalado. Léelo bien, por favor, y verás que es así.
#52 Cuando alguien habla de puerta trasera en un algoritmo es que seguro que tiene experiencia en el tema. No se nota nada y no traspasa. A menéame va a venir un administrador de fincas a explicarnos el tema de la puerta trasera.
#52 Creo que no tienes claro lo que es una puerta trasera, pirata
Una back-door es una vulnerabilidad en un algoritmo o protocolo de criptografia, normalmente introducida a propósito con el fin de debilitar el algoritmo. Estos ataques de la noticia aprovechan cagadas y bugs varios, pero ninguna puerta trasera.
#66 Cierto. Donde digo "puerta trasera" léase "implementación defectuosa".
Es como los controles de seguridad de los aeropuertos, pero en remoto: arbitrarios, ilegales, nadie sabe realmente a que responden y anulan todos los derechos personales.
hace no mucho tuve una discusion con un usuario de aqui, el insistia en que el https era segurisimo, que si bla bla... yo le insistia que habia bugs conocidos y otros muchos que no conocemos, ademas de que los gobiernos controlan el trafico en la red, que es una falsa sensacion de seguridad. El creia estar seguro. En fin...
Añado a lo dicho en #5
kevin-mitnick-demuestra-como-hackear-fibra-optica-espiar/c051#c-51
Kevin Mitnick demuestra cómo hackear fibra óptica ...
malavida.comEstablecer un canal seguro con otra persona que la NSA no pueda leer es fácil: tengo un ordenador no conectado a internet
Como veis, hay gente que es tonta del culo y por mas que se lo intentaba hacer entender se pensaba que el problema era que te colasen backdoors y no entendia que la propia encriptacion no sirve de nada.
#7 Eso que sepamos. A dia de hoy la red tor es lo que te puede dar cierto anonimato, pero poco mas.
#6 Vaaaaale, ganas tú la discusión. Toma 100 internets
#6 No, si al final lo más seguro va a ser mandar un pendrive por correo postal
#6 La encriptacón sí que sirve, lo dice Snowden.
#5 En internet, con mucho sacrificio y esfuerzo, se puede ser realmente anónimo. Claro, que tienes que esforzarte por ello y además minimizar tu huella digital antes de ello.
#7 Y navegar a velocidad los 90, y por webs con tecnologías de los 90.
#11 Siempre puedes enviar un e-mail desde un servidor externo a un servicio tuyo descentralizado que lo parsee, mire qué página quieres ver y te devuelva los datos
#15 Pues probablemente de esta forma sí que se navega seguro 90%. Ahora, un coñazo total.
Y tampoco hace falta llegar a esos extremos de paranoia que tiene cierto personaje que ha hecho mucho por la libertad.
#15: Como manda Stallman.
Relacionada: http://menea.me/1hgiw
La parte positiva, no me pareció leer que esto sea debido a ningún ataque fácil a los algoritmos criptográficos. Todo son implementaciones erróneas, servidores mal usados, primos mal elegidos, protocolos defectuosos, etc. Pero el sistema de cifrado sigue siendo bueno, no está roto. A fin de cuentas un correo con GPG y una clave pública normal todavía no es vulnerable. Pues a mejorar las cosas. ¿Qué la mayor parte de la población le importa un bledo? Pues si... total lo van a contar todo en Facebook.
¿Nos protege la criptografía en Internet? Yo diría que la respuesta corta es SI.
Artículo muy interesante, pero muy alarmista. Habla de 2 problems de seguridad en las conexiones web SSL (con los servidores web tipo bancos, etc). Estos problemas de seguridad no son fácilmente explotables (se requieren conocimientos criptográficos y acceso a tu red interna para hacer un ataque Man In The Middle). Además, uno de ellos solo afectaría al 12% de los servidores (cada día que pasa disminuye), y otra del 7% de los servidores (también cada día que pasa disminuye, y solo afectaría a navegadores antiguos). Volver a aclarar que solo habla de conexiones SSL, es decir, habla de la criptografía que se usa de forma trasparente. Cualquiera que quiera podría usar la criptografía para protegerse en internet para comunicarse con otras persoas de forma segura sin que estos problems de seguridad le afecten.
#24 Para que el HTTPS sea seguro (aunque puedes decir mi red es segura entonces todo está bien y el HTTPS da igual) influyen tanto el navegador (y el humano que está detrás) como el servidor.
Si el navegador (o el almacén de certificados del sistema operativo) está desactualizado le puedes colar un certificado de una CA comprometida.
Si el servidor acepta downgrade a una versión antigua de SSL, la comunicación estará expuesta a ciertos ataques.
Relacionado:
El estado del SSL en Ayuntamientos Españoles
El estado del SSL en Ayuntamientos Españoles
securitybydefault.com#31, "LOGJAM es relativamente fácil de parchear (los navegadores de Internet más usados ya lo han parcheado), aunque depende de que también los servidores (las webs a las que accedemos) se lo tomen en serio y cierren la vulnerabilidad."
Yo con eso entiendo que solo pueden atacar a navegadores vulnerables, pero que es importante también que parcheen los servidores para que los navegadores antiguos no sean vulnerables.
#48 Bueno, es facil de parchear cuando el parche está disponible para que se lo baje quién quiera. Sí, esa parte es facil.
#24 El articulo se centra en la NSA (lo pone en el titulo y todo). Para ellos si son problemas fácilmente explotables.
#33 , igual tienes razón, y he respondido a la entradilla, la cual empieza con la frase: "¿Nos protege la criptografía en Internet? La respuesta corta es no. "
#24 No te rias tanto del MITM, que es muy sencillo tener el control de la red.
por ejemplo
- Si te conectas desde el trabajo, el proxy del trabajo puede hacer MITM. Algunas empresas lo hacen. Yo siempre compruebo el certificado, siempre. Cada vez, cada conexión.
- Si usas TOR, el nodo de salida puede montar un MITM ahí mismo.
- eMule, bueno, eso ya es de risa. Es sistemático.
#61, no me río, es un ataque poderoso y sencillo técnicamente de hacer, solo hago énfasis en que para realizarlo se necesita acceso a la red interna a la que pertenece el atacante (con alguna excepción).
#64 En el caso de la NSA tienen la cooperación de la inmensa mayoría de ISPs, incluyendo todos los grandes de EEUU (AT&T, Verizon, Sprint...). No necesitas controlar la red interna si los ISPs te dejan instalar tus cajas negras en sus centrales.
ligera variacion del clasico atemporal de "te espio y si no te gusta es que tienes algo que ocultar"
El mayor problema que tiene la criptografía es que una de las entidades que generalmente crea los algoritmos/protocolos, es decir el NIST o Instituto Nacional de Estándares y Tecnología de EE.UU, ha permitido a la NSA dar una serie de ideas que en realidad hacían limitar dichos algoritmos/protocolos y/o hacerlos más débiles.
El NIST prepara nuevos algoritmos para el 2.016 y la NSA tendría un acceso mucho más limitado, al parecer.
En todo caso otro de los grandes problemas es que aunque existan protocolos y algoritmos más o menos seguros. Muchas páginas siguen sin implementarlos, por ejemplo aquí en España es un desastre, cientos de páginas siguen usando SSL3, RC4, SHA-1
Otro problema es el tema de la emisión de certificados falsos o que se le cuelen chicos malos a las entidades de certificación.
Esto lo digo como opinión, que mis conocimientos en criptografía son muy limitados.
Salu2
#38 NIST no crea algoritmos, que yo sepa. Organiza concursos. Por ejemplo AES fué hecho en Europa.
dar una serie de ideas que en realidad hacían limitar dichos algoritmos/protocolos y/o hacerlos más débiles.
No me consta. El caso de DES es bien conocido. el acortamiento de la clave que se hizo fué convenciendo a los autores (creo que fué IBM) de que tenía sentido. Cuando al final se descubrió el pastel, resultó que la NSA no había dicho nunca nada que no fuera cierto.
#58 Sí que desarrollan protocolos y algoritmos de seguridad:
http://www.nist.gov/itl/biometrics/biometrics-050212.cfm
Es más tienen hasta laboratorios propios.
Y lo de la NSA es bastante conocido:
http://www.microsiervos.com/archivo/seguridad/puertas-traseras-nsa.html
Salu2
Pero alguien se cree que van a pillar a algun terrorista de verdad por sus mensajes en la red?
.
Se me ocurren infinitas maneras de encriptar mensajes y no solo a traves de un ordenador. Los unicos terroristas que pillaran son los chiflados que se hacen cuentas en facebook
Yo creo que ya me resigno a que me espíe la NSA. Me conformo con que no me espíe cualquier pringao o delincuente común.
Queremos que espíen a Donald Trump, tiene pinta de terrorista financiero.
Tiene pinta de ser un troll peligrosisimo, y no parece que trame nada bueno.
¿Habeis pillado fotos de su hija?
Snowden informa de que los empleados de la NSA interceptan y comparten fotos privadas de desnudos [ING]
Snowden informa de que los empleados de la NSA int...
engadget.comDespues a estas familias (fijo que son terroristas)
La democracia de Estados Unidos, en manos de 158 familias
http://www.elmundo.es/internacional/2015/10/15/561e8e1c22601de9768b458f.html
Just 158 families have provided nearly half of the early money for efforts to capture the White House
http://www.nytimes.com/interactive/2015/10/11/us/politics/2016-presidential-election-super-pac-donors.html
Son mas peligrosas que el ISIS y seguro que se reúnen con familias como las de Bin Laden para conspirar.
Más de medio centenar de muertos por la caída de una grúa en la Gran Mezquita de La Meca/c125#c-125
Y a tope a los bancos y sociedades en Caiman y en Delaware.
El terrorismo está allí a tope concentrado.
Se dice que parte del dinero del ISIS pasa por la red tor que tienen montada allí.
Despues tenemos a estos sospechosos de hacer opaco el terrorismo.
Jonathan James Low, Rudy Valner, Fasana, David Dennis Cuby, Paul Louis Saurel, ...
Pero como ellos hay miles, igual decenas o cientos de miles,
¿Cómo el dinero del "robo del siglo" acabó en un humilde apartamento en Escocia?/c5#c-5
La banca británica y Santander UK necesitan "miles de millones"/c13#c-13
Perfiladlos al detalle pero ya.
Vigilados: desde la radio hasta el porno, espías británicos rastrean online las identidades de los usuarios [ENG]
Vigilados: desde la radio hasta el porno, espías b...
theintercept.comSe agrupa, se perfila, se estudia y se saca la lista de los mas peligrosos, y a Guantanamo hasta que confiesen donde han metido el dinero del isis, el al qaeda y el de anonymous.
#28 Nos vigilan a todos, excepto a la casta y a sus jefes, y es entre ellos entre los que están los mas peligrosos.
Tipos como Thomas Brian Reynolds http://m.imdb.com/title/tt0120660/fullcredits/cast?ref_=m_tt_cl_sc
O Patrice Saint-Clair
http://takenfilm.wikia.com/wiki/Patrice_Saint-ClairClair
Es un chorrada porque la agencia funcionará igual que aquí hacienda, en cuanto pillan algo de la casta, se impide su investigación y sube a los circulos clientelares en los que se protegen entre ellos. Al amigo y ensobrador del congresista no se le espia por muchos trapicheos que haga.
Para qué quereis la criptografía? Acaso quereis que ganen los terroristas? No teneis nada que ocultar si sois legales
#19 Eso dijo Snowden a EEUU
yo mando esteanogramas por zmodem que es de tiempos del bbs, tan obsoleto que ni lo espian
Clinton le contestó a una periodista cuando esta le hizo no recuerdo que pregunta que "dentro del gobierno existe otro gobierno que yo no controlo". En un rapto de sinceridad reconoció que él debía el cargo a la accion de otro poder que él no controla. Son los amos del mundo, una kábala de 40 individuos que se ha apoderado de los grandes centros de decisión. Todas las grandes agencias de espionaje están controladas por ellos, ni Obama se escapa del espionaje, por eso cuando la Merkel descubrio que EEUU vigilaba su móvil no la montó sabía que no era debido a Obama sino a los "amos" (a sus amos porque ella tambien está controladas por los que dirigen el poder del dinero del verdadero poder). La NSA es una agencia de cobertura, pero tambien la CIA, el Mosad, aparte de sus jefes "ordinarios" tienen otros "altos jefes" que tiran de la cuerda y a los que prestan obediencia. Si no lo hacen los jefes respectivos y hasta sus gobiernos pueden caer por el poder político que tiene el poder del dinero.
Si no se reconoce este contexto "mundialista" no se entiende el extraño juego que se llevan y los silencios de los agraviados que en otro tiempo era para montar una guerra al menos fria. Y de ese control no se escapa nadie, ni meneame cuando es útil a los nuevos dioses.
#34 ¿quienes son? Yo prefiero los iluminati a los reptilianos.
#59 Tal vez sean los roboti los que están tras todos esos nombres.
#63: La robomafia, hombre. Eso lo sabe hasta Calculón.
#37 Es un anglicismo incorrecto en castellano, lo se. Pero en IT se usa constantemente. Que te resulte raro ya dice mucho.
#39 Es mucho más sencillo explicar que hay una vulnerabilidad en el intercambio de claves TLS entre "cualquier servidor" y el navegador. Y que permite que la clave intercambiada sea "solo" de 512 bits, lo que la hace susceptible de ser vulnerada.
El algoritmo sigue siendo seguro. Vulnerabilidades del intercambio de claves se solucionan en un pis-pas y son debidas a configuraciones por defecto al establecer el nivel de seguridad para la clave, en este caso el de exportación de criptografía de EE.UU.
No tiene nada que ver con la seguridad del algoritmo.
#40 (fijate de que forma tan sutil he utilizado el termino castellano "intercambio" en vez de handshake o key exchange. Parece cómo que no sé lo que es el acknowledge en un canal seguro, pero todo el mundo lo entiende)
en internet no debe de haber privacidad, e internet se presta a eso pues es su naturaleza, todo lo que hay en internet es de todos
punto pelota
#44 Eso es una idiotez, pero seguro que hasta tú lo sabes.
Salu2
#53 internet es el primer sitio donde la Humanidad no tiene propiedad privada, una autentica utopia y que no cambie, que no nos lo quiten
A medida que voy leyendo el artículo, menos lo entiendo.
El intermediario intercepta esa petición y la sustituye por otra que diga “hola señor banco, soy yo, quiero una conexión de 512 bits.
Un MITM attack ve los datos en forma clara. No necesita alterar el tipo de conexión para nada. ¿qué he entendido mal?
aunque se supone que cada conexión tiene una clave RSA en teoría, lo que hacen los servidores en la práctica es generar una sola clave RSA y usarla para todos los clientes.
Y hacen bien. Cada nodo tiene una clave privada y su correspondiente clave pública. Una. La idea de las claves es que pueden ser reutilizadas tanto como se quiera sin perjuicio de la seguridad. ¿no?
aunque la base de los algoritmos RSA y DH son diferentes, muchos en la comunidad criptográfica siempre han creído que son matemáticamente similares en cuanto a fortaleza, de modo que si te cargas uno también puedes cargarte el otro. Por supuesto, hay que demostrarlo, y eso es lo que hizo otro equipo de investigadores en mayo de 2015. El nuevo ataque, llamado LOGJAM, hace con el sistema DH lo que FREAK hacía con el RSA.
Nada que ver ¿no? Ambos ataques son contra el protocolo, no contra el algoritmo criptográfico. Entonces comparar la fortaeza de los algoritmos para explicar estos ataques es, es... ¿me he vuelto tonto?
la mayoría de los servicios de Internet usan un número muy limitado de primos p, y los reutilizan una y otra vez.
Diffie-Hellman consiste en acordar una clave secreta usando un canal público, donde el primer paso es acordar p, en claro.
La seguridad de Diffie-Hellman no se basa en el secreto de p (ni g), de hecho el análisis de seguridad parte de la base de que es público. ¿qué hay de malo en reutilizarlo?.
#17 Hay dos tipos de MITM. El clásico es el tuyo, este es una versión que tiene pinta de ser mas fácil de realizar a gran escala.
El MITM clásico es que durante TODA la comunicación hay un tío en medio y, como tu dices, lo ve todo en claro. Pero en este ataque el MITM solo esta durante el intercambio de claves. Y luego se quita de en medio pero puede POSTERIORMENTE y tras sus 4h de calculos, desencriptar todo lo intercambiado (ha ido guardando todos los mensajes encriptados intercambiados por ambas partes) porque ha obtenido las claves.
El ataque FREAK consiste en obtener la clave simétrica secreta forzando a cliente y servidor a usar claves asimétricas de intercambio mas débiles. Y esa es la que rompes. O eso entiendo yo, que este tampoco es mi campo y hace ya muchos años que estudie estas cosas
#29 ¿Un man in the middle que lo ve todo "claro"? ¿Qué entiendes tú por claro? O sea, si yo mando mi mensajito cifrado el señor in the middle lo ve sin cifrar automágicamente, ¿no?
/cc #17
#45 El MITM clasico es:
1)Cliente envía petición al servidor
2)El "man in the middle" (literalmente "el hombre que esta en medio") suplanta al servidor, y a su vez reenvía la petición al servidor de verdad suplantandote a ti.
El resultado es que tu has establecido conexión segura con el MITM, y él a su vez con el servidor. Por ese motivo lo ve todo "en claro" (sin cifrar) pero ni tu ni el servidor real os enteráis de nada. Estos ataques ocurren cuando confías en un certificado sin firma correcta, o cuando alguien se hace con un certificado correcto de forma fraudulenta, o cuando una de las entidades certificadoras (CAS) la caga y le otorga un certificado correcto a quien no debe. Si googleas hay al menos un par gordas de estas cada año (mas todas las que no lleguen a hacerse publicas).
#45 No sabes como funciona, pero es muy sencillo. A y B quieren hablar, X se pone enmedio. A manda un mensaje a B para establecer la encriptación, X se hace pasar por B, así que A cree que está hablando con B, pero habla con X. X lo lee todo (en claro), pues porque están hablando con él ¿no?. Con B pasa lo mismo mismito.
A X B
Esto, que parece que se podría hacer siempre, es lo que evitan los certificados firmados por alguien en quién confían tanto A como B. También se puede detectar si A y B poseen un secreto en común.
Hay cosas que son sencillamente ridículas en ese artículo y demuestran un enorme desconocimiento. Como, por ejemplo, que alerten sobre que los servidores Apache solo utilizan un número primo ¿Pero de qué wtf están hablando? La fortaleza de los algoritmos reside en la factorización de enteros, no en la utilización de un único número primo.
Cada certificado HTTPS que reside en un servidor es distinto y están emitidos por una autoridad de certificación diferente. No sé exactamente que quieren decir con que Apache "solo usa un número primo", supongo que se refieren a que el servidor Apache está firmado mediante un certificado criptográfico, el propio de la fundación Apache, para garantizar la integridad del código, como cualquier otro programa.
Vamos, que tienen un popurrí mental que da verguenza ajena.
#22 A mu bajo nivel, en muchos algoritmos las claves se generan multiplicando números primos gigantescos. Eso te da un entero que es jodidamente difícil de factorizar porque solo es divisible por primos gigantes (y por 1, claro). Simplificando MUCHO puedes decir que las claves se generan a partir de números primos. Reutilizar la clave es a fin de cuentas reutilizar esos primos. Por ahí van los tiros. A favor del articulo decir que como te pongas a explicar SSL de arriba a abajo necesitas 40h mínimo. Yo he leído artículos mucho peores que este, que es bastante decente a nivel divulgación.
#32 ¿Bajo nivel? Voy a sacar la mano a ver si cae algún tiro en este planeta...
No entiendo cómo funciona el FREAK, si hay un man in the middle y tu estableces una connexión cifrada con él, éste ya dispone de la clave para descifrar tus datos porque se los estás enviando a él y tu pc piensa que él es el banco. Entonces, para qué quiere el atacante establecer una conexión menos segura con el banco de verdad? qué más le da? así solo va a llamar la atención.
#51 Lo dices bien ¿para qué? Sería hasta peor, arriesgandose a que le descubran y tal. La definición de gilipollas.
Respuesta larga:
Pues porque no se trata de un MITM de verdad. El del medio no puede interponerse y descifrar haciéndose pasar por quién no es. Lo que hace es colar un mensaje suyo en medio de la conversación, consiguiendo ejecutar una parte del protocolo que tiene un fallo que le permite rebajar la complejidad de la encriptación hasta donde sí es capaz de atacarla.
Respuesta corta: No es MITM