Perché un certificato SSL non firmato viene trattato peggio di nessun certificato SSL?

19

Se visualizzo un sito con un certificato SSL non firmato o autofirmato, il mio browser mi avvisa. Tuttavia, lo stesso browser non ha problemi a consentire l'invio di credenziali attraverso pagine non protette.

Perché il certificato autofirmato è trattato peggio del non avere certificato?

— Macha
fonte

16

Ci sono molte persone che ritengono che questo sistema sia rotto.

Ecco la logica alla base del perché il tuo browser ti darà un avviso così allarmante quando un certificato SSL non è valido:

Uno degli scopi di progettazione originali dell'infrastruttura SSL era fornire l'autenticazione dei server Web. Fondamentalmente, se vai su www.bank.com, SSL consente al server web che risponde di dimostrare che, di fatto, appartiene alla tua banca. Ciò impedisce a un impostore di manipolare DNS o utilizzare un altro metodo per far rispondere un server dannoso.

Il "Trust" in SSL è fornito dal fatto che una terza parte attendibile (aziende come VeriSign e Thawte Consulting) firmino il certificato, indicando che hanno verificato che è di proprietà di chi afferma di essere (in teoria visitando l'amministratore IT in persona o un altro metodo che crea fiducia diretta, anche se le prove dimostrano che in realtà sono piuttosto vaghe al riguardo - tutto ciò che serve per ottenere un certificato SSL firmato è spesso un numero 800 e un po 'di abilità recitazione).

Quindi, se ti connetti a un server Web che fornisce un certificato SSL, ma non è firmato da una terza parte attendibile, in teoria ciò potrebbe significare che stai comunicando con un impostore che finge di essere un server appartenente a un'altra organizzazione .

In pratica, un certificato autofirmato significa in genere solo che l'organizzazione che esegue il server ha scelto di non pagare per un certificato firmato (possono essere piuttosto costosi, a seconda delle funzionalità desiderate) o mancava dell'esperienza tecnica per configurarne uno ( alcune soluzioni per le piccole imprese offrono un meccanismo con un clic per un certificato autofirmato, ma ottenere un certificato attendibile richiede ulteriori passaggi tecnici).

Personalmente ritengo che questo sistema sia guasto e che comunicare con un server che non offre crittografia sia molto più pericoloso che comunicare con un server che offre SSL con un certificato autofirmato. ci sono tre ragioni per cui i browser non si comportano in questo modo:

Le comunicazioni non crittografate sono la norma su Internet, quindi se i browser ti facessero fare clic su un avviso per visualizzare i siti Web che non offrono la crittografia, ti infastidirebbero rapidamente e disabiliterebbero l'avviso.
A causa dei terribili avvertimenti ai clienti, è anormale vedere un certificato autofirmato su un sito Web di produzione. Questo stabilisce un sistema che si autoalimenta: i certificati autofirmati sono sospetti perché sono rari, sono rari perché sospetti.
Questo mi suona cinico, ma ci sono aziende che trarranno molto profitto dalla firma dei certificati SSL ( tosse Verisign tosse ), quindi usano i white paper (un termine IT che significa "pubblicità lunga e noiosa") e altre pubblicazioni far valere l'idea che i certificati non firmati siano pericolosi.

— jcrawfordor
fonte

5

Senza una catena di fiducia, che è ciò che si ottiene con un certificato firmato da un'autorità di certificazione e non con un contratto autofirmato, non è possibile verificare che il server a cui ci si sta connettendo sia chi lo dice. I certificati autofirmati sono pericolosi nel senso che non forniscono alcun mezzo per consentire a un utente di verificare che i dati che stanno trasmettendo stiano raggiungendo la destinazione che sostengono. Le persone stanno iniziando a imparare a cercare "https" quando effettuano transazioni sicure, quindi avere un grande avvertimento su un certificato non valido o autofirmato è garantito al 100%, perché stanno perdendo uno dei principali vantaggi di SSL.

— MDMarra,

Non direi "rotto". Penso che il componente aggiuntivo Firefox Certificate Patrol sia molto più vicino all'implementazione corretta dei certificati e alla gestione della fiducia rispetto all'impostazione predefinita. Tuttavia, l'impostazione predefinita è migliore dell'ignorare completamente le reti fiduciarie.

— Slartibartfast,

4

@MarkM - La mia sensazione è che l'autenticazione non debba essere considerata il principale vantaggio di SSL. Non ho i dati per eseguire il backup, ma penso che molti più incidenti di sicurezza derivino da dati trasferiti su connessioni non crittografate (ad esempio, l'ingegnere di sicurezza di Facebook che ha rubato la password - ha annusato la password da una rete wifi , poiché l'accesso a Facebook non è crittografato) rispetto a MitM o agli attacchi impostori, che sono relativamente molto più complicati da implementare. L'attenzione all'autenticazione sulla crittografia in SSL è, come ho notato, precisamente ciò che crea questa situazione.

— jcrawfordor,

1

@MarkM - anche se c'è sicuramente un sovraccarico, che è una preoccupazione legittima, l'uso di certificati non firmati non stresserà le CA, in particolare perché una CA non sarebbe utilizzata per un certificato autofirmato. Inoltre, per le organizzazioni con una potenza sufficiente, non è un problema: considera che ora Google viene impostato automaticamente su https per Gmail e altri servizi. Capisco il tuo punto che senza autenticazione, l'utilità SSL è degradata. Il modello attuale non è ben progettato. Ciò di cui abbiamo veramente bisogno è un protocollo crittografato standard e un protocollo autenticato per usi più sicuri.

— pensa

5

Il significato più grande del mio punto, e NRHinkle ha detto direttamente questo, è che dobbiamo iniziare a considerare la crittografia e l'autenticazione come obiettivi separati e permettere che vengano raggiunti separatamente. Questi sono i difetti fondamentali con il sistema SSL in questo momento: 1) Vediamo la crittografia e l'autenticazione come inestricabilmente attaccati - per raggiungere uno, devi raggiungere l'altro. Fornire solo uno è "sospetto". 2) L'autenticazione deve essere ottenuta da un numero limitato di autorità di certificazione principalmente a scopo di lucro. In generale, le CA sono molto costose (Verisign ecc.) O molto ombreggiate (NameCheap ecc.)

— jcrawfordor,

6

L'invio di credenziali da una pagina all'altra sta fondamentalmente facendo HTTP POST. Non c'è nulla di speciale nell'invio di credenziali rispetto all'invio, ad esempio termini di ricerca tramite POST. Se qualsiasi post su una pagina non sicura attiverebbe un avviso, gli utenti verrebbero bombardati da avvisi inutili.

L'uso del canale sicuro indica l'intenzione del programmatore di proteggere il trasferimento. In questo caso, utilizzare l'avviso di certificato autofirmato è la cosa più giusta da fare.

— Miro A.
fonte

Abbastanza giusto per me.

— dag729,

È un dato di fatto, ricordo che almeno le vecchie versioni di Netscape Navigator hanno fatto apparire un avviso per ogni POST non crittografato. Certo, tutti li hanno disabilitati dopo cinque minuti, quindi credo sia per questo che l'hanno tolto ...

— sleske,

4

Non posso commentare, quindi posterò queste informazioni che completano le informazioni corrette dell'utente40350.

Tuttavia, lo stesso browser non ha problemi a consentire l'invio di credenziali attraverso pagine non protette.

Questo non è nemmeno vero. La maggior parte dei browser mostrerà un avviso come se stai per inviare dati tramite una connessione non protetta quando lo provi per la prima volta, ma puoi disattivarlo in modo che non venga più visualizzato, e scommetto che è esattamente quello che hai fatto ...

Miro A ha scritto:

L'invio di credenziali da una pagina all'altra sta fondamentalmente facendo HTTP POST. Non c'è nulla di speciale nell'invio di credenziali rispetto all'invio, ad esempio termini di ricerca tramite POST

Anche questo non è corretto, poiché i campi password sono ad esempio tag html speciali. Inoltre, etichette come "nome utente" e "password" tradiscono molto della loro sensibilità. Sarebbe perfettamente fattibile per i browser prendere in considerazione questo tipo di informazioni.

— ufotds
fonte

3

Le connessioni protette dal protocollo https: // sono indicate dal browser come "protette". Ad esempio, viene mostrato un piccolo lucchetto o parti dell'URL sono contrassegnate in verde.

Si suppone pertanto che l'utente abbia fiducia nel fatto che le pagine che sta visitando provengono effettivamente dall'URL che aveva inserito e non da qualcun altro.

Se non utilizza https: //, l'utente dovrebbe sapere che i dati inseriti non sono protetti e che il sito su cui sta navigando potrebbe essere impostato.

Un certificato autofirmato non garantisce - anche in questo caso l'aspettativa, che la pagina visitata non sia impostata, quindi non fornisce ulteriore sicurezza.

— usermac75
fonte

1

È necessario fare una distinzione tra un certificato attendibile (firmato da un'autorità di fiducia) e un certificato non attendibile. Altrimenti qualcuno potrebbe impersonare la tua banca (ad esempio) utilizzando un certificato autofirmato con relativa impunità.

In questo caso è preferibile un avvertimento in-face a uno sottile perché il rischio potenziale è relativamente alto. Le persone potrebbero fare clic su un collegamento HTTPS e nemmeno pensare che qualcuno potrebbe essere seduto in mezzo a monitorare la connessione. Se l'indicazione che il certificato non è attendibile è sottile (ad esempio un'icona rossa anziché verde, ecc.), Allora le persone potrebbero essere facilmente ingannate, rimuovendo i vantaggi di SSL.

— Slartibartfast
fonte

Non è facile impersonare una banca se si ha accesso al computer dell'utente e si modificano i loro certificati? Se il computer dell'utente non viene modificato, il browser Web non sarebbe in grado di modificare l'URL della pagina Web per affermare che si tratta della banca; e se ottengono un URL molto simile, possono comunque ottenere un certificato per quel sito Web e l'utente non si preoccuperà di chi è la pagina web firmata, vedranno solo che è https e si spera che l'URL non sia il URL della loro banca ...

— Dmitry,

Il vantaggio di SSL non è la fiducia nel fatto che il sito Web è quello che pensi che siano (questo è impossibile poiché un'applicazione di terze parti può modificare i tuoi certificati o la banca può essere hackerata); ma piuttosto confida che la comunicazione tra te e chiunque il sito pensi sia, è solo tra voi due e nessun altro può dare un senso a quella comunicazione. Non avere un certificato è peggio che averne uno autofirmato perché non importa con chi stai parlando, ciò che conta è che nessun altro dovrebbe essere in grado di intercettare ciò che stai dicendo.

— Dmitry,

Inoltre, come utente, so davvero chi è Verisign e perché dovrei fidarmi di loro? Il loro interesse a vendere certificati non è forse superiore a quello di ritenere i proprietari dei certificati responsabili per l'uso improprio delle informazioni che invii loro?

— Dmitry,

0

Sono stati elencati molti buoni motivi. Eccone un altro:

Pensa ai casi in cui una pagina Web sicura incorpora elementi da un'altra. Un utente malintenzionato è in grado di rilevare quali richieste sono per la pagina Web esterna (ad esempio osservando i tempi, deve venire prima) e quali sono per gli elementi interni. Poteva iniettarsi come MITM solo negli elementi interni, usare un certificato autofirmato e controllare parti della pagina. A meno che non sia stato presentato un avviso per gli elementi interni mediante SSL ma non utilizzando un certificato attendibile, la sicurezza della pagina esterna sarebbe compromessa.

Ecco un esempio realistico. Supponi di essere un fornitore e di avere un link "paga con PayPal". Fai clic su quello e lo so. Ti reindirizzo a PayPal e ti consento di ottenere la pagina PayPal legittima e sicura. Se guardo la tua rete, so che sarà la tua prima richiesta da PayPal, e subito dopo invierai la tua password. Quindi MITM submitcontiene il tuo indirizzo email e la tua password, sostituendo il mio certificato autofirmato con quello di PayPal.

Vedi come viene compromessa la sicurezza della pagina esterna non avvisando se il certificato della pagina interna è autofirmato? Quindi deve avvertire sui certificati autofirmati che provengono dai collegamenti.

E, naturalmente, se si inserisce httpsmanualmente, deve avvisarti. Perché ti aspetti che sia sicuro.

— David Schwartz
fonte

-1

Quando man in the middle attack viene eseguito in https: // website l'avvertimento è solo un'indicazione di qualcosa di sbagliato per l'utente medio. Pertanto è una parte molto importante della sicurezza HTTPS.

La buona domanda è perché la crittografia parzialmente non sicura non è possibile ad esempio tramite HTTP.

— Cmazay
fonte