SSL (TLS v1.2) - Posso offrire CA di fallback durante l'aggiornamento dei certificati? (Giava)

Question

SSL (TLS v1.2) - Posso offrire CA di fallback durante l'aggiornamento dei certificati? (Giava)

#1 da (1 voti)

0

Attualmente sto sviluppando un prodotto che coinvolge due situazioni di rete. Sul lato client, più computer formano una rete P2P (più sedi, più reti p2p) e un sottoinsieme di nodi di ciascuna rete stabilisce una connessione con un sottoinsieme di server che ospitiamo (per scambi di dati, aggiornamenti). Tutti i server e i client hanno certificati, firmati con un certificato CA.

Il mio problema ora è l'aggiornamento delle CA (intermedie). Non posso garantire un aggiornamento simultaneo di tutte le macchine contemporaneamente (anche per i failover, un tempo di transizione sarebbe apprezzato), e quindi ci deve essere un periodo di tempo in cui sono validi più certificati CA, una versione legacy che si esaurirà in non -il tempo trascurabile e una versione aggiornata per sostituirlo.

Poiché il client attende con la sua autenticazione fino a quando non ha ricevuto il certificato del server, può reagire a una CA obsoleta e inviare la propria catena di certificati legacy, e poiché la connessione nelle reti p2p verrà tentata in entrambi i modi, posso ignora il caso in cui un client legacy incontra un server aggiornato e aspetta solo che accada il contrario.

Ma questo non funziona per i server centrali, perché i client potrebbero nascondersi dietro un NAT Layer, anche a me sembrerebbe brutto girare la connessione in un vero modello client-server. Lavorare con il certificato precedente fino al giorno x senza offrire una transizione fluida mi sembra rischioso.

Quindi ecco finalmente la domanda, è possibile che un server SSL offra un certificato fallback nel caso in cui la CA corrente (intermedia) sia sconosciuta dal client.

Ho due idee per soluzioni alternative (in caso di errore, ricorda l'IP del client e invii un certificato diverso al tentativo, oppure esegui il servizio su porte diverse con certificati diversi), ma poiché l'aggiornamento delle CA è una cosa reale, suppongo che sii la soluzione migliore.

Per favore mi illumini.

public-key-infrastructure tls certificate-authority x.509

posta Sebastian Mohr 12.10.2013 - 19:30

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure tls certificate-authority x.509

Una telecamera IP funzionerà ancora se il router wifi si rompe o si spegne? [chiuso] Come implementare correttamente TLS su un server ejabberd

score 1 · Answer 1

La soluzione è: non fare nulla.

I server ei client SSL inviano i loro certificati come catene proprio perché non possono assumere che il peer abbia già tutto il certificato CA intermedio necessario. L'intero punto delle catene di certificati e delle CA intermedie è che una "parte relying" (gergo X.509 che qui significa "un client o un server") può convalidare una catena, qualsiasi catena, purché abbia già il trust ancora , che è anche conosciuto come "certificato radice" o "CA radice". Cioè la CA che non è una CA intermedia.

Ad esempio, supponiamo che nel tuo sistema ci sia una CA radice che tutti conoscono a priori (questo è ciò che è per CA root). Poi c'è la "vecchia CA intermedia" chiamata CA1 e la "nuova CA intermedia" chiamata CA2. Il server in precedenza aveva un certificato S1 emesso da CA1, ma ora ha un nuovo certificato S2 emesso da CA2. Un client si connette. Cosa manderà il server? Bene, il server invia semplicemente la catena CA2- > S2. Il client potrebbe non aver mai visto CA2 prima; non importa. CA2 viene emesso (firmato) dalla radice e il client conosce e si fida della radice, in modo che il client possa verificare la firma sul certificato CA2 e apprendere quindi che CA2 è una CA intermedia valida che il client non aveva ancora incontrato. La convalida del certificato procede quindi con la verifica della firma su S2, da parte di CA2. Le cose funzionano.

I certificati X.509 funzionano in un modello PKI gerarchico in cui gli attori devono conoscere CA radice e niente di più . Questi certificati sono stati progettati per lo scopo esatto di evitare il problema che si prevede, vale a dire la distribuzione di CA intermedio. Qualsiasi client (o server) può creare dinamicamente qualsiasi catena di fiducia richiesta in base ai certificati che ha in qualsiasi momento, e poiché i certificati sono concatenati, il modo in cui vengono ottenuti non è importante. In particolare possono essere ricevuti dal peer e questo trasferimento non richiede ulteriore fiducia.

Quindi finché tutti i server (e i client) inviano i loro certificati come parte di catene che sono valide in quel momento, la convalida funzionerà.

Ora, se stavi parlando dell'aggiornamento di una root CA, allora sì, sarebbe diventato complicato. La fiducia viene trasportata attraverso le firme sui certificati; ma non è creato dal nulla. Deve iniziare da qualche parte, e quella da qualche parte è una a priori , una conoscenza intrinseca di un'ancora di fiducia. Per riassumere, davvero non si vuole cambiare spesso la CA radice, perché è un disastro. Si suppone che una radice sia molto longeva. E questo implica l'uso di CA intermedie, perché una radice molto longeva è una cosa preziosa, quindi veramente vuoi mantenere la CA root offline e usarla come piccola possibile.