Perché HTTP è ancora comunemente usato, invece cosa direi HTTPS molto più sicuro?
SSL / TLS ha un leggero sovraccarico. Quando Google ha passato Gmail a HTTPS (da una funzione opzionale all'impostazione predefinita), ha scoperto che il sovraccarico della CPU era di circa + 1% e il sovraccarico della rete + 2%; vedi questo testo per i dettagli. Tuttavia, questo è per Gmail, che consiste di dati privati, dinamici, non condivisi e ospitati sui sistemi di Google, accessibili da qualsiasi luogo con una latenza molto bassa. Gli effetti principali di HTTPS, rispetto a HTTP, sono:
L'avvio della connessione richiede alcuni roundtrip extra della rete. Poiché tali connessioni sono "mantenute in vita" e riutilizzate quando possibile, questa latenza aggiuntiva è trascurabile quando un determinato sito viene utilizzato con interazioni ripetute (come è tipico di Gmail); i sistemi che servono per lo più contenuti statici potrebbero trovare il sovraccarico della rete non trascurabile.
I server proxy non possono memorizzare nella cache le pagine servite con HTTPS (poiché non vedono nemmeno quelle pagine). Anche in questo caso, non c'è niente di statico da memorizzare nella cache con Gmail, ma questo è un contesto molto specifico. Gli ISP amano molto il caching poiché la larghezza di banda della rete è la loro forza vitale.
HTTPS è HTTP in SSL / TLS. Durante l'handshake TLS, il server mostra il suo certificato, che deve designare il nome del server previsto - e ciò si verifica prima la richiesta HTTP stessa viene inviata al server. Ciò impedisce l'hosting virtuale, a meno che non venga utilizzata un'estensione TLS nota come Indicazione nome server ; questo richiede il supporto del cliente. In particolare, Internet Explorer non supporta l'indicazione del nome del server su Windows XP (IE 7.0 e versioni successive lo supportano, ma solo su Vista e Win7). Data l'attuale quota di mercato dei sistemi desktop che utilizzano WinXP, non si può presumere che "tutti" supportino l'indicazione del nome del server. Invece, i server HTTPS devono utilizzare un IP per nome server; lo stato attuale della distribuzione IPv6 e la carenza di indirizzi IPv4 fanno di questo un problema.
HTTPS è "più sicuro" di HTTP nel senso seguente: i dati sono autenticati come provenienti da un server nominato e il trasferimento è confidenziale per quanto riguarda chiunque possa origliare sulla linea. Questo è un modello di sicurezza che non ha senso in molte situazioni: per esempio, quando guardi un video da Youtube, non ti importa se il video proviene davvero da youtube.com o da qualche hacker che (cortesemente) invia tu il video che desideri vedere; e quel video è comunque dati pubblici, quindi la riservatezza è di scarsa importanza qui. Inoltre, l'autenticazione viene eseguita solo relativamente al certificato del server, che proviene da un'Autorità di certificazione a conoscenza del browser client. I certificati non sono gratuiti, dal momento che il punto dei certificati è che essi implicano l'identificazione fisica del proprietario del certificato da parte della CA (non sto dicendo che la CA commerciale giudica in modo equo i loro certificati, ma anche la più bella CA, gestita dallo stesso Buddha, devono ancora pagare una tassa per un certificato). La CA commerciale vorrebbe solo amare HTTPS come "predefinita". Inoltre, non è chiaro se il modello PKI incarnato dai certificati X.509 sia effettivamente quello che è necessario "di default" per Internet in generale (in particolare quando si tratta di relazioni tra certificati e DNS - alcuni sostengono che un il certificato del server deve essere emesso dal registrar quando viene creato il dominio).
In molte reti aziendali, HTTPS significa che i dati non possono essere visti dagli intercettatori e che questa categoria include tutti i tipi di filtri dei contenuti e software antivirus. L'impostazione predefinita di HTTPS renderebbe molto infelici molti amministratori di sistema.
Tutti questi sono motivi per cui HTTPS non è necessariamente una buona idea come protocollo predefinito per il Web. Tuttavia, non sono la ragione per cui HTTPS non è, attualmente, il protocollo predefinito per il Web; HTTPS non è l'impostazione predefinita semplicemente perché HTTP era lì per primo.
Anche se ci sono già ottime risposte, credo che finora un aspetto sia trascurato.
Eccolo: Plain HTTP è il protocollo predefinito per il web perché la maggior parte delle informazioni sul Web non ha bisogno di sicurezza.
Non intendo sminuire la domanda o i problemi di sicurezza di alcuni siti / applicazioni web. Ma a volte possiamo dimenticare quanto traffico web:
Alcuni esempi rapidi, sono sicuro che puoi farti rapidamente un'idea più precisa:
Http era sempre l'impostazione predefinita. Inizialmente, https non era necessario per nulla, era praticamente un'aggiunta aggiunta in quanto era evidente che la sicurezza era necessaria in alcune circostanze.
Anche ora, ci sono così tanti siti web che non hanno bisogno di https che non è ancora un argomento convincente per sostituire completamente http.
Con meccanismi sempre più efficaci per l'esecuzione di connessioni protette TLS, il sovraccarico della CPU sta diventando molto meno un problema.
Nessuno ha rilevato un problema evidente che deriva dall'utilizzo di http come predefinito, piuttosto che https.
Quasi nessuno si preoccupa di scrivere l'intero uri quando si richiede una risorsa che deve essere crittografata e / o firmata per vari scopi.
Prendi Gmail come esempio, quando gli utenti visitano gmail.com , in realtà visitano il protocollo predefinito di http anziché https. A questo punto la sicurezza ha fallito in scenari in cui l'avversario sta intercettando il traffico. Perché? Perché è possibile rimuovere la html dalla richiesta https e indirizzarla a http.
Se https fosse in effetti il protocollo predefinito, le tue sessioni sui siti Web sarebbero state protette.
Alla domanda sul perché http è stata scelta su https, si applicano le varie risposte sopra. Il mondo non è ancora pronto per l'uso diffuso della crittografia.
Oltre ai motivi che altri hanno già fornito:
Lavoro aggiuntivo richiesto per configurare HTTPS sul server
L'amministratore del server deve configurare i certificati per ciascun dominio. Ciò comporta l'interazione con un'autorità di certificazione per dimostrare di essere il vero proprietario del dominio e ottenere i rinnovi dei certificati. Ciò potrebbe significare la generazione manuale delle richieste di firma dei certificati e dei rinnovi degli acquisti oppure l'impostazione di un processo automatizzato per farlo (come certbot utilizzando Let's Encrypt). In entrambi i casi, è più lavoro che non usare HTTPS.
Sono richiesti ulteriori indirizzi IP
Questo non è un problema dal momento che il supporto SNI (identificazione dei nomi dei server) è diventato diffuso nei browser e nelle librerie client SSL.
Tradizionalmente, tuttavia, era necessario utilizzare un indirizzo IP diverso per ciascun sito distinto utilizzando SSL su un server e una porta specifici. Questo ha a che fare con la possibilità di fare hosting basato su nome (hosting virtuale) - una pratica ampiamente utilizzata che consente di ospitare molti domini diversi dallo stesso indirizzo IP. Con HTTPS, il normale hosting basato su nome non funziona perché il server dovrebbe sapere quale nome host presentare nel livello di validazione SSL / TLS prima della richiesta HTTP, contenente il nome host, può essere decrittografato.
SNI (Server Name Identification), che implementa efficacemente l'hosting basato sul nome sul livello SSL / TLS, rimuove questa limitazione.
Ritmo lento di cambiamento
HTTPS era una modifica di un protocollo esistente, HTTP, che era già molto radicato prima che molte persone iniziassero a pensare alla sicurezza. Una volta che una tecnologia si è affermata e onnipresente come HTTP, potrebbe richiedere molto tempo perché il mondo si trasferisca sul suo successore, anche se le ragioni del cambiamento sono convincenti.
Thomas ha già scritto una risposta eccellente, ma ho pensato di offrire un paio di altri motivi per cui HTTPS non è più utilizzato ...
Non necessario. come sottolinea in modo significativo la risposta di Jesper "la maggior parte delle informazioni sul Web non ha bisogno di sicurezza". Tuttavia , con la crescente quantità di tracciamento dei motori di ricerca, delle società pubblicitarie, dei filtri Internet a livello nazionale e di altri programmi "Big Brother" (ad esempio NSA); sta aumentando la necessità di maggiori misure di privacy.
Velocità. Spesso si sente lento a causa dei viaggi di andata e di ritorno aggiuntivi per gli elenchi di revoca dei certificati ( OCSP ecc.). Fortunatamente SPDY (creato da Google e ora supportato in tutti i principali browser) e alcuni il lavoro interessante da CloudFlare ti aiuta a spostarlo.
Prezzo dei certificati. La maggior parte delle autorità di certificazione addebita importi esorbitanti di denaro (centinaia di dollari) per un certificato. Fortunatamente ci sono opzioni gratuite , ma queste non ottengono tanta pubblicità (non so perché?).
Prezzo degli indirizzi IP. Fino a quando IPv6 non sarà diffuso, i siti Web dovranno affrontare la crescente scarsità (e quindi il costo) degli indirizzi IPv4. SNI rende possibile l'utilizzo di più certificati su un singolo indirizzo IP, ma senza supporto SNI in Windows XP o IE 6 , la maggior parte dei siti ha ancora bisogno di un indirizzo IP dedicato per fornire SSL.
Aumento dell'utilizzo della CPU del server. Questa è una credenza comune, ma secondo Google " SSL / TLS non è più computazionalmente costoso ".
La spiegazione più semplice e la più ragionevole che ho trovato tra i miei colleghi è che è sempre stato fatto con HTTP, perché cambiarlo ora.
Se non è rotto, non aggiustarlo.
La vera risposta è che i certificati SSL nella loro forma attuale sono comicamente difficili da usare. Sono così inutilizzabili che minacciano la sicurezza dei certificati, dato che le persone prendono scorciatoie per fare solo cose. Dico questo come qualcuno che si occupa abitualmente di SSL a 2 vie (PKI certs), le incompatibilità di stack TLS create dalla complessità delle specifiche e il numero pazzesco di combinazioni di configurazioni (limiti di cifratura, opzioni, bug di librerie specifiche della lingua , ecc.) che sono chiamati "TLS".
Vedi l'ascesa di LetsEncrypt come prova che questo è vero.
Caddy è un progetto di reverse proxy che utilizza LetsEncrypt. Può rinnovare i certificati mentre il server è in esecuzione e le persone utilizzano scadenze davvero brevi perché i rinnovi sono automatizzati.
Leggi altre domande sui tag http cryptography web-application tls