Qual è la differenza tra http e https con un certificato SSL autofirmato?

19

Un mio collega mi ha detto che non vede perché c'è un avvertimento quando visita un sito Web HTTPS con un certificato autofirmato che dice che la sicurezza potrebbe essere compromessa, ma non c'è alcun avviso quando si visita un "normale" Sito Web HTTP, anche se la sicurezza potrebbe essere compromessa.

Non sono riuscito a pensare a un argomento contro questo (capisco la differenza tra certificati autofirmati e certificati CA).

Quindi, qual è il rischio per la sicurezza che si ha quando si visita un sito Web HTTPS con un certificato autofirmato o scaduto, che non si ha quando si visita un sito Web HTTP?

Vorrei aggiungere qual è il ragionamento alla base del messaggio di avviso del browser per i certificati autofirmati ma non c'è nessuno per HTTP , ma posso già pensare a diversi "non preoccupare gli utenti di 90% del web "essere uno.

Nota

Sono a conoscenza di molto simile domanda , ma non risponde alla mia domanda specifica.

Aggiornamento

Google ha realizzato questo paradosso e presto contrassegnerà tutte le connessioni HTTP-non-S come non sicure: link

    
posta thomasb 28.08.2015 - 16:31
fonte

5 risposte

34

Lo scopo dell'avvertenza è che utilizzando HTTPS ci si aspetta una sicurezza adeguata, ma un certificato autofirmato o scaduto presenta delle vulnerabilità di cui l'utente deve essere a conoscenza.

Il "rischio" è che si pensa di essere adeguatamente protetti, ma non sono completamente protetti, al contrario di HTTP, dove si sa che non esiste affatto alcuna crittografia.

Non ci sarebbe un avvertimento per HTTP, perché non c'è sicurezza (cioè crittografia) da compromettere.

    
risposta data 28.08.2015 - 16:40
fonte
25

Differenza di sicurezza

In primo luogo, parliamo di SSL (ora chiamato TLS a proposito), che aggiunge la "S" alla fine di HTTP S e si occupa di " proteggere la comunicazione ". L'indizio per rispondere a questa domanda è davvero comprendere appieno cosa intendiamo per "assicurare la comunicazione".

SSL, indipendentemente dal fatto che si tratti di un certificato autofirmato o di un certificato firmato da un'autorità di certificazione, garantirà che la comunicazione tra l'utente e l'host remoto rimanga riservata e che nessuno possa manomettere i dati scambiati .

L'avvertimento quindi non riguarda questo.

Tuttavia, come puoi sicuro che questo host remoto che risponde alle tue richieste è davvero quello che ti aspetti che sia? Con siti Web pubblici, per i quali non hai un modo diretto per autenticare il certificato solo da te stesso, è semplicemente impossibile. Arriva una CA attendibile esterna: fidandosi di una CA, si presuppone che tutti i certificati da lui firmati vengano utilizzati solo a fini legittimi per proteggere il traffico con i server esplicitamente menzionati nel certificato.

Questo è tutto questo avviso: il tuo browser ti avverte che, mentre la comunicazione stessa è protetta, non ha un modo automatico per autenticare il certificato da solo e quindi fa affidamento su di te per accettarlo o rifiutarlo.

Se il certificato autofirmato è associato a uno dei tuoi server, dovresti essere in grado di procedere con questa autenticazione manuale: dovresti essere in grado di controllare l'impronta digitale del certificato, o almeno devi sapere se il certificato è stato cambiato recentemente o no.

Una volta completata l'autenticazione manuale, il browser ti offre la possibilità di "ricordare" questo certificato: questo significa che il browser associerà questo certificato autofirmato all'host dell'URL e non fornirà alcun avviso in futuro poiché, ora , il browser ha un modo automatico per autenticare il certificato.

Tuttavia, non appena il certificato autofirmato verrà modificato sul server, il browser visualizzerà nuovamente l'avviso e tornerà a essere l'utente finale per determinare se questa modifica del certificato è normale e se il il nuovo certificato presentato dal server è effettivamente autentico.

Differenza UX

Fino ad ora la mia risposta non riguardava l'aspetto dell'interfaccia utente del browser della tua domanda.

Ho trovato il modo predefinito in cui i browser informano la sicurezza corrente dell'utente in gran parte inefficace. Solo per gli utenti non ti interessa il lucchetto e non si noti quando manca la sicurezza SSL . Anche gli utenti che si preoccupano non hanno accesso alle informazioni corrette (nulla impedisce a un sito Web di mostrare un certificato di convalida esteso per configurare il loro sito Web utilizzare sistemi di crittografia scadenti o deboli o affidarsi a contenuti di terze parti meno sicuri: l'interfaccia del browser predefinito sarà comunque felice e mostrerà la barra di sicurezza "top-notch security".

Si spera che, a seconda del browser utilizzato, alcuni plugin possano tentare di rimediare a questa situazione. Su Firefox, hai SSLeuth che per impostazione predefinita aggiungerà una nuova area di notifica a sinistra o la barra dell'URL (accanto al lucchetto quando ce n'è una)

Questa nuova area di notifica ha le seguenti proprietà:

  • Il colore dello sfondo varia dal rosso (nessuna sicurezza: HTTP), all'arancione (impostazione di sicurezza scarsa) al blu e al verde (buona e migliore sicurezza secondo le migliori pratiche attuali).
  • Un'opzione consente di estendere questo colore all'intera barra dell'URL, quindi i siti Web HTTP visualizzeranno ora una barra dell'URL completamente rossa,
  • Finalmente viene visualizzato un punteggio (tra 0 e 10) per mostrare una stima dell'attuale livello di sicurezza SSL / TLS. Prende in considerazione diversi criteri, tra cui il tipo di certificato (autofirmato, firmato dalla CA, certificato di convalida estesa), la configurazione crittografica utilizzata, la sicurezza del contenuto di terze parti, ecc. Cliccando sull'area di notifica vengono forniti tutti i dettagli del punteggio, principalmente utile quando il risultato non è quello atteso (ovvero " Perché il mio sito web della banca ha concesso una barra URL arancione? ").
risposta data 28.08.2015 - 17:03
fonte
3

Senza avvisi per cose come certificati autofirmati o scaduti, selezioni di suite di crittografia inappropriate e altre configurazioni HTTPS errate, la presentazione dello stato di sicurezza di un sito Web all'utente diventa binaria: o hai HTTPS sul sito o non lo fanno. Ciò nasconderebbe una serie di sfumature che possono influenzare in modo significativo esattamente quanto la "S" in "HTTPS" ti stia davvero proteggendo.

In un'implementazione HTTPS corretta, il certificato del sito è firmato da una terza parte che il sistema client considera affidabile. Questo garantisce al cliente che il contenuto viene consegnato dal sistema che si aspettano, e non c'è nessuno nel mezzo.

Il problema con un certificato autofirmato è che chiunque può crearne uno. Quindi, quel certificato potrebbe anche essere generato da un sistema che agisce come Man-in-the-Middle che sta intercettando e forse anche manipolando i dati che vanno avanti e indietro tra te e il sistema fidato. Se il sistema fidato utilizza normalmente un certificato autofirmato e non hai convalidato personalmente quel certificato fuori banda o durante una precedente connessione affidabile, non conoscerai mai la differenza.

Com'è diverso dal normale HTTP? Dal suo punto di vista, potrebbe sembrare che non lo sia: in entrambi gli scenari, un MitM può facilmente visualizzare e manomettere la connessione e non ci si accorge. Tuttavia, l'utilizzo di HTTPS con un certificato autofirmato ti offre qualcosa che HTTP non può: la certezza che i tuoi dati siano ancora crittografati durante la trasmissione, nonostante chiunque sia nel mezzo. A seconda dell'ambiente (ad es .: Wi-Fi pubblico densamente popolato), questo potrebbe ridurre drasticamente il pubblico che ha accesso ai tuoi dati, anche se potrebbe esserci un MitM in gioco.

Puoi controllare la mia risposta su un'altra domanda correlata per maggiore copertura su questo. L'articolo di Troy Hunt, "SSL non riguarda la crittografia" potrebbe essere di interesse per te, anche se forse non molto utile per la tua parte del dibattito qui.

    
risposta data 28.08.2015 - 16:57
fonte
1

Queste risposte sono fantastiche. Ma spesso devo dare una risposta semplificata senza tutto il gergo.

HTTP - Non è crittografato e i dati inviati sulla linea potrebbero essere facilmente letti.

HTTPS: crittografato e verificato da una parte fidata, i dati vengono gestiti dalla fonte corretta.

HTTPS (autofirmato) - È crittografato ma non c'è alcuna verifica da parte di un soggetto fidato che sia gestito dalla fonte corretta.

Ecco perché i certificati autofirmati ricevono l'avviso molto importante. Anche se ciò non significa che il certificato non sia sicuro, il browser non può confermare che il certificato sia sicuro nel suo utilizzo / trasmissione dei dati. Senza questo importante avviso un truffatore / hacker potrebbe sostituire il certificato con uno di loro e non saresti mai più saggio.

    
risposta data 29.08.2015 - 00:23
fonte
0

Visitare un URL https porta con sé un'aspettativa di sicurezza. Visitare un URL http non lo fa. Questo non vale solo quando si digitano manualmente gli URL, ma forse più importante quando si seguono i link e si inviano i moduli.

Una solitaria sarebbe quella di aggiungere un altro schema di url per "crittografato ma non autenticato" ma anche se tutti i browser avessero iniziato a supportarlo domani ci sarebbe voluto molto tempo prima che fosse abbastanza diffuso da permettere ai siti web di fare affidamento su di esso. Sarebbe anche potenzialmente difficile spiegare le differenze di sicurezza agli utenti.

Un'altra soluzione sarebbe quella di fare encyrption opertunistico sotto lo schema http url. Anche se ottenere supporto nei browser sarebbe una lotta in salita.

    
risposta data 18.04.2016 - 00:31
fonte

Leggi altre domande sui tag