Autenticazione con certificato client vs HMAC

Penso che tu abbia riassunto bene.

Alcuni punti aggiuntivi oltre alla sicurezza tecnica di queste soluzioni:

• I certificati TLS richiedono la gestione, scadono, ecc. Dovresti considerare se hai le risorse (puoi automatizzare in parte) la gestione dei certificati. Uno scenario piuttosto brutto è quando le operazioni IT sono semplicemente stufe di tutti i problemi e disabilita la convalida del cert perché in questo modo funziona solo . ;)

• Anche un'implementazione della firma HMAC-SHA1 è abbastanza buona e puoi limitare la finestra temporale di una riproduzione (e come hai detto, in TLS va bene). Tuttavia, l'implementazione è più complessa rispetto all'altra. Se si tratta di una squadra più numerosa che manterrà il codice e, soprattutto, se è necessario modificare a volte l'implementazione, ci sono buone probabilità che venga introdotto un difetto. Gli altri due sono molto più semplici in termini di codice sorgente che deve essere scritto.

• HTTP Basic è molto semplice e potrebbe essere ok con TLS, ma come hai detto tu, direi che è il meno sicuro dei tre. Molte persone pensano ancora che sia abbastanza buono per molti scopi, ma dipende da cosa si vuole proteggere contro. TLS è considerato sicuro contro gli aggressori MitM. Penso che il più grande vantaggio sia la semplicità, non c'è molto da fare fuori strada.

Per me è un gioco da ragazzi: Certificati lato client TLS . Sono i più veloci, i più sicuri, i meno homebrew e tu dici che sta già utilizzando le librerie TLS . Sono anche molto più semplici dell'opzione HMAC in termini di implementazione.

Non fare roba con infrastruttura a chiave pubblica (PKI): lascia semplicemente che il lato client generi un certificato autofirmato valido per 100 anni e contrassegnato come non CA. Fidati di quel certificato sul server. Non c'è motivo di creare PKI, YAGNI ... Non risolve il tuo problema, introduce problemi di CRL o OCSP, problemi di classe SHA1 e molti altri effetti collaterali. Pensa a un certificato autofirmato semplicemente come una chiave pubblica RSA: è una di fatto.

Assicurarsi che client e server memorizzino nella cache le sessioni TLS. Questo ti darà connessioni TLS velocissime. (Ciò è vantaggioso quando si hanno solo certificati sul lato server. Ne beneficiano due volte quando si aggiungono i certificati sul lato client.)

C'è pochissima programmazione con questo, questo ha solo bisogno di implementare semplici opzioni di configurazione testuale che passano del testo (come la posizione di un file truststore da usare). Il personale amministrativo fa il resto. Sono anche in grado di testare robe stesse con openssl s_client ecc.

Qualsiasi vulnerabilità futura può essere gestita in modo amministrativo (ad esempio tramite l'aggiornamento di openssl ugprade o JDK).

La soluzione HMAC è una scatola nera per amministratori. Qualsiasi problema deve essere risolto dai programmatori.

Con l'autenticazione di base HTTP, stai facendo uno strano lavoro. È ancora necessario implementare TLS e impostare i certificati X509 (ad esempio il client probabilmente si fiderà di qualcosa di diverso dalle CA pubbliche predefinite) e sarà comunque necessario gestirlo e aggiornarlo. Ma fai metà lavoro e per l'altra metà usi un meccanismo completamente diverso. Sembra valido, ma ha un po 'di cattivo odore.

Credo che le tue supposizioni siano corrette finché hai una politica severa che il client interrompe la connessione nel caso in cui la catena del trust del certificato del server non possa essere verificata o nel caso si presentasse un altro problema di sicurezza TLS. Se ti fidi del TLS, sei al sicuro da replay ecc.

Potresti, tuttavia, dedicare un paio di riflessioni alla domanda su quanto velocemente puoi reagire se le tue informazioni di autenticazione sono compromesse. Qui, il passaggio a una chiave condivisa potrebbe essere significativamente più semplice o più difficile rispetto a mettere un certificato client su un CRL, questo dipende completamente dal proprio ambiente. Considerando che TLS offre una buona protezione per la trasmissione di dati via cavo, le opzioni descritte potrebbero fornire un livello diverso di comodità / affidabilità / sicurezza quando si tratta di revocare le informazioni di autenticazione.