No quiero que el servidor vea la entrada sin formato y prefiero que el cliente realice el cifrado y luego pase los datos (a través de https) al servidor para su almacenamiento.
Si uso una biblioteca JS para cifrarla con AES, ¿qué otras cosas debo tener en cuenta?
JavaScript crypto generalmente se considera una mala idea (consulte los detalles aquí )
Si está tratando de hacer frente a la amenaza de que el servidor sea malicioso, entonces el primer problema que encuentra es "¿de dónde viene el JavaScript del cifrado?"
La respuesta habitual para los sitios web es, "proviene del servidor", lo que le deja con el problema de que si el servidor es malicioso, solo pueden cambiar el JavaScript para darles una copia de la clave necesaria para descifrar los datos.
Esto hace que el criptográfico de JavaScript no tenga sentido ...
Las recientes filtraciones de la CIA (y, en menor medida, las revelaciones de Snowden anteriores) me han convencido de que @ rоry-mccune's response (que también creía anteriormente) ya no es un buen consejo. Los documentos de la CIA dicen que los ataques de degradación del protocolo hacen que el HTTPS sea ineficaz. Además, es bastante posible que incluso si una parte tiene una clave privada del servidor (habilitando tanto la vigilancia / falsificación HTTPS Y ) no deseen arriesgarse a revelar que tienen las claves privadas al modificar el contenido a través de un Ataque MITM, ya que el contenido modificado pudo ser detectado. También tenga en cuenta que la vigilancia pasiva puede llevar a un compromiso activo. Por ejemplo, si se envía una contraseña o token de acceso al servidor, un atacante puede usar esa contraseña para obtener más acceso sin revelar que ha roto un cifrado o implementado un ataque de degradación de protocolo pasivo (pasivo porque solo son vigilancia (no alteración / forjado) - presumiblemente en una red o como parte de una botnet de enrutadores / puntos wifi pirateados.
Además, generar un lado del cliente de clave privada, enviar la clave pública junto con el mensaje cifrado y eliminar (o reemplazar periódicamente) el lado del cliente de clave privada garantiza un mayor grado de confidencialidad en el caso de que se rompa un cifrado.
Aparte del posible rendimiento en ciertos contextos, no veo la desventaja del cifrado del lado del cliente. Sí, CSP, HSTS precargados y HPKP, TLS 1.2+ son más importantes y sí, si está obteniendo el código de otro lugar, puede joder con su tiempo de ejecución y sí, el generador de números aleatorios puede no ser lo suficientemente puro, pero todo el argumento está basado en Esta cita del artículo vinculado:
Usted puede. Es más difícil de lo que parece, pero transmites de forma segura. Javascript crypto a un navegador utilizando SSL. El problema es tener estableció un canal seguro con SSL, ya no necesita Javascript criptografía; Tienes criptografía "real". Mientras tanto, el Javascript El código criptográfico todavía está en peligro por otros problemas del navegador.
Lo que dice la CIA no es cierto en los documentos clasificados filtrados.
Además, las filtraciones de Snowden mostraron cómo, en muchos casos, los gobiernos usarían redes perezosas para la mayoría de los sitios y ataques dirigidos a algunos (como Google) que eran lo suficientemente seguros como para causar problemas. Si un cifrado se rompe en secreto, estará mejor protegido implementando esto que si no lo hiciera.
En cuanto a qué recomendar específicamente, no me he tomado el tiempo de examinar las alternativas. El autor del artículo vinculado menciona esto pero ahora que tenemos lo que estamos tratando de ser un generador seguro de números aleatorios en Chrome y Firefox I Creo que, en general, es mejor intentar animar a más desarrolladores de código abierto a que aseguren las cosas en lugar de no intentar hacerlo. Solo asegúrate de que sepan que es importante tener TLS.
Lea otras preguntas en las etiquetas aes