¿Es SSL suficientemente seguro para una API REST? ¿Alguien ha utilizado PGP o AES para cifrar los datos reales dentro de SSL?

Sí, hay situaciones en las que las capas de cifrado tienen sentido. Aquí hay un ejemplo específico:

SSL puede ser descifrado legítimamente por puntos intermedios; no siempre es de extremo a extremo:

• Akamai puede descifrar y volver a cifrar el tráfico para el que proporciona la entrega de contenido.
• Prolexic desea las claves SSL de sus clientes para que cuando se les solicite protegerse contra una DDoS, puedan abrir paquetes y tomar decisiones inteligentes sobre qué permitir y qué dejar.
• Un IDS / IPS puede configurarse con claves privadas para descifrar el tráfico para su análisis, y usted quiere proteger los datos confidenciales para que no se registren allí.
• Incluso dentro de una empresa, SSL puede ser descifrado en una puerta de enlace de borde SSL por razones de rendimiento y pasado sin cifrar en redes internas.

Alguien va a saltar aquí y decir "¡No deberías usar SSL de esa manera!" Convenido. Simplemente sucede en el mundo real una cantidad no trivial de tiempo por razones razonables.

Mi empresa tiene una API que hace lo que usted describe. Las transacciones XML-over-HTTPS tienen campos confidenciales específicos cifrados con cifrado de clave pública. Los hosts provisionales pueden descifrar el SSL por motivos como los que he enumerado anteriormente sin exponer la información confidencial. Es una solución inteligente para un problema real.

Un compañero de trabajo y yo hicimos una presentación en AppSec USA hace unos años sobre este tema. (Admito que está un poco seco al principio, pero se vuelve más interesante a la mitad :)

enlace

La respuesta depende de cuál es su modelo de amenaza.

Si su modelo de amenaza incluye un usuario final malicioso, entonces no, SSL no es suficiente. Un usuario final puede MITM fácilmente su propia máquina y ver o modificar el tráfico de API. En nuestra charla, demostramos un escenario hipotético

Si su modelo de amenaza incluye estados nacionales que realizan un ataque de hombre en el medio, entonces SSL con una CA de terceros tampoco es muy seguro. (Esto es a lo que se refiere Rook anteriormente). La fijación de certificados es una posible solución, lo discutimos en nuestra conversación, pero tiene algunos inconvenientes, como una mayor dificultad para revertir los certificados cuando caducan.

Nuestra conversación trata sobre algunas posibles mitigaciones, pero el problema subyacente de confiar en un dispositivo que no está bajo su control generalmente no se resuelve.

Cifrar datos y luego transmitir este texto cifrado con flujo SSL / TLS proporciona cero beneficios de seguridad y es solo un desperdicio de recursos. SSL / TLS proporciona más que solo la confidencialidad, y el uso de SSL / TLS para transmitir texto cifrado es redundante. Lo que se ha demostrado que previene contra los ataques MITM (BGP o DNS) y otras formas de coerción gubernamental es Fijación de certificados . Lea: Su aplicación no debería sufrir los problemas de SSL . Espero con interés utilizando HTTP-Strict-Transport Security (HSTS) para la identificación del certificado ya que esto proporcionará herramientas útiles para mejorar HTTPS.

SSL / TLS es muy eficiente y tiene un diseño sólido. Por otra parte, nuestra PKI se rompe constantemente y no todos deben confiar en nosotros. Si una PKI rota afecta su modelo de amenaza, use la fijación de certificados. Si no desea utilizar un algoritmo específico, defina su propia lista de suites de cifrado permitidas.