POST sobre HTTPS ¿es "suficientemente seguro" para datos confidenciales?

8

Me pregunto si para evitar la posibilidad de un certificado SSL comprometido que pueda conducir a la divulgación de información confidencial si sería prudente cifrar más los datos que se pasan sobre SSL.

Escenario imaginario: dos aplicaciones web. Una es una aplicación web, la otra es una aplicación que proporciona una API de autenticación.

La aplicación web envía un POST HTTPS a la API de autenticación que contiene el nombre de usuario y la contraseña. Está cifrado a través de SSL.

Sin embargo, ¿no podrían rastrearse esos datos si un atacante comprometiera el certificado SSL?

Mi pensamiento es agregar otro nivel de cifrado, por ejemplo, tenemos un par adicional de clave pública / privada y también ciframos toda la información en el POST.

Eso significaría que un atacante que había comprometido tu certificado SSL tendría que encontrar una clave privada adicional para romper la comunicación.

¿Pensamientos?

    
pregunta user8405 06.02.2014 - 22:01
fuente

4 respuestas

4

En lugar de cifrado adicional, si debe ser seguro, use la autenticación de dos factores. Haga que los usuarios ingresen un nombre de usuario, una contraseña y un número aleatorio de 6 dígitos enviados por correo electrónico o SMS. Un certificado comprometido significa que el atacante posiblemente puede controlar la carga útil SSL completa en ambas direcciones; incluyendo cualquier código que envíe al cliente para realizar el cifrado requerido para autenticarse con el servidor.

También considere separar su servidor de aplicaciones y su servidor de autenticación. Esto hace que sea mucho más difícil para un atacante hacer algo útil con una lista adquirida de nombres de usuario y contraseñas si el servidor de aplicaciones no los acepta realmente; Este es el concepto detrás de OAuth2. Es mucho más fácil recuperar un servidor que atacar dos servidores (al menos, en teoría).

    
respondido por el phyrfox 06.02.2014 - 23:08
fuente
2

Supongo que cuando dices que la "aplicación web" envía un POST, lo que realmente quieres decir es que la página web html en el navegador de los usuarios realiza una solicitud POST a un servidor de terceros.

El evento de un compromiso SSL / TLS por parte de un atacante externo (CA / gobierno no autorizado) es probablemente bastante bajo. Eso deja dos posibilidades.

# 1. Su servidor fue comprometido a través de un ataque no relacionado, y la clave privada fue robada

Si alguien está en su sistema y puede acceder a la clave privada, es probable que pueda acceder a su aplicación / fuente y modificarla para extraer datos (MITM). En ese momento, ninguna criptografía adicional lo salvará.

# 2. La configuración utilizada para crear / implementar SSL / TLS es mala. Si está utilizando algoritmos / hashes inseguros o una versión SSL antigua, puede ser vulnerable a ataques SSL específicos ( enlace ) . Recuerda utilizar SSL 3 / TLS. Preferiblemente TLS 1.2.

    
respondido por el Daisetsu 07.02.2014 - 03:51
fuente
0

¡Sí! TLS es no seguro: la sustitución de certificados es extremadamente (la mayoría de las empresas utilizan dispositivos de borde de inspección de contenido, la mayoría de las escuelas y Unis, todos los buenos cortafuegos e incluso varios países todos obligan a los usuarios a instalar su propia CA para que puedan usar MitM e inspeccionar el tráfico "encriptado"). Aproximadamente cada 2 meses, una nueva CA también se ha visto comprometida. También hay muchos programas maliciosos que instalan su propia CA en las máquinas víctimas.

El uso de 2FA no es una solución para este problema. 2FA es una tecnología de autenticación de 35 años que no tiene nada que ver con la protección contra la intercepción de tráfico.

    
respondido por el Anon Coward 14.03.2017 - 16:31
fuente
0

Si está asumiendo que la clave privada fue comprometida (el certificado se entrega con cada transacción, pero es inútil sin la clave privada), tendría que haber sido en el banco. Si este es el caso, cualquier otro mecanismo de seguridad provisto por el banco es igualmente nulo e inútil.

Si está asumiendo que el navegador o la aplicación tiene una autoridad CA adicional (como lo hacen a menudo los empleadores), entonces el cliente está comprometido. Si no confía en la lista de entidades emisoras de certificados, ¿por qué confiaría en que el navegador no tiene ningún enganche, o en el caso de un registrador de teclas?

Si esto se hace desde una aplicación que está escribiendo, debería poder obtener el certificado TLS para su conexión. Esto debería ser posible para Java en un navegador, (aunque aparentemente no es de Javascript). Todavía está, por supuesto, asumiendo que la aplicación / programa java no ha sido manipulado, no hay manera de ejecutar código de confianza en una plataforma no confiable.

Si tiene una conexión TLS con Diffie-Hellman, no es posible descifrar los datos capturados, incluso con la clave privada (cita: enlace ).

Un ataque de hombre en medio aún funcionará incluso para un Diffie-Hellman (si el atacante tiene la clave privada y el certificado, no se pueden distinguir del propietario legítimo).

Mi opinión personal es que, si alguien está manipulando / intentando manipular mis datos, entonces no quiero otra capa de encriptación, quiero que se me informe (y se me niegue el servicio).

También tenga en cuenta: he visto certificados de CA adicionales instalados por el software antimalware, por lo que puede buscar malware entregado por https.

    
respondido por el AMADANON Inc. 04.08.2018 - 12:36
fuente

Lea otras preguntas en las etiquetas