¿Y porqué no recortan en juicios estúpidos y supérfluos? ¿Que delito cometieron esas 22 personas?
Y incluso en el supuesto de que lo que han hecho fuera delito (que no debería serlo). ¿A caso no hay otras prioridades a juzgar como a los "mossos de mierda" que han torturado y mutilado a la gente?
#9: Yo a los mosssos de mierda ya les considero como terroristas, y sus atentados les conodeno como hago con los de la ETA.
#3: Si no tienen pruebas, no me extrañaría que se inventaran unas y destruyan todas las pruebas en contra.
Nos graban por todos lados, y luego no aparecen las imágenes donde se demuestra la inocencia, curiósamente las cámaras dejan de grabar en ese precíso instante. En cambio, cuando las víctimas son los mossos de mierda, hay vídeos desde varios ángulos.
NOTA: "mosssos de mierda" es mi grupo de música donde toco, no os vayáis a pensar que me refiero a otro tipo de gente.
#66 Gracias por la aclaración, me leí el ataque por encima y no sabia que usaban también un applet java.
Yo estoy por votar errónea. ¿Qué cojones tiene que ver java en el exploit BEAST? Este exploit aprovecha JavaScript (que nada tiene que ver con Java) para conseguir descrifar las connexiones SSL. Que pinta Java en todo esto?
java en el navegador (applets) se usa bastante en aplicaciones web profesionales y intranets... ¿por que? por que lamentablemente es la unica forma de acceder a los recursos del pc sin tener que pasar por activeX. Con flash puedes hacer alguna cosa (acceder a archivos locales, por ejemplo, pero de forma limitada), pero con java puedes hacer casi cualquier cosa si tienes un applet firmado o desactivas la medida de seguridad oportuna.
Por ejemplo: a ver como escaneas algo desde una web sin usar java ni activeX, sin requerir instalar nada extra en el cliente.
Y aun así con java es una pequeña tortura.
Si quitan la posibilidad de usar java en firefox, olvidaros de que se use firefox en todas las administraciones publicas, y en cientos de empresas.
por otra parte, estoy con #59, tenia entendido que el asunto lo hacian con javascript.
#59 Coincido contigo que la noticia es una mierda. En inglés, mejor: http://www.theregister.co.uk/2011/09/29/firefox_killing_java/
http://www.securitynewsdaily.com/web-browsers-beast-1193/
Beast inyecta javascript PERO usa el framework de Java para poder hacerlo.
Te iba a haber votado negativo pero se me fue el dedillo, Eso que te has llevado
cc #65
#74 #75 #77 Ah vale, veo que no es erronea, es que el ataque además de a traves de JS como ya han implementado, podría implementarse a traves de otras características que realicen peticiones al servidor https://bug665814.bugzilla.mozilla.org/attachment.cgi?id=540839, dicen:
"... Recall that the necessary condition of Mallory’s agent is the ability to send cookie-bearing requests to Bob’s
server, since Alice’s browser cookies are what Mallory is going after. The author of this papers then collected
a list of browser features and plugins that satisfy this condition. Surprisingly, there are a lot of them, including
but not limited to Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java
Applet URLConnection API, and Silverlight WebClient API..."
#77 Pues si están pensando en desactivar Java... En fin que parece que Opera tiene el fix que mejor va hasta ahora aunque aún rompe algunos sitios... pero la solución vendrá de usar otros protocolos o al menos otras versiones, el problema, que tienen que implementarlo los servicios.
#78 Todas esas son las técnicas usadas que permiten acceder a las cookies. No he leído el documento pero no pueden ser esas técnicas las que haya que desactivar...
Creo que deberíamos analizar ese documento... pero son las 12 y hay poco tiempo! .
P.D. Tampoco suficiente conocimiento para entender los tejemanejes del encriptado de transmisión de paquetes....
#82 Cada una de ella tiene sus forma de implementar la Same Origing Policy, de diferentes maneras pero se ataca lo mismo, no probablemente no se tenga que desactivar todo... pero habrá que ver, pero insisto, todo eso para seguir usando los protocolos que ya se sabe que se han roto... lo que hay que hacer es cambiar de protocolos o al menos de versión de los mismos.
#35 y para incrementar la libertad individual, la responsabilidad y la madurez de la sociedad frente al dogmatismo de un "sabio" sobre sus obedientes.
#54 Hacía siglos que no veía tanta bilis junta...
#33, #42 Que le den por culo a vuestra puta propiedad privada.
Propiedad de uso, sí. Propiedad para especular y vivir del cuento, que os jodan capullos, así de jodidos estamos. Basta ya de defender a muerte las asquerosa propiedad privada, si alguién no sabe administrar bien un recurso, que se joda y lo lleve otro.
Y entre construir pisos para su lucro personal o mantener un centro social para un barrio, que le den por culo al especulador que quiere vivir de pelotazos y de xupar la sanfre a la gente que realmente curra y luego le toca dar más de la mitad de su sueldo pa tener un techo dónde vivir.
okupa y resiste!
#9 Como dice el artículo, este ataque se basa en la inyección mediante javascript de texto conocido y especialmente preparado dentro de la conversación ssl, para más disfrute aún, en los primeros bytes de una nueva petición.
Así pues, mientras las aplicaciones que se usen no esten comprometidas (el escenario planteado para el ataque es bajo un man in the middle y con código inyectado), SSL3.0/TLS1.0 sigue siendo perfectamente válido. És un ataque a https, no a todo el protocolo.
Tal como comentaban en hacker news, los navegadores más nuevos que soportan TLS1.1 o 1.2 no se ven afectados, así como cualquier otra aplicación en la cuál la inyección de código no sea tan trivial como añadir texto plano extra a una petición de la víctima.
P.D: Cuesta creer que casi todos los comentarios sean de talibanes lingüísticos. ¿Por que no creáis vuestros flames en notícias de léxico y ortografía y dejais el resto tranquilas?
P.D.2: Larga via a SSH, siempre he pensado que da mil vueltas a SSL para la protección de servicios!
#3 Si lees el artículo, verás que en el ataque se usa javascript para generar peticiones con las llaves del cliente. Así, capturando el tráfico SSL una vez las peticiones las genera el codigo javascript, se puede conseguir la llave de la sessión y descifrar toda la conversación, permitiendo el uso de toda la información que se haya transmitido (datos de login, llaves de paypal... cualquier información que se suponía protegida de mirones).
Este ataque es nuevo, ya que no falsifica ningún dato, simplemente permite que el atacante lea la conversación. Me parece que es de los primeros en conseguir-lo, después del ssl strip (que se basa en un fallo del usuario por pedir las páginas sin cifrar i esperar a que el servidor indique que se debe usar cifrado...)
Es un nuevo agujero de seguridad que debe ser tomado en cuenta, pues creo que va estar disponible durante mucho tiempo: requiere actualización del navegador web, y solo con ver que aún hay gente con IE6, pueden passar muchos años antes que este falló deje de ser usable.
#3 Como bien apunta #4, si lees el articulo que apunto en #1:
"Instead, BEAST carries out what's known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks.
If the attacker's guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.
#4 Hay muchas otras cosas que se apoyan en TLS para el cifrado, no solo el navegador.
No recuerdo exactamente que versión pero OpenVPN usa TLS como parte de la criptografía del cifrado.
Habrá que ver cual es el alcance real del asunto, pero si es como dicen, puede ser serio.
#13 No es lo mismo..... pero vamos, que me he cansado de decir una y otra vez que son diferentes palabras con diferentes raíces...
#24 ¿Por qué te metes en las conversaciones de las personas mayores?
Me votas negativo por decirle a #9 que criptografía sí existe.
"que me he cansado de decir una y otra vez que son diferentes palabras con diferentes raíces"
1.Soy tan talibán como el que más, pero regañinas y discursos los justos.Y menos sin motivos. Ya sé que encriptar no existe, nadie ha dicho lo contrario. Come fibra.
2.Y por tocarte un poco la moral:
Lo quieras o no encriptar, aunque no exista, existirá. No seguimos a la RAE, la RAE lo que hace es tomar nota del lenguaje empleado en la calle. El castellano es una lengua viva. De lo contrario, tú y yo estaríamos escribiendo en latín.
Positivo para ti, para que alegres ese espíritu geek que tienes. (Que por cierto si tan defensor eres del castellano podrías haber sustituido por "apasionados por la tecnología e informática" en lugar de usar anglicismos). Y neurálgico lleva acento. Corríjelo en tu página. Queda un poco mal.
#12 Tú mismo, la RAE ADMITIÓ "descambiar", el día que admitan "encriptar" pues otro gallo cantará, pero no es el caso.
#30 Eso de que existirá lo dices tú, el caso es que por ahora no existe, así que si quieres inventarte las palabras alla tú, pero actualmente el término no es válido en nuestro lenguaje, y habiendo uno que lo define perfectamente ¿para qué usar otro, aun encima inventado?
#30 si quieres te paso las claves y lo haces tu mismo......
P.D. Utilizaré lo que me venga en gana, pero por lo menos lo que utilizo existe en algún idioma
#36 Si quieres te lo dibujo para que lo entiendas, pero encriptar es un anglicismo de la misma manera que chatear también lo es. (supongo que nunca habrás usado el verbo inexistente chatear para expresar una forma de comunicación escrita ¿verdad?)
Puedes cabrearte todo lo que quieras, pero insisto, es irónico que el uso de anglicismos ofenda a alguien tan geek.
#9 Como dice el artículo, este ataque se basa en la inyección mediante javascript de texto conocido y especialmente preparado dentro de la conversación ssl, para más disfrute aún, en los primeros bytes de una nueva petición.
Así pues, mientras las aplicaciones que se usen no esten comprometidas (el escenario planteado para el ataque es bajo un man in the middle y con código inyectado), SSL3.0/TLS1.0 sigue siendo perfectamente válido. És un ataque a https, no a todo el protocolo.
Tal como comentaban en hacker news, los navegadores más nuevos que soportan TLS1.1 o 1.2 no se ven afectados, así como cualquier otra aplicación en la cuál la inyección de código no sea tan trivial como añadir texto plano extra a una petición de la víctima.
P.D: Cuesta creer que casi todos los comentarios sean de talibanes lingüísticos. ¿Por que no creáis vuestros flames en notícias de léxico y ortografía y dejais el resto tranquilas?
P.D.2: Larga via a SSH, siempre he pensado que da mil vueltas a SSL para la protección de servicios!
#10 Tambien conocido como fallo en la capa 8 de la aplicación
#32 Sin ricos no hay pobres y sin pobres no hay ricos. Son conceptos complementarios que sin uno no existe el otro. Así que cargarse a los ricos equivale a cargarse a los pobres i viceversa.
Así que si quieres hacer desaparecer a los pobres, empieza por hacer desaparecer las grandes fortunas (que son menos y más fáciles de localizar) y los pobres desaparecerán seguidamente pues no habrá 'rico' con quien comparar, todo es cuestión de como se reparten los recursos disponibles.
Tengo la mala suerte de conocer a uno de los detenidos y su detención. Daba miedo! Estábamos sentados en una terraza tranquilamente y de golpe un grupo de 4 encapuchados lo cogieron de todas partes y sin mediar palabra lo metieron en un coche. Salimos corriendo detrás de ellos hasta que uno de los encapuchados nos enseñó la placa y nos dijo que era policia. Tal como actuaron, no era una detención -para dar una citación y luego soltarlos- sino un secuestro en toda regla.