Abbiamo un'API B2B Rest con autenticazione del certificato client.
Ci sono motivi per aggiungere anche un controllo della firma del carico utile a questa API?
Vedo molti fornitori di servizi che aggiungono un parametro payload della firma digitale sulla loro API.
Avere già un'autenticazione del certificato client è un controllo ridondante o ha un altro scopo?
Ho letto che potrebbe aiutare a non ripudiare la transazione.
Ho il sospetto che questo sarà un grande "Dipende dalla tua architettura" e quindi le persone casuali su Internet non saranno in grado di darti una risposta completa.
In cima alla mia testa, ecco alcuni scenari in cui potrebbe avere senso avere le firme del carico utile TLS e dell'autenticazione client. I primi sono i vincoli di rete:
Poi ci sono molti modi in cui puoi avere una separazione logica tra la connessione TLS e le richieste API:
Un motivo per cui è necessario entrambi è quando l'API viene utilizzata sull'infrastruttura che separa la verifica della certificazione del client e la verifica del carico utile. In alcuni ambienti, il controllo dei certificati client viene eseguito a livello di bordo, mentre la verifica del carico utile viene eseguita a livello di applicazione, dopo aver attraversato alcuni livelli di bilanciamento del carico o sistemi proxy.
Questo a sua volta può consentire una forma sottile di attacco, in cui il certificato client è valido per la connessione al sistema, ma il payload interno corrisponde effettivamente a un altro client - il sistema edge consente l'accesso, poiché il certificato client è valido, e il sistema applicativo consente di eseguire l'azione, poiché non ha modo di verificare quale utente ha effettuato la richiesta, ma si fida del livello del bordo per consentire solo le richieste valide attraverso.
Se il carico utile è firmato, tuttavia, l'applicazione può ora verificare che l'azione richiesta sia appropriata per il client di connessione, anche se non ha accesso al controllo del certificato client.
Oltre alle risposte relative a TLS che terminano su un sistema separato rispetto a quello che verifica il payload, hai sentito correttamente che può aiutare con il non ripudio anche se TLS termina sullo stesso host.
Il certificato client autentica solo il client sul server, non autentica (direttamente) alcun dato inviato dopo. Normalmente questo non è un problema, poiché i dati inviati tra client e server sono crittografati e MACed con una chiave nota solo al client e server. Poiché il server può controllare il MAC dei dati che riceve, può facilmente provare a sé che deve provenire dal client (poiché il server non l'ha inviato, deve essere stato il client ), ma il server non può facilmente provare a altri che non ha fabbricato i dati e utilizzare la chiave TLS per crittografare e MAC.
Ecco una risposta correlata.
Proporre un'alternativa a Mutuo TLS ...
Abbiamo avuto molti problemi di supporto quando i nostri clienti aziendali tentano di impostare Mutual TLS con i nostri server SAAS. Inoltre, non c'è una buona soluzione per mantenere il 100% di uptime durante la modifica / aggiornamento del certificato foglia.
Ti suggerisco di prendere in considerazione l'utilizzo di intestazioni HMAC doppie.
Inoltre, HMAC fornisce un controllo end-to-end della validità del contenuto a differenza del controllo del livello di trasporto di TLS / Mutual TLS
Vedi la scrittura da Box per una buona soluzione:
Leggi altre domande sui tag rest authentication digital-signature non-repudiation