Abbiamo un'interessante discussione tra il team dell'operatore del server e gli sviluppatori di un'applicazione client.
La nostra configurazione in generale è così: C'è un root-ca, chiamiamolo "root-1". Questo ha un sub-ca, chiamiamolo "sub-1". Entrambi sono contenuti nel truststore del server. Il client ha un key / truststore combinato (vale a dire lo stesso file keystore), contenente la catena ca menzionata sopra e un certificato client emesso da sub-1. Chiamiamo questo "client-1".
Durante l'handshake TLS, il server invia un messaggio CertificateRequest, contenente un elenco di DN attendibili (perché si trovano nel truststore), ovvero ["root-1", "sub-1"].
Il client controlla l'elenco, riconosce che ha un certificato emesso da "sub-1" e invia tale certificato come elenco_certificazione con una singola voce: il certificato client.
Gli operatori del server affermano che il client deve inviare l'intera catena di certificati, ma può omettere il root-ca. Fondamentalmente, a loro piace eliminare "sub-1" dal loro truststore in modo che solo il "root-1" sarà richiesto dal server. Il client dovrebbe trovare "client-1" che viene emesso da "sub-1" che viene emesso da "root-1" e quindi inviare l'intera catena di certificati.
Gli sviluppatori client affermano che si tratta di una violazione della sicurezza o almeno meno sicura della soluzione corrente. Dicono che sembra che il server convaliderà il certificato del client nuovamente il trustchain che il client ha inviato da solo.
Quindi dal mio punto di vista ci sono due domande che risultano da questa discussione: 1. Se il server richiede solo "root-1", il client dovrebbe trovare "client-1" come certificato appropriato e usarlo per la comunicazione? 2. Se la risposta alla prima domanda sarebbe sì, il client dovrebbe inviare la catena di certificati, cioè [client-1, sub-1] (omettendo root ca secondo rfc)?
La RFC 5246 potrebbe essere un po 'sfocata in quella sezione:
7.4.6. Client Certificate
[...]
Client certificates are sent using the Certificate structure
defined in Section 7.4.2.
E la Sezione 7.4.2 dice:
7.4.2. Server Certificate
[...]
Structure of this message:
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
Lo sviluppatore client ora sta interpretando questa sezione in questo modo:
Each following certificate MUST directly certify the one preceding it.
Questo significa che non ci deve essere un certificato che segua il "certificato dei mittenti", cioè il certificato del cliente. Poiché la stessa struttura viene utilizzata per il certificato server e client, l'elenco certificati ha una lunghezza di 0..2 ^ 24-1. Ciò significa che l'elenco è valido con 0, 1 o più voci.
Il mio pensiero su questo è questo:
- se il server ha "sub-1" NON nel suo truststore, userà il CA che il client sta inviando per la convalida, il che mi sembra meno sicuro. Un utente malintenzionato potrebbe produrre un "sub-2" valido in qualche modo, quindi creare un certificato client utilizzando "sub-2", inviare la catena e verrà autenticato.
- Un elenco di revoche per CA non funzionerà quindi, perché il rogue ca "sub-2" è sconosciuto
- qual è il vantaggio di avere solo root-ca nel truststore del server e avere un client che invia l'intera catena di certificati?
Informazioni aggiuntive: anche il client è un middleware, quindi non c'è alcuna possibilità di interazione con l'utente.
Gli sviluppatori del client temono che l'elaborazione voluta dagli operatori di server porti gravi problemi di sicurezza, che altrimenti sarebbero facilmente evitati. Per loro non ha senso inviare il sub-ca insieme al certificato client, perché il server dovrebbe in realtà FIDARTI il sub-ca. Ecco perché il sub-ca dovrebbe risiedere nel truststore del server.
Gli operatori di server stanno dicendo che sarebbe molto importante mantenere sempre un set di sotto-cas valido nel truststore del loro server, perché potrebbe esserci un nuovo sub-cas in arrivo, senza la loro conoscenza o attenzione. Inoltre, si dice, il comportamento del client non è conforme a TLS 1.2 e viene richiesto di utilizzare TLS 1.2.
Ma non riesco a trovare alcuna differenza nell'area CCA (Autenticazione del certificato client) tra TLS 1.0 e TLS 1.2. È lo stesso testo lì.
Apprezzerò qualsiasi chiarimento di questo problema da parte di qualcuno degli esperti di sicurezza qui.
- Come gestisci scenari simili nei tuoi progetti? Quando si implementano i client conformi a TLS 1.2, si sta inviando la catena di certificati o un singolo certificato?
- Metti il sub-cas nel truststore dei tuoi server o no? E perché?
Ci scusiamo per il lungo testo, ma penso che sia una situazione delicata, e deve essere spiegata in dettaglio, credo. Addizionalmente, penso che rfc 5246 sia sfocato nell'aspetto in cui l'handshake SSL reciproco deve essere fatto, esattamente.