Fijación de certificado frente a cifrado E2E

  

Veo que hay algunas API que intercambian algunas claves públicas de tipo   Asegure el contenido de la conexión https usando encriptación asimétrica. Es   ¿Hay algún beneficio adicional para esto? Por lo que yo sé, debería ser   imposible para el hombre en el medio una conexión tls que tienen   fijación de certificados.

Lea el funcionamiento del protocolo TLS completo, es un excelente artículo disponible aquí: ¿Cómo funciona SSL / TLS?

En pocas palabras, las claves públicas se utilizan para permitir que el contenido que se ha cifrado mediante claves simétricas (claves derivadas como parte del protocolo de enlace) se autentique.

Los ataques del hombre en el medio no siempre se mitigan debido a la fijación de certificados. Por ejemplo, si el navegador nunca ha visitado el sitio antes, un hombre en el atacante central podría devolver su certificado que no menciona nada sobre la fijación.

  

El beneficio del cifrado de extremo a extremo está claro cuando se envía el contenido   de un usuario final a otro usuario final, lo que hace que el servidor de fondo no pueda   para leerlo.

No. Solo protege los datos en tránsito, cuando llega al servidor, cualquier cosa en ese servidor podría en teoría ver los datos.

  

Pero he visto algún ejemplo en el que solo se envían datos a   backend (cliente final para terminar backend), pero algún tipo de asimetría   se aplicó el cifrado.

     

Por ejemplo, AWS S3 permite al cliente cifrar los datos antes de enviarlos. yo   lea en algún lugar que Akamai también podría cifrar el contenido. tengo también   visto algunas instituciones que necesitan usar su tarjeta / claves para cifrar   el contenido.

S3 permite el cifrado asimétrico del lado del cliente. Lo que significa que su máquina local está cifrando los datos antes de enviarlos a AWS. Esto solo significa que usted, ni siquiera AWS, puede ver el contenido de los archivos. Esto es para la protección de datos en reposo, no datos en tránsito.

  

Volviendo a mi pregunta, ¿existe realmente algún beneficio de cifrado   contenido utilizando algunos medios (ya sea RSA o algún dispositivo) y enviándolo   sobre TLS con el certificado de fijación?

Depende de su aceptación de riesgos y requisitos de cumplimiento. Pero sí, el cifrado de datos no autentica los datos por sí solo. Si le envías a alguien un archivo cifrado, ¿cómo saben que en realidad proviene de ti? Alguien podría haber usado tu llave. SSL / TLS encripta, pero también autentica la conexión, para que sepa que realmente está "hablando" hasta el punto final en el que inició la comunicación. La identificación del certificado agrega seguridad de que, de hecho, obtienes el mismo certificado que obtuviste la última vez y, por lo tanto, es menos probable que estés involucrado en un hombre en el ataque central.

Me gusta esto de este problema en capas. La TLS es donde estamos usando Pinning para asegurarnos de que solo confiamos en que un certificado de servidor específico sea el más alto de las capas (sesión / transporte esencialmente) y nos aseguramos de no rechazar el par de claves del servidor. P.ej. Sabemos que el par de claves en el que confiamos es el par de claves al que nos estamos conectando, así como el uso de la tradicional cadena de confianza (verificando las CAs firmantes). Se podría decir que es irrelevante verificar la cadena de un certificado anclado, pero Lo ignoraremos por ahora, ya que no cambia el modelo significativamente.

El servicio que proporciona la terminación TLS para la sesión necesita el propio Certificado. En la mayoría de las implementaciones fuera del desarrollo / uso individual, a menudo vemos servidores web / LB que terminan las conexiones TLS que viven por separado de los servidores de aplicaciones que responden a solicitudes dinámicas. de los usuarios finales.

El servidor / procesamiento de la aplicación es donde van los datos que se encuentran dentro del túnel TLS, pero no se garantiza que estén controlados por la misma persona / organización en la que confía al fijar el certificado. Agregar un cifrado adicional en la parte superior de la capa de sesión (en los propios datos) puede proporcionar confidencialidad adicional si ese conjunto de claves se controla por separado del certificado del servidor TLS (por ejemplo, si cifró los datos con sus propias claves simétricas).

Si estamos hablando de cifrado asimétrico, puede usar un par de claves separado para garantizar la identidad en el lado del cliente (si el cliente tiene un par de llaves donde el aspecto público ha sido compartido con el servidor de destino), entonces puede cifrar los datos usando su clave privada para demostrar el no repudio de usted (quien controla su certificado de cliente) dentro del túnel TLS, lo que permite la confidencialidad de la transacción y el no repudio del servidor, y después de la verificación del no repudio del servidor cliente.