si Noscript está seguro, ¿es posible que nuestro sistema todavía se comprometa con criptografía?

Question

si Noscript está seguro, ¿es posible que nuestro sistema todavía se comprometa con criptografía?

#1 de Thomas Pornin (5 votos)
#2 de Dinu S (2 votos)
#3 de Nicolai (0 votos)

0

quizás todos nosotros usamos no-Script cuando visitamos páginas web que no son de confianza para bloquear todos los complementos de scripts, etc., pero todavía hay algo más que códigos HTML simples que no bloqueamos; Conexión SSL! en el protocolo Https, cualquier página web puede enviarnos datos criptográficos que se manejan con Firefox NSS lib y casi siempre se basan en dos cosas, AES y RSA. desde mi opinión, cifrar o descifrar los datos recibidos de un sitio no confiable debe ser seguro porque las crypto libs no son como un reproductor flash que le da al atacante la capacidad de hacer infinitos códigos posibles y ejecutar ... por ejemplo, en AES solo procesa cada byte con unos pocos conocidos ciclos para cifrarlo o descifrarlo, y ambos son casi iguales y en RSA es solo una función matemática en un número, ¿por qué el cálculo de números causa un desbordamiento de búfer? la pregunta es:

¿es posible hacer un compromiso con cifrado / descifrado AES ?
es posible hacer un compromiso con descifrado RSA (si el atacante conoce la clave privada o no)

web-browser buffer-overflow

pregunta user20876 17.02.2013 - 17:42

fuente

3 respuestas

Lea otras preguntas en las etiquetas web-browser buffer-overflow

Restablecimiento automático de contraseña: ¿es una buena idea? ¿Qué tan seguro es el proceso de hashing / salazón / estiramiento como se describe en este diagrama?

score 5 · Answer 1

Los algoritmos criptográficos no son intérpretes para un lenguaje equivalente a Turing. Como tales, no pueden compararse de manera significativa con el soporte de scripting, que Noscript desactiva.

Las implementaciones de algoritmos criptográficos rara vez se ven afectadas por desbordamientos de búfer, pero pueden filtrar algunos datos altamente confidenciales (como claves criptográficas) si se implementan de manera inexperta. Una fuente más común de vulnerabilidades es el manejo de los certificados X.509 (p. Ej., Vea esto para OpenSSL ), porque la decodificación de certificados puede ser una tarea desalentadora debido a su uso (ab) de todas las complejidades de ASN.1 .

score 2 · Answer 2

Está preguntando si es posible encontrar una falla en el mecanismo SSL, de modo que pueda ejecutar un exploit en una computadora víctima.

Esto es altamente improbable, el propósito de la conexión cifrada es claro y la implementación también está probada y es bastante estricta.

Si el otro extremo no habla SSL y dice que sí, entonces el navegador cortará la conexión tan pronto como algo no esté bien.

Tan pronto como compruebe que está en el dominio correcto y que tiene un certificado válido, debería estar seguro en la mayoría de los casos (excepto en el caso de que tanto un servidor DNS como una autoridad de certificación estén en peligro). / p>

score 0 · Answer 3

Para darle una respuesta breve y clara: sí, en teoría, se puede comprometer simplemente visitando la fuente de vista: http s : //attacker.in.

Sin embargo, la mayoría de los criptográficos se centran mucho en el manejo de errores (por ejemplo, alguien que manipula la secuencia cifrada no debería aprender nada sobre el texto claro), por lo que, al igual que los otros, creo que es muy poco probable que exista algún defecto (explotable) en esta parte del código.

Un atacante también podría encontrar una falla en la imagen / css-rendering o tal vez omitir NoScript con algún tipo de juego de caracteres inteligente mezclado (mientras que NoScript es impresionante (!!), entonces no es 100% perfecto, nada es).