SSL sobre la autoimplementación de RSA?

Question

SSL sobre la autoimplementación de RSA?

#1 de Thomas Pornin (2 votos)

0

Actualmente escribo una aplicación cliente que se comunica con un servidor PHP.

La aplicación en sí misma requiere credenciales de usuario válidas y obtiene toda su información haciendo solicitudes POST al servidor PHP. ¿Es seguro el primer escenario o debo usar SSL / TLS en su lugar?

1er escenario (ya implementado):

La aplicación cliente tiene una clave pública RSA codificada
La aplicación genera una clave AES aleatoria y IV en cada inicio. (Nunca use la misma clave y IV para cifrar el nombre de usuario y la contraseña)
La aplicación del cliente cifra la clave AES y la IV con una clave pública RSA en una cadena
El servidor PHP descifra la cadena y almacena la clave AES y IV
La aplicación del cliente cifra el nombre de usuario y la contraseña cuando se intenta iniciar sesión
El servidor PHP recibe los datos cifrados, descifra los datos y usa password_verify para ver si las credenciales de inicio de sesión coinciden con las almacenadas
Después de iniciar sesión correctamente, la aplicación cliente necesita algunos datos de usuario y solicita un nonce del servidor PHP usando el nombre de usuario y la contraseña cifrados
El servidor PHP cifra el nonce y lo envía a la aplicación cliente
La aplicación cliente descifra el nonce y lo envía con la solicitud POST
El servidor PHP echa un vistazo a la base de datos y ve que el nonce es válido
El servidor PHP envía los datos cifrados AES que el usuario solicitó
La aplicación cliente ahora descifra los datos

2do escenario:

Implementando autenticación ssl mutua

tls aes rsa

pregunta wHaT 27.01.2015 - 12:59

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls aes rsa

Tiempo de respuesta promedio de Adobe PSIRT [cerrado] Cómo realizar un comando de inserción o actualización de SQL utilizando la inyección de SQL

score 2 · Accepted Answer

Si desea seguridad seria, debe pensar no solo en confidencialidad (haciendo que los datos sean ilegibles para los escuchas pasivos) sino también en integridad (detectar de manera confiable las alteraciones de activos atacantes). Los atacantes activos no son una noción de ciencia ficción; el atacante activo barato típico es un tipo malo que se sienta en un parque o en un restaurante y opera un punto de acceso "WiFi gratuito" falso, esperando que las víctimas se conecten a través de él.

La integridad debe estar garantizada dentro de cada mensaje individual (por lo tanto, el "cifrado AES" no es suficiente, también necesita un MAC ) y entre mensajes sucesivos (el atacante podría intentar soltar mensajes, duplicar mensajes, reordenar mensajes y mezclar conversaciones entre varios servidores y clientes).

Todo esto se puede hacer, pero requiere mucho cuidado y esfuerzo, y el resultado final será, más o menos, SSL / TLS : cuando su protocolo se haya expandido y arreglado lo suficiente como para tener en cuenta todos los posibles ataques, mostrará características internas similares a las de TLS, con una complejidad comparable. Por lo tanto, hay poca ganancia que esperar con el simple uso de TLS.

Además, el protocolo que es más fácil y más rápido de diseñar e implementar de forma segura (una tarea bastante desalentadora) es el protocolo que ya se ha diseñado e implementado de manera segura, por lo que ahorrará mucho tiempo y dolores de cabeza con solo usar TLS. En su caso específico, donde tiene una aplicación dedicada, podría usar un certificado autofirmado básico en el lado del servidor y codificar una copia de ese certificado en el cliente, de modo que la validación de X.509 sea una simple bit a bit comparación (por lo que no es necesario comprar y renovar un certificado de una CA comercial). Este certificado maneja la autenticación del servidor; Una vez que se establece el túnel, el cliente simplemente puede enviar el nombre de usuario y la contraseña dentro de él.