c# - válido - servercertificatevalidationcallback
¿Cuál es el punto de SSL si el violinista 2 puede descifrar todas las llamadas a través de HTTPS? (3)
Hace un tiempo hice una pregunta sobre cómo ocultar mis llamadas de solicitud http y hacerlas más seguras en mi aplicación. No quería que las personas usen el violín 2 para ver la llamada y configurar una respuesta automática. Todos me dijeron que fuera SSL y las llamadas se ocultarán y la información se mantendrá segura.
Compré e instalé un Certificado SSL y configuré todo. Arranqué el fiddler 2 y ejecuté una aplicación de prueba que se conecta a un servicio web https y que está conectada a un script https php.
Fiddler 2 no solo pudo detectar ambas solicitudes, ¡sino también descifrarlas! Pude ver toda la información regresando y la cuarta, lo que me lleva a mi pregunta.
¿Cuál es el punto de tener SSL si hizo cero diferencia en seguridad? Con o sin SSL, puedo ver toda la información regresando a la cuarta y STILL configurar una respuesta automática.
¿Hay algo en .NET que me falta para ocultar mejor mis llamadas pasando por SSL?
EDITAR
Estoy agregando una nueva parte a esta pregunta debido a algunas de las respuestas que he recibido. ¿Qué ocurre si una aplicación se conecta a un servicio web para iniciar sesión? La aplicación envía al servicio web un nombre de usuario y una contraseña. El servicio web luego envía los datos a la aplicación diciendo buenos datos de inicio de sesión o mal. Incluso si se pasa por SSL, la persona que usa el fiddler 2 podría simplemente configurar una respuesta automática y la aplicación se "descifraría". Entiendo cómo podría ser útil ver los datos en la depuración, pero mi pregunta es qué se debe hacer para asegurarse de que SSL se conecte a la que estaba solicitando. Básicamente diciendo que no puede haber un intermediario.
El objetivo de SSL / TLS en general es que el espía ocasional con Wireshark no pueda ver tus cargas útiles. Fiddler / Burp significa que interactuaste con el sistema. Sí, es una interacción muy simple, pero requiere que (uno) de los sistemas se vea comprometido.
Si desea mejorar la seguridad al hacer que estos programas MITM sean inútiles a un nivel tan básico, requeriría la autenticación del certificado del cliente (SSL bidireccional) y fijaría los certificados del servidor y del cliente (por ejemplo, requerir que solo el certificado particular sea válido para las comunicaciones). También encriptaría las cargas transferidas por el cable con las claves públicas de cada parte y se aseguraría de que las claves privadas solo residen en los sistemas a los que pertenecen. De esta forma, incluso si una de las partes (Bob) se ve comprometida, el atacante solo puede ver lo que se envía a Bob y no lo que Bob le envió a Alice. A continuación, tomaría las cargas cifradas y firmaría los datos con un certificado verificable para garantizar que no se manipulen los datos (hay mucho debate sobre si cifrar primero o firmar primero, por cierto). Además de eso, puedes usar la firma usando varias pasadas de algo como sha2 para asegurarte de que la firma es ''como enviada'' (aunque esto es en gran medida un paso oscuro).
Esto lo llevaría tan lejos en la forma de seguridad como sea razonablemente posible cuando no controla (uno) los sistemas de comunicación.
Como otros mencionaron, si un atacante controla el sistema, ellos controlan la RAM y pueden modificar todas las llamadas a métodos en la memoria.
Esto se trata aquí: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp
Fiddler2 se basa en un enfoque de "hombre en el medio" para la interceptación de HTTPS. Para su navegador web, Fiddler2 afirma ser el servidor web seguro, y para el servidor web, Fiddler2 imita el navegador web. Para simular ser el servidor web, Fiddler2 genera dinámicamente un certificado HTTPS.
Básicamente, usted confía manualmente en cualquier certificado que Fiddler proporcione, lo mismo será cierto si acepta manualmente el certificado de una persona aleatoria que no coincide con el nombre de dominio.
EDITAR: Hay formas de prevenir el ataque de Fiddler / man-in-the-middle, es decir, en la aplicación personalizada que usa SSL se puede requerir que se usen certificados particulares para la comunicación. En el caso de los navegadores, tienen interfaz de usuario para notificar al usuario sobre el desajuste del certificado, pero eventualmente permiten dicha comunicación.
Como muestra públicamente disponible para certificados explícitos, puede intentar usar los servicios de Azure (es decir, con las herramientas de PowerShell para Azure) y olfatear el tráfico con Fiddler. No funciona debido al requisito de certificación explícita.
Puede configurar su servicio web para requerir una certificación del lado del cliente para la autenticación SSL, así como para el servidor. De esta forma, Fiddler no podrá conectarse a su servicio. Solo su aplicación, que tiene el certificado requerido, se podrá conectar.
Por supuesto, entonces usted tiene el problema de cómo proteger el certificado dentro de la aplicación, pero de todos modos tiene ese problema con su nombre de usuario y contraseña. Alguien que realmente quiera descifrar tu aplicación podría usar Reflector, o incluso buscar en la memoria la clave privada asociada con el certificado del lado del cliente.
No hay una manera real de hacer que esto sea 100% a prueba de balas. Es el mismo problema que tiene la industria del cine para asegurar el contenido del DVD. Si tiene un software capaz de descifrar el DVD y reproducir el contenido, entonces alguien puede hacer un volcado de memoria mientras ese software está en acción y encontrar la clave de descifrado.