Ho difficoltà a capire perché dobbiamo acquistare certificati SSL quando possiamo generarli localmente usando openSSL. Qual è la differenza tra il certificato che acquisto e un certificato di prova che generi localmente? È solo una grande truffa?
Ho difficoltà a capire perché dobbiamo acquistare certificati SSL quando possiamo generarli localmente usando openSSL. Qual è la differenza tra il certificato che acquisto e un certificato di prova che generi localmente? È solo una grande truffa?
Risposte:
Una sola parola: fiducia. Il certificato SSL di un provider di cui il tuo browser si fida significa che hanno almeno fatto una verifica di base per dire che sei chi dici di essere.
Altrimenti potrei creare i miei certificati per google.com o yourbank.com e fingere di essere loro.
I certificati a pagamento non forniscono alcun livello aggiuntivo di crittografia rispetto all'auto-firma (di solito). Ma un certificato autofirmato provocherà un errore nel browser.
Sì, parti di SSL sono una truffa (un certificato verisign contro una geotrust in cui verisign sono fino a 100 volte più costosi) ma non tutto.
Se si tratta di elementi interni, non è necessario un certificato a pagamento in quanto è possibile utilizzare i propri metodi di attendibilità (ad es. Non fare nulla o forse solo il controllo delle impronte digitali).
L'intero punto di un certificato SSL è che il browser ha un ragionevole grado di fiducia nella chiave pubblica del server per le transazioni HTTPS.
Innanzitutto, esploriamo cosa accadrebbe se non utilizzassimo i certificati. Al contrario, il server invierebbe la chiave pubblica in testo normale e il browser avvierebbe la comunicazione crittografata utilizzandola (la prima cosa da fare sarebbe crittografare la propria chiave pubblica e inviarla in modo sicuro). E se io e l'attaccante mi fossi incastrato nel mezzo? Potrei sostituire la tua chiave pubblica al volo con la mia, avere una connessione crittografata con il browser, decrittografare tutto ciò che ricevo, crittografarlo con la tua chiave pubblica e inviarlo (e viceversa per il traffico di tipo risposta). Nessuna parte noterebbe la differenza, poiché nessuno conosceva in anticipo le chiavi pubbliche.
OK, quindi abbiamo stabilito che abbiamo bisogno di un modo per il browser di fidarsi della mia chiave pubblica. Un modo per farlo sarebbe quello di memorizzare tutte le chiavi pubbliche registrate nel browser. Naturalmente, ciò richiederebbe un aggiornamento ogni volta che qualcuno registrava una chiave pubblica e questo portava a gonfiarsi. Si potrebbe anche tenere le chiavi pubbliche nelle mani dei server DNS 1 , ma anche i server DNS possono essere falsificati e il DNS non è un protocollo sicuro.
Quindi l'unica opzione rimasta è "concatenare" la fiducia attraverso un meccanismo di firma. Il browser memorizza i dettagli di alcune autorità di certificazione e il certificato verrà inviato insieme a una catena di altri certificati, ognuno dei quali firma il successivo e passa alla CA principale / attendibile / integrata. È compito della CA assicurarsi che il dominio appartenga a te prima di firmare un certificato.
Dal momento che essere una CA è un'azienda, fanno pagare per questo. Alcuni più di altri.
Se hai creato il tuo certificato, otterrai un errore simile a:
Non esiste alcun valore per un certificato non firmato. È come prendere una matita e un opuscolo, disegnare un passaporto che afferma che sei Barack Obama. Nessuno si fiderà di questo.
1. Dopo tutto, la tua voce DNS viene creata quando registri un dominio. L'uso di un protocollo più solido che ti consenta di registrare contemporaneamente le chiavi pubbliche sarebbe un concetto interessante.
La risposta alla tua domanda dipende dal tuo pubblico: poiché l'intero sistema di certificati si basa sulla "fiducia", i tuoi utenti devono avere la disponibilità per provare i certificati stessi o fidarsi di una terza parte che ha fatto questi controlli e mostra il successo firmando il tuo certificato. Il termine "per provare i tuoi certificati" che ho usato è un po 'impreciso: la versione lunga dovrebbe essere: "per dimostrare che sei il proprietario del certificato e sei autorizzato a usarlo".
Se tutti i tuoi utenti ti conoscono personalmente e hanno la capacità tecnica di provare che il tuo certificato è stato emesso da te stesso, non è necessario utilizzare un certificato da un fornitore "certificato". In questo caso, il certificato autofirmato potrebbe persino essere migliore di quello di uno dei provider.
Ma nella maggior parte dei casi, gli utenti non possono eseguire questo processo da soli. Qui entrano sul mercato quei provider SSL. Offrono il servizio per eseguire questi controlli ed esprimere il risultato dei controlli firmando il certificato. Ma un fatto importante da tenere a mente è: firmando un certificato, un provider SSL dichiara di aver verificato l'identità degli emittenti di certificati in base alla propria politica di firma. Quindi l'utente deve decidere se questa politica è abbastanza precisa e se può fidarsi del provider.
Il punto principale è che, se il certificato è auto-generato, gli utenti comuni non hanno modo di verificarne la veridicità. Per un certificato acquistato, suppongono di aver verificato almeno che ciò che è stampato all'interno del certificato sia corretto. Idea: se inserisci il telefono e l'indirizzo nel certificato, la CA suppone di verificarlo, ma raramente lo fa.
Inoltre, i certificati di acquisto sono tracciabili, il che significa che l'utente può sempre rintracciare la provenienza del certificato, mentre un certificato autofirmato è solo un'identità casuale.
Per molti sistemi, in passato era richiesta la "firma del codice" da un'autorità di certificazione autorizzata, che è guidata dai criteri, ma poiché i certificati autofirmati sono così numerosi, ora non è più applicabile al 100%.
Non ci sono differenze tecniche (le tue non sono meno sicure) solo organizzative: il certificato della CA non fa parte dell'installazione standard del browser. Questo rende scomodo per la maggior parte delle persone connettersi al proprio certificato. Ma non avrebbe senso acquistare un certificato per una rete interna.
Si riduce alla fiducia. Un provider SSL "certificato" è presumibilmente affidabile (sebbene possa essere manipolato) rispetto a un certificato autofirmato dal server stesso.
Se la tua organizzazione ha la propria firma del certificato, questo è perfettamente accettabile e non dovrebbe causare alcun avviso per gli utenti (a condizione che stiano usando il tuo portachiavi cert come fonte attendibile) ma creerà comunque un avviso se provi a usarlo esternamente.
In conclusione: per uso interno va bene, se lo stai fornendo esternamente a un cliente pagante, non avere avvertimenti è tranquillità. Ti sentiresti più sicuro se le tue transazioni finanziarie passano attraverso una fonte accreditata o un ragazzo in piedi sulla strada che non conosci davvero?
Di recente, LetsEncrypt ha annunciato la disponibilità dei propri strumenti da riga di comando per generare certificati validi.
Nessuna email di convalida, nessuna modifica complicata della configurazione, nessun certificato scaduto che rompe il tuo sito web. E, naturalmente, poiché Let's Encrypt fornisce certificati gratuitamente, non è necessario organizzare il pagamento.
Per coloro che si chiedono se tali certificati sono validi nei principali browser, la risposta è Sì:
Il 19 ottobre 2015 i certificati intermedi sono stati firmati da IdenTrust, facendo sì che tutti i certificati emessi da Let's Encrypt siano considerati affidabili da tutti i principali browser. [20]
..... L'8 marzo 2016, Let's Encrypt ha emesso il suo milionesimo certificato dopo sette mesi di esistenza. [39]
Il 12 aprile 2016 Let's Encrypt ha lasciato la Beta.
Link per amministratore di sistema e sviluppatori: https://letsencrypt.org/getting-started/
Nell'era della tecnologia blockchain e dell'eliminazione dei sistemi fiduciari di terze parti, era giunto il momento dell'emissione di certificati costosi da parte di alcune autorità scelte.
Sebbene Letsencrypt non abbia nulla a che fare con la tecnologia blockchain, è un inizio nella giusta direzione. Si spera che la necessità di pagare una tariffa elevata ogni anno a un'autorità di certificazione costosa stia per finire logicamente.
In poche parole, un certificato SSL autofirmato non significa nulla. Non ha valore per il mondo esterno. È come dire "Possiedo la Spagna". Potresti pensare onestamente di sì, ma nessuno riconoscerà il tuo reclamo.
Un'analogia simile sarebbe inventare qualcosa e poi rivendicare il possesso dei diritti sull'invenzione, ma se non si registra un brevetto in ufficio, sarà difficile crederci, adesso?
Il punto centrale di un certificato è che è firmato da un'autorità di cui la gente si fida. Se un sito Web ha un certificato SSL valido, significa che il proprietario si è preso la briga di registrare il proprio sito Web, pagare il certificato SSL e ottenere la certificazione ufficiale da qualche autorità di certificazione del mondo reale, quindi probabilmente non è un sito Web di phishing a buon mercato. D'altra parte, se ti fidi dei certificati autofirmati, allora il sito Web di phishing potrebbe semplicemente generare il suo certificato contraffatto (che accetteresti felicemente) e voilà.
Naturalmente, se si tratta di una rete interna su una intranet privata, probabilmente ti fidi già dell'altro, quindi in questo caso un certificato autorevole non aggiunge davvero nulla, quindi puoi tranquillamente ignorare le luci rosse luminose che il tuo browser ti lancerà . Lo stesso vale per i piccoli siti Web in cui si desidera comunque crittografare il traffico client-server ma il modello di minaccia non garantisce un'autenticazione forte, nel qual caso è possibile cavarsela con un certificato autofirmato e accettare il (trascurabile dal modello di minaccia) rischio di MITM.
Il che è probabilmente soddisfacente considerando quanto costosi possano essere i certificati SSL affidabili.
In altre parole, un certificato autofirmato equivale a dire "Dichiaro di essere quello che sono - fidati di me !".
Per farla breve e semplice ... e smantellare un po 'quello che è stato detto ...
Non è un problema di crittografia, con strumenti adeguati puoi generare un certificato localmente con il tipo di crittografia che desideri ... e ottenere un certificato valido.
Il vantaggio principale che hai quando acquisti un certificato da un'entità di certificazione è che durante il periodo di validità del certificato mantengono nei loro server un meccanismo per convalidare tutto ciò che hai firmato con la tua certificazione online ...
Non è necessario che il PC sia collegato per la verifica e la convalida dei prodotti digitali con il certificato ... è necessario reindirizzare la convalida all'entità di certificazione.
Mi dispiace partecipare a questa discussione così tardi - ho pensato che valesse la pena sottolineare che utilizzando openssl è possibile impostare una CA privata, con il proprio certificato radice, e quindi creare certificati server firmati da questa CA. A condizione che il certificato radice della CA sia importato nel browser e al browser venga detto di accettarlo, il certificato del server verrà accettato senza commenti. (Ovviamente questa è un'opzione praticabile solo se la comunità di utenti è piccola e tutti gli utenti si conoscono personalmente.)
Ti fideresti di qualcuno che dice "Fidati di me"? La fiducia nell'autenticità può essere fornita solo da un '"Autorità fidata", di cui tutti si fidano. Questo è il motivo per cui dobbiamo guadagnare un sacco di soldi per i certificati.