I certificati autofirmati sono attualmente più sicuri dei certificati firmati CA?

C'è un punto sottile qui. Nella situazione prevista, c'è una (o più) CA canaglia che può emettere certificati falsi per man-in- gli attacchi di mezzo . La vulnerabilità qui non riguarda un server che utilizza un certificato (originale) da tale CA canaglia; riguarda il client potenzialmente che accetta un certificato da tale CA. Per proteggere te stesso (come un cliente) contro la CA canaglia, devi non fidarsi di CA (ad esempio rimuovilo dal tuo archivio di certificati "root attendibili"). Questo semplicemente implica che i server con cui si desidera continuare a parlare dovrebbero utilizzare altri CA distinti per i loro certificati.

In una società, produrre certificati autofirmati e spingerli a tutti i clienti è davvero un caso speciale di mantenere la propria PKI : la società produce uno o più radici, che devono essere installate in tutti i clienti. Questo è fattibile; alcune aziende fanno proprio questo. Ma per MitM come discusso qui, nulla viene acquisito fino a quando l'archivio "trusted roots" di tutti i client viene eliminato da tutte le altre CA potenzialmente malvagie.

Purtroppo, non puoi necessariamente farlo . Se il tuo sistema operativo è Windows, ci sono molte firme usate per vari componenti, in particolare per gli aggiornamenti da Microsoft. fai vuoi installare le correzioni di sicurezza, vero? Puoi rimuovere la maggior parte della CA radice dalle "radici attendibili", ma non tutte, altrimenti molte cose si romperanno nel tuo sistema operativo.

Il problema concettuale è che alcuni SO (in particolare Windows) usano un meccanismo centralizzato per la convalida dei certificati, in cui c'è un one trust store che è ritenuto appropriato per tutto ciò che riguarda la convalida dei certificati sul macchina (nei dettagli, c'è un solo negozio fidato "locale", comune a tutti gli utenti, e un altro negozio fiduciario per utente, ma un utente non può "optare" per l'archivio fiduciario comune della macchina locale). Potresti avere più fortuna con altri sistemi operativi come Linux, che tradizionalmente non usano i certificati X.509 per le loro esigenze interne, ma le chiavi OpenPGP, con un sistema di fiducia molto più decentralizzato.

Il Firefox browser Web, tuttavia, utilizza la sua implementazione SSL e il suo trust store, separati da quello del sistema operativo di base. Inoltre, Firefox supporta profili , nel senso che un utente può avere più "personaggi" con Firefox, ognuno con le proprie impostazioni, incluso il set di radici attendibili. Pertanto, una società che teme per la riservatezza dei dati potrebbe fare quanto segue: potrebbe istruire i suoi dipendenti, quando si occupano di server aziendali, a utilizzare sempre Firefox, con un profilo specifico che contiene solo la radice della società (o un insieme di certificati firmati) come "trusted root".

Non è chiaro se gli impiegati vorranno, ma è fattibile.

Ricorda, tuttavia, che un potente attaccante è potente. Se quell'attaccante può controllare "CA ufficiale", allora potrebbe spingere un aggiornamento falso, presumibilmente firmato da Microsoft, che installa una backdoor in ogni sistema. Oppure potrebbero semplicemente chiedere a Microsoft di piantare la backdoor da soli. In ogni caso, non hai molta scelta: per costruzione, devi avere fiducia nel sistema operativo e nell'hardware per non aver giocato con te.

I plugin del browser come Certificate Patrol per Firefox possono avvisarti di cambiamenti dal l'ultima volta o la prima volta che hai visitato; ma scoprirai che molte delle topologie di rete legittime e le soluzioni di bilanciamento del carico si sono basate su questo difetto di sicurezza intercambiabile di SSL, quindi finirai con un sacco di richieste e avvertimenti durante la navigazione in Internet.

È corretto che i certificati autofirmati o le CA principali private siano più sicuri delle CA principali pubbliche pre-attendibili; a condizione che abbiate motivo di fidarsi della catena di certificati privati e di un canale sicuro per riceverla. Ovvero: affidati solo ai certificati autofirmati di cui hai motivo di credere. Dovrai eliminare tutte le altre CA principali pre-trusted.

Forse sul computer sono presenti due istanze del browser con il marchio diverso. Uno per comunicazioni sicure usando solo una piccola serie di CA radice verificate; e un'altra istanza del browser vanilla per comunicazioni non sicure.

Inizialmente la crittografia asimmetrica (coppie di chiavi pubbliche / private) avrebbe dovuto implicare qualche forma di fiducia più diretta, come la popolarità delle parti fisiche della firma delle chiavi negli anni '90. Un approccio esatto e attuabile non era stato pienamente sviluppato prima che Internet esplodesse a metà degli anni '90.

Poiché queste reti fisiche di fiducia erano considerate non lavorabili per l'e-commerce su distanze nazionali o internazionali, accettammo la creazione di società che agissero come CA-Root "affidabili" per il resto della comunità imprenditoriale; presumibilmente in grado di essere citato in giudizio se hanno firmato certificati che non avevano verificato. Mentre questa è una soluzione (per lo più adeguata) per citizen<->business di fiducia per scopi di eCommerce; non fa nulla per la protezione contro le entità con le risorse e i poteri legali per intercettare e costringere le autorità di certificazione commerciale.

Per parafrasare: la migliore bugia che l'NSA * abbia mai detto è che la loro spionaggio non esiste o non funziona.

La conservazione dei dati lo porta a un livello completamente nuovo.

Personalmente, sin da quando ho letto La luce degli altri giorni , ho assorbito subliminalmente l'idea che nulla è veramente privato . Si tratta solo di quanto siano interessanti le Potenze che sono in te, di cosa hanno a disposizione e se esiste una democrazia sana per tenerli sotto controllo.

_{* o [inserisci agenzia di spionaggio preferita qui]}

Tutti gli altri qui hanno perfettamente ragione, ma ecco una semplice risposta diretta alla tua domanda.

Se è possibile comunicare con il proprietario del server out-of-band la prima volta che si accetta un certificato autofirmato e verificare che sia il loro certificato e solo riconoscere tale certificato per le future connessioni al proprio server, quindi in teoria tale impostazione potrebbe essere più sicura di un tradizionale certificato firmato da una CA. Lo scenario di trasporto dell'unità USB funzionerebbe come comunicazione out-of-band qui, purché si possa essere certi che l'unità USB non sia stata compromessa in alcun modo.

In tal caso, puoi farlo se il certificato è firmato da una CA o autofirmato e se quel certificato è sempre "bloccato" dal tuo browser (o nella tua mente; quindi dovresti controllare che sia la stessa firma per ogni visita), quindi puoi essere relativamente sicuro che nessun MitM sta succedendo. Ciò implica in anticipo la necessità di parlare e fidarsi di ogni singolo operatore di server, e spesso ciò non è fattibile.

Questo scenario richiederebbe anche un canale di revoca fuori banda, nel caso in cui un'entità ostile si intrometta nel proprio server e rubi la propria chiave privata. E se dici "bene, cosa succede se l'operatore del server non è a conoscenza del compromesso della chiave privata?" allora non si può fare molto; questo è un problema che SSL / TLS non può impedire in generale.

È più sicuro utilizzare un certificato aggiunto che semplicemente affidarsi a CA sigining. Questo è indipendente dal fatto che il certificato sia autofirmato o firmato da una CA.

Tuttavia, è necessario garantire la distribuzione del pinnng: -)

Per il caso in cui stai distribuendo un "browser sicuro" in CD, puoi installare una scorciatoia con una riga di comando come «Twitter come un capo» di link

(attenzione: le attuali versioni di Chrome non supportano la proprietà public_key_hashes in HSTS, che viene utilizzata in quella riga di comando per bloccare il certificato)

Avere solo un certificato autofirmato non lo rende più sicuro. Dopo che è stato compromesso, devi dire a tutti i tuoi clienti che la connessione non è più sicura e che non dovrebbero più fidarsi di essa, distribuire il nuovo certificato e devi tenere le dita incrociate che tutti i tuoi clienti siano avvisati in tempo.

Se vuoi andare in questo modo, devi costruire la tua CA con il tuo certificato di root privato (generato su una macchina che non è mai connessa a Internet). Dovresti tenere la chiave su una chiavetta USB solo e metterla in un caveau e toglierla solo se hai bisogno di emettere un nuovo certificato (richiesta) (di nuovo, fallo solo su un computer che non ha mai visto il world wide web) . Avere una CA ti dà la possibilità di creare nuovi certificati quando ne hai bisogno. Quindi configura un server OCSP in modo che i client possano controllare su richiesta (se è il tuo software client, devi applicare il controllo OCSP prima di qualsiasi connessione) se qualche certificato è stato revocato.

Quando tutto è impostato e funzionante, devi sperare che nulla vada storto (i tuoi server vengono violati). Ma è un sacco di lavoro, e tenerlo sicuro non è probabilmente economico.