Tenemos una API de resto B2B con autenticación de certificado de cliente.
¿Hay alguna razón para agregar también una comprobación de firma de carga útil a esta API?
Estoy viendo muchos proveedores de servicios que agregan un parámetro de carga de firma digital en su API.
Tener una autenticación de certificado de cliente en su lugar, ¿es un cheque redundante o tiene otro propósito?
Leí que podría ayudar a no rechazar la transacción.
Sospecho que esto será un gran "Depende de tu arquitectura" y, por lo tanto, los usuarios aleatorios de Internet no podrán darte una respuesta completa.
Desde lo alto de mi cabeza, aquí hay algunos escenarios donde podría tener sentido tener firmas de carga útil TLS y de cliente-autenticación. Las primeras son restricciones de red:
Luego hay una gran cantidad de formas en que podría tener una separación lógica entre la conexión TLS y las solicitudes de API:
Una razón para requerir ambos es cuando la API se está utilizando en la infraestructura que separa la verificación de certificación del cliente y la verificación de la carga útil. En algunos entornos, la verificación de los certificados de los clientes se realiza a un nivel perimetral, mientras que la verificación de la carga útil se lleva a cabo en el nivel de la aplicación, después de pasar por algunas capas de equilibrio de carga o sistemas proxy.
Esto a su vez puede permitir una forma sutil de ataque, donde el certificado del cliente es válido para la conexión al sistema, pero la carga útil interna corresponde en realidad a otro cliente: el sistema perimetral permite el acceso, ya que el certificado del cliente es válido. y el sistema de aplicación permite que se realice la acción, ya que no tiene forma de verificar qué usuario realizó la solicitud, sino que confía en que la capa de borde solo permita solicitudes válidas a través.
Sin embargo, si la carga útil está firmada, la aplicación ahora puede verificar que la acción solicitada es adecuada para el cliente que se conecta, incluso si no tiene acceso a la verificación del certificado del cliente.
Además de las respuestas con respecto a la terminación de TLS en un sistema diferente al que verifica la carga útil, escuchó correctamente que puede ayudar con la no repudiación, incluso si TLS termina en el mismo host.
El certificado del cliente solo autentica al cliente en el servidor, no autentica (directamente) los datos enviados después. Normalmente, esto no es un problema, ya que los datos enviados entre el cliente y el servidor están cifrados y MACed con una clave conocida solo por cliente y servidor Dado que el servidor puede verificar el MAC de los datos que recibe, puede demostrar fácilmente a sí mismo que debe provenir del cliente (ya que el servidor no lo envió, debe haber sido el cliente). ), pero el servidor no puede demostrar fácilmente a otros que no fabricó los datos y usó la clave TLS para cifrarlos y macularlos.
Aquí hay una respuesta relacionada.
Proponiendo una alternativa a Mutual TLS ...
Hemos tenido muchos problemas de soporte cuando nuestros clientes corporativos intentan configurar Mutual TLS con nuestros servidores SAAS. Además, no hay una buena solución para mantener el tiempo de actividad al 100% al cambiar / actualizar el certificado de hoja.
Le sugiero que considere utilizar encabezados HMAC duales en su lugar.
Además, HMAC proporciona una verificación de extremo a extremo de la validez del contenido, a diferencia de la verificación de la capa de transporte de TLS / TLS mutua
Consulte el artículo escrito en el recuadro para obtener una buena solución:
Lea otras preguntas en las etiquetas authentication digital-signature rest non-repudiation