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

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.

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).

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.

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