Perché https autofirmato è meno affidabile di http non criptato?

8

Non sarebbe inverosimile supporre che almeno il 50% del traffico web possa essere intercettato nel 2014.

Tuttavia, un'ipotesi di attacchi di intercettazione attiva è probabilmente inferiore di un ordine di grandezza, probabilmente ben al di sotto dello 0,5%, e, apparentemente, molti di essi sono fatti dai governi, che potrebbero potenzialmente ha comunque il controllo delle autorità di certificazione , quindi il valore di avere una catena di CA attendibile è discutibile.

Poiché la maggior parte del traffico viene intercettata solo passivamente, il che significa che la crittografia senza autenticazione ti permetterà di allontanarti da survaillance e di preservare il tuo diritto alla privacy nel 99,9% di questi casi, perché i produttori di browser e l'industria https promuovono ancora efficacemente no crittografia http sui certificati https autofirmati per gli appassionati di Web come me?

Le mie e-mail su una dozzina di domini self-hosted sono crittografate gratuitamente (SMTP STARTTLS), senza bisogno di installare nuovi certificati ogni X mesi, e senza che le persone che mi scrivono ricevono mai degli avvisi.

(L'uso efficace di ssh allo stesso modo non richiede il pagamento di alcun pagamento a nessuno.)

Perché i miei siti web non commerciali e le proprietà web non possono fare lo stesso?

    
posta cnst 29.06.2014 - 03:41
fonte

4 risposte

6

Since most traffic is intercepted merely passively, meaning that encryption without authentication will let you get away from surveillance ....

Solitamente è facile intercettare il traffico attivamente se ci si trova all'interno della stessa LAN (W), ad es. eseguendo spoofing ARP o tecniche simili. E, per le parti che sono in grado di intercettare il traffico passivamente su Internet più ampia, di solito è anche possibile cambiarlo o reindirizzare in qualche modo (come con lo spoofing del DNS) e ci sono persino ISP che modificano il traffico per iniettare annunci ecc.

È già difficile per le persone comprendere la differenza tra semplice HTTP (nessuna crittografia), HTTPS "semplice" e HTTPS "migliore" (ad esempio certificati di convalida estesi). Quello che proponi qui è un altro livello di sicurezza, che è leggermente migliore di nessuna crittografia e di gran lunga peggiore del semplice HTTPS, perché fidarsi ciecamente di qualsiasi certificato peer che ottieni ti rende solo un facile attacco man-in-the-middle.

Naturalmente, se solo poche persone utilizzano un determinato servizio è possibile utilizzare certificati autofirmati o tecniche simili. Ma in questo caso è necessario verificare il certificato o la chiave pubblica off-band, come con l'acquisizione dell'impronta digitale del certificato o della chiave pubblica in un altro modo e controllandola con l'impronta digitale presentata dalla connessione. Funziona se hai il tuo server di posta o se fai ssh con gli host che controlli. Tuttavia, poiché di solito non disponi di un'infrastruttura consolidata e sicura per la verifica off-band, questo non funzionerà per un pubblico più vasto.

    
risposta data 29.06.2014 - 04:33
fonte
5

Attualmente, abbiamo solo due protocolli specificati: HTTP semplice e HTTPS che richiede certificati validi. Se dicessimo semplicemente "HTTPS è ora possibile con certificati autofirmati", il tuo browser non potrebbe distinguere se un sito che stai tentando di visitare ha un certificato autofirmato perché è previsto o perché sei stato attaccato. Quindi, diminuirebbe la sicurezza.

Potremmo definire un nuovo schema di URL, ad es. httpe, dove sono previsti certificati autofirmati. Richiederebbe tutti i browser per implementarlo prima di essere utile.

Utilizzare HTTPS solo come linea guida e semplicemente non mostrare l'icona del lucchetto se si incontrano certs autografati, sarebbe estremamente pericoloso: Immagina che la tua applicazione web invii i dati confidenziali a un URL https: non vuoi che quelle richieste vengano passate se non è possibile stabilire una connessione sicura. Quindi, anche se lo volessimo, spostarci da https = sia criptato che autenticato non avrebbe funzionato.

Potremmo anche chiedere ai server HTTP prima della richiesta effettiva se supportano la crittografia opportunistica e, se dicono che lo fanno, eseguire l'aggiornamento a TLS mentre continuano a mostrare URL HTTP. Qualcosa del genere viene proposto per HTTP 2 qui e qui .

Nota a margine, StartSSL offre certificati gratuiti per uso non commerciale / non sensibile (questa restrizione è nascosta nella loro politica , sezione 3.1.2.1).

    
risposta data 29.06.2014 - 21:46
fonte
2

Concorda con @SteffenUllrich che di per sé ci sono pochi modelli di minacce a cui questo effettivamente protegge. Praticamente tutte le situazioni che è possibile annusare passivamente possono anche essere annusate attivamente se si utilizza HTTPS non attendibile. L'uso di questo schema con qualcosa come Moxie Marlinspikes convergence ( www.convergence.io ) sarebbe efficace, tra l'altro, che cerca di sostituire l'attuale modello di CA con qualcosa di più robusto. Ciò mi farebbe sentire più a mio agio, anche se ritengo che abbia i suoi difetti (quelli difetti sono sminuiti da quelli dell'attuale infrastruttura CA che è per la maggior parte del tutto insufficiente).

E per rispondere alla tua domanda, l'autofirmato è MEGLIO di un semplice HTTP, ma i guadagni di sicurezza sono in realtà molto piccoli perché non c'è modo di verificare l'identità del server a cui si connette il client.

    
risposta data 30.06.2014 - 11:05
fonte
1

Questa è la tua dichiarazione, i certificati firmati autofirmati o certificati scaduti dalla CA sono ancora affidabili di nessuno (HTTP).

Protocollo di sicurezza il più sicuro al minimo: 1. HSTS 2. HTTPS 3. HTTP

Chi ha firmato il tuo certificato non è correlato alla sicurezza? Tutto dipende da chi può decrittografarlo.

La crittografia è definita dall'autenticazione, non ripudio, integrità e riservatezza.

Un certificato autofirmato può essere creato da chiunque, il che non garantisce il non ripudio (può essere un'identità falsa).

In teoria, questo è meno affidabile di un certificato firmato. I certificati CA (firmati) sono più sicuri in teoria, ma possono essere facilmente aggirati: c.f. SSLStrip o SSLSnif link

HTTP (S) è un protocollo stateless, puoi manipolare i frame POST, GET, PUT e anche creare cookie. HTTPS offre la crittografia mentre HTTP non lo fa, quando si tratta di trasportare informazioni critiche indipendentemente dal certificato (firmato, scaduto, autofirmato) è ancora preferibile rispetto a nessuna crittografia.

Ecco un'alternativa a cui potresti essere interessato: link

    
risposta data 30.06.2014 - 10:48
fonte