it-swarm-es.com

¿Puede Javascript / Flash verificar la conexión SSL para evitar la "Inspección SSL"?

Me gustaría determinar si una página web SSL se está depurando a través de Fiddler , o si está pasando por un Proxy SSL .

Entonces algunas personas pueden preguntar

¿Cuál es el punto de volver a validar SSL usando javascript?

Mi objetivo es saber cuándo una conexión está sujeta a la intercepción de terceros como se menciona en esto respuesta. La vulnerabilidad es que las contraseñas pueden estar expuestas, y las sesiones de usuario también están expuestas. Todo esto es posible cuando el software malicioso, o la política corporativa de TI dicta la intercepción y monitoreo SSL.

¿Qué se puede hacer si se intercepta una conexión SSL?

Dependiendo de la sensibilidad de la aplicación, y si se usa la autenticación de dos factores, puedo bloquear programáticamente la conexión o limitar el acceso a ciertas partes del sitio web. También puedo colocar una notificación de banner que indique el riesgo de seguridad de usar ese quiosco. ... O puedo permitir que el usuario agregue una "excepción", siempre y cuando comprenda los riesgos.

Mi pregunta :

¿Puede Javascript verificar los detalles del certificado SSL actual, incluida la cadena de CA?

Creo que la forma correcta de abordar esto es mirar al emisor del certificado y al resto de la cadena de certificados. El siguiente paso sería enumerar cada certificado en la cadena y ver si alguna de esas CA es igual a la raíz de las CA de confianza pública. Quiero excluir específicamente qué certificados adicionales puede haber agregado ese usuario a su computadora local.

Espero que la gente en security.stackexchange.com ofrezca ideas sobre cómo abordar esto.

Si Javascript no puede validar la conexión SSL actual, ¿cuáles son las alternativas?

Dado que esto puede o no ser posible en una solución de JavaScript pura, etiqueté esta pregunta con Flash, ya que debería ser capaz de lograr esto y enviar una respuesta a Javascript.

Si alguien tiene experiencia Java ME, mencione si esto es posible. Lo mismo ocurre con cualquier otro complemento ampliamente implementado.

Se aprecia el código fuente de la tecnología relevante.

14

Preguntaste sobre alternativas. Francamente, esta es una pregunta difícil: si alguien está jugando man-in-the-middle en su sesión SSL, y el usuario no se ha dado cuenta o ha permitido que continúe, está en una situación realmente difícil. Sin embargo, intentaré hacer una lluvia de ideas sobre algunas alternativas que podría considerar, si Javascript no puede verificar el certificado que el servidor proporcionó en esta conexión HTTPS. Ambas ideas están lejos de ser perfectas, en el mejor de los casos, pero las transmitiré en caso de que ayuden.

Idea 1. No confíe en el navegador. Una alternativa posible es usar la autenticación y confirmación de dos factores, para que no sea 100% dependiente de la sesión del navegador. Por ejemplo, para aplicaciones de banca en línea, si el usuario realiza una operación delicada, el servidor podría enviar al teléfono celular del usuario un mensaje SMS que enumera la información de la transacción ("¿pagar $ 100 a AT&T para aprobar? este PIN: 2781 "), y luego requerir que el usuario responda con su aprobación o ingrese el PIN en su sesión del navegador. Sin embargo, me doy cuenta de que esto es molesto e inconveniente para los usuarios.

Idea 2. Sockets sin formato. Otra posibilidad que podría explorar: use Flash o Java para abrir un socket sin formato a algún TCP puerto en el servidor. Si esto no es interceptado/man-in-the-middled por el proxy, ahora tiene varias opciones para detectar el proxy. Una estrategia de detección simple: si el servidor nota que la dirección IP de origen asociada con el el zócalo sin procesar es diferente de la dirección IP de origen asociada con esta conexión HTTPS. (Sin embargo, esto podría generar falsas alarmas ...) También puede omitir el proxy sin Flash o Java usando algún otro controlador de protocolo que el navegador reconozca pero que el proxy no intercepte, como ftp: // o somesuch.

5
D.W.

No: el DOM no expone el acceso al certificado SSL para la página actual, todo lo que tiene acceso es location.protocol que le permite verificar si se le está entregando a través de HTTPS

4
blowdart

En el contexto del navegador web, hay dos tipos de conexiones SSL: las que administra el navegador y las que administra su código (ya sea Java, Javascript ...).

Para el primer tipo, la mayoría no tiene suerte, porque el navegador no le dará detalles sobre la cadena de certificados del servidor. El navegador le dice "todo esto es excelente", pero no le da forma de verificar que el navegador no se esté desviando.

Para el segundo tipo, bueno, esto significa que su código abrirá la conexión al servidor y ejecutará el protocolo de enlace SSL completo. En ese punto, por supuesto, el código verá la cadena de certificados del servidor y podrá validarla de manera arbitraria, que incluye " confianza directa "(el código del cliente ya" conoce "la clave pública del servidor) o al menos utiliza una CA raíz específica esperada. Este enfoque tiene varios problemas prácticos que pueden abordarse a un costo:

  • Debe incrustar una implementación SSL completa. Esto no es necesariamente enorme, pero puede ser complicado. Puede hacerlo más pequeño, ya que controla el código del cliente y del servidor, de modo que puede concentrarse en la versión exacta del protocolo y los algoritmos que tiene la intención de usar.
  • El rendimiento puede ser un problema si se usa un intérprete sin compilador JIT .
  • Todo esto tiene sentido solo si puede asegurarse de que el código del cliente no haya sido alterado. Es inútil verificar cualquier cosa con Javascript sobre la conexión SSL a través de la cual se ha descargado el código Javascript: a Man-in-the-Middle puede cambiar el código Javascript para eliminar la verificación.
  • Abrir una conexión sin procesar al servidor desde el código del cliente es complicado en algunas redes, especialmente con respecto a los proxies .

Para el rendimiento, querrá usar Java ME . La mayoría de la implementación de Java ME usa intérpretes básicos, por lo que no será más rápido que Javascript o Flash, excepto que el estándar Java ME La biblioteca incluye Java.math.BigInteger, una implementación de aritmética en enteros arbitrariamente grandes, que generalmente se implementará como código nativo, por lo tanto, muy rápido. Lo necesitará para los cálculos de RSA o DH involucrados en el protocolo de enlace SSL.

Para asegurarse de que se está ejecutando el código correcto en el cliente, allí nuevamente Java ME puede acudir al rescate, porque Java los applets de ME pueden estar firmados . Esto realmente no resuelve su problema, porque un atacante que puede ejecutar Fiddler es un atacante que podría insertar su propia CA falsa en el almacén de confianza local; el mismo atacante podría haber agregado su propia CA falsa al otro almacén de confianza local, el que valida los certificados de firma de applet. Sin embargo, esto agrega un toque agradable: si se intercepta la conexión del cliente, entonces, los exámenes forenses posteriores pueden descubrir el applet firmado en caché, y luego se hará evidente que el applet es falso y usted, como mantenedor del servidor, no es el malo. No puede tener ese tipo de protección legal contra la autenticación, pero las firmas pueden ayudar. Esto, por supuesto, depende mucho del contexto.

El problema con los proxies es grave. Muchas redes locales, especialmente corporativas, no lo hacen NAT ; en cambio, todo el tráfico externo debe pasar por algunos servidores proxy. El navegador web del usuario sabe dónde están los servidores proxy, pero no su código Javascript o Java. Además, los proxies pueden requerir alguna autenticación, que puede estar vinculada con las credenciales de la sesión local; allí nuevamente, el navegador pasa de manera transparente, no su código. Para hacer frente a ese tipo de problema, puede imaginar la tunelización de su tráfico SSL a través de solicitudes HTTP, que se entregarán al código HTTP proporcionado por el marco. Esto es posible (lo hice hace aproximadamente una década) pero no es fácil.


Sin embargo, todo esto huele mal. Los ataques MitM del tipo del que está hablando funcionan solo si el atacante podría atravesar el modelo de confianza X.509, p. instalando su propia CA no autorizada como una CA confiable en el sistema del cliente. Dado que las actualizaciones de software del sistema operativo también usan este modelo de confianza, se debe suponer que el sistema cliente está, en ese momento, bajo el control completo del atacante, en menos potencialmente. En cierto modo, Fiddler no es algo que usan las personas malvadas, porque las condiciones que permiten que Fiddler opere también permiten que las personas malvadas antes mencionadas promulguen la maldad a una escala mucho mayor y más completa.

Lo que se puede resumir como: verificar las cosas en las conexiones SSL desde Javascript o Java El código del lado del cliente ME es tan inútil como una buena nota en la mesa de su sala de estar, solicitando posibles ladrones para llamar amablemente a la Policía.

(Sin embargo, podría funcionar en Canadá).

4
Thomas Pornin

Dado su modelo de amenaza (detecta un proxy que representa SSL pero no intenta alterar su código de verificación), puede incrustar código Javascript en todas sus páginas que suma el contenido y lo compara con una suma de verificación codificada por el servidor, para determinar si la página que llegó al cliente coincide con lo que envió el servidor. Sin embargo, sospecho que probablemente haya algunos desafíos técnicos no triviales aquí, y no estoy convencido de que te compre mucho (ten en cuenta que un proxy malicioso siempre puede eliminar tu código de verificación).

Puede que le interese aprender acerca de Suiza y trabajar en la Universidad de Washington en "web tripwires" .

3
D.W.

Esto no es actualmente compatible (por lo que puedo decir) por ninguno de los navegadores.

Hay un error sobresaliente en Firefox para introducir algún tipo de soporte para esto, pero no se ha resuelto.

Puede admitir esto en Javascript utilizando OpenSSL compilado con Emscripten aunque ese enlace solo proporciona los huesos, necesitará construir el enlace JS a su aplicación.

Puede admitir esto en Flash utilizando OpenSSL compilado con Adobe Alchemy (búsquelo) pero necesitaría rehacer el trabajo para el motor Flash más nuevo y OpenSSL.

1
Joe Steele

En lo que respecta a Silverlight y .NET, normalmente usaría ServicePointManager para interceptar llamadas para validar el certificado SSL, sin embargo, parece que eso no es posible en el SL4.

Hay una publicación en Microsoft Connect con respecto a esto, sin embargo, Microsoft dice que es por diseño. Animaré a cualquiera que piense que esta función debería estar disponible para los desarrolladores de Silverlight para publicar una respuesta allí.

0