Perché non usare HTTPS per tutto?

Se stavo configurando un server e avessi i certificati SSL, perché non dovrei usare HTTPS per l'intero sito anziché solo per acquisti / accessi? Penserei che avrebbe più senso crittografare l'intero sito e proteggere completamente l'utente. Eviterebbe problemi come decidere cosa deve essere protetto perché tutto sarebbe, e non è davvero un inconveniente per l'utente.

Se stavo già utilizzando un HTTPS per una parte del sito, perché non dovrei voler utilizzarlo per l'intero sito?

Questa è una domanda correlata: perché https viene utilizzato solo per l'accesso? , ma le risposte non sono soddisfacenti. Le risposte presuppongono che non sia stato possibile applicare https all'intero sito.

Mi vengono in mente un paio di ragioni.

• Alcuni browser potrebbero non supportare SSL.
• SSL può ridurre leggermente le prestazioni. Se gli utenti scaricano file pubblici di grandi dimensioni, potrebbe esserci un onere di sistema per crittografarli ogni volta.

Oltre agli altri motivi (soprattutto relativi alle prestazioni) è possibile ospitare un solo dominio per indirizzo IP * quando si utilizza HTTPS.

Un singolo server può supportare più domini in HTTP perché il server HTTP intestazione consente il know server di quale dominio di rispondere con.

Con HTTPS, il server deve offrire il proprio certificato al client durante l'handshake TLS iniziale (che è prima dell'avvio di HTTP). Ciò significa che l' intestazione del server non è stata ancora inviata, quindi non c'è modo per il server di sapere con quale dominio viene richiesto e con quale certificato (www.foo.com o www.bar.com) rispondere.

* Nota: tecnicamente, è possibile ospitare più domini se li si ospita su porte diverse, ma generalmente non è un'opzione. Puoi anche ospitare più domini se il tuo certificato SSL ha un carattere jolly. Ad esempio, è possibile ospitare sia foo.example.com che bar.example.com con il certificato * .example.com

SSL / TLS non viene usato abbastanza spesso. HTTPS deve essere utilizzato per l' intera sessione , in nessun momento è possibile inviare un ID sessione su HTTP. Se si utilizza https solo per l'accesso, si è in evidente violazione di OWASP top 10 per il 2010 "A3: autenticazione interrotta e gestione delle sessioni".

Perché non inviare ogni posta ordinaria in una busta opaca a prova di manomissione tramite posta raccomandata? Qualcuno dell'ufficio postale ne avrebbe sempre la custodia personale, quindi potresti essere abbastanza sicuro che nessuno stia ficcando il naso nella tua posta. Ovviamente, la risposta è che mentre un po 'di posta vale la spesa, la maggior parte della posta non lo è. Non mi interessa se qualcuno legge il mio "Sono contento che tu sia uscito di prigione!" cartolina a zio Joe.

La crittografia non è gratuita e non sempre aiuta.

Se una sessione (come acquisti, attività bancarie, ecc.) Si concluderà con HTTPS, non c'è motivo di non rendere l'intera sessione HTTPS il più presto possibile.

La mia opinione è che HTTPS dovrebbe essere usato solo quando inevitabilmente necessario, sia perché la richiesta o la risposta devono essere salvaguardate da ficcanaso intermedio. Ad esempio, dai un'occhiata a Yahoo! homepage. Anche se hai effettuato l'accesso, la maggior parte delle tue interazioni avverrà tramite HTTP. Esegui l'autenticazione su HTTPS e ricevi cookie che dimostrano la tua identità, quindi non hai bisogno di HTTPS per leggere le notizie.

Il motivo principale, oltre al carico del sistema, è che interrompe l'hosting virtuale basato sul nome. Con SSL, è un sito - un indirizzo IP. Questo è piuttosto costoso, oltre che più difficile da amministrare.

Per collegamenti ad alta latenza, l'handshake iniziale TLS richiede ulteriori round trip per convalidare la catena di certificati (incluso l'invio di certificati intermedi), concordare suite di cifratura e stabilire una sessione. Una volta stabilita una sessione, le richieste successive possono utilizzare la memorizzazione nella cache della sessione per ridurre il numero di viaggi di andata e ritorno, ma anche in questo caso vi sono ancora più viaggi di andata e ritorno di quanto richieda una normale connessione HTTP. Anche se le operazioni di crittografia sono gratuite, i viaggi di andata e ritorno non lo sono e possono essere abbastanza evidenti su collegamenti di rete più lenti, specialmente se il sito non sfrutta il pipelining http. Per gli utenti della banda larga all'interno di un segmento ben collegato della rete questo non è un problema. Se fai affari a livello internazionale, richiedere https può facilmente causare notevoli ritardi.

Vi sono ulteriori considerazioni come la manutenzione del server dello stato della sessione che richiede potenzialmente una quantità significativamente maggiore di memoria e ovviamente operazioni di crittografia dei dati. Praticamente tutti i siti di piccole dimensioni non devono preoccuparsi delle capacità del server rispetto al costo dell'hardware di oggi. Qualsiasi sito di grandi dimensioni sarebbe facilmente in grado di permettersi un offload AES CPU / w o schede aggiuntive per fornire funzionalità simili.

Tutte queste problematiche stanno diventando sempre più problematiche man mano che il tempo avanza e le capacità dell'hardware e della rete migliorano. Nella maggior parte dei casi dubito che ci sia qualche differenza tangibile oggi.

Potrebbero esserci considerazioni operative come restrizioni amministrative sul traffico https (pensate ai filtri di contenuto intermedi ... ecc.) Possibilmente alcune normative aziendali o governative. Alcuni ambienti aziendali richiedono la decrittografia dei dati a livello perimetrale per prevenire la perdita di informazioni ... interferenze con hotspot e sistemi di accesso basati su Web simili non in grado di iniettare messaggi nelle transazioni https. Alla fine della giornata, a mio avviso, i motivi per cui non si va in https per impostazione predefinita sono probabilmente abbastanza piccoli.

https è più affamato di risorse rispetto al normale http.

Richiede di più sia dai server che dai client.

Se l'intera sessione è crittografata, non sarà possibile utilizzare la memorizzazione nella cache per risorse statiche come immagini e js a livello di proxy, ad esempio ISP.

Dovresti usare HTTPS ovunque, ma perderai quanto segue:

1. Non dovresti assolutamente usare la compressione SSL o la compressione HTTP su SSL, a causa di attacchi BREACH e CRIME. Quindi nessuna compressione se la tua risposta contiene identificatori di sessione o csrf. Puoi mitigarlo inserendo le tue risorse statiche (immagini, js, css) in un dominio senza cookie e sfruttando la compressione lì. Puoi anche usare la minificazione HTML.

2. Un certificato SSL, un indirizzo IP, a meno che non si utilizzi SNI, che non funziona su tutti i browser (vecchio Android, Blackberry 6, ecc.).

3. Non dovresti ospitare contenuti esterni sulle tue pagine che non provengono da SSL.

4. Si perde l'intestazione del referente HTTP in uscita quando il browser passa a una pagina HTTP, il che potrebbe essere un problema per te.

Bene, la ragione ovvia è la prestazione: tutti i dati dovranno essere crittografati dal server prima della trasmissione e quindi decifrati dal client alla ricezione, il che è una perdita di tempo se non ci sono dati sensibili. Può anche influire sulla quantità di cache del tuo sito.

È anche potenzialmente fonte di confusione per gli utenti finali se tutti gli indirizzi utilizzano https://anziché quelli familiari http://. Vedi anche questa risposta:

Perché non usare sempre https quando si include un file js?

https richiede al server di crittografare e decrittografare le richieste e le risposte dei client. L'impatto sulle prestazioni si sommerà se il server sta servendo molti client. Ecco perché la maggior parte delle implementazioni attuali di https è limitata alla sola autenticazione con password. Ma con l'aumentare della potenza di calcolo questo può cambiare, dopo tutto Gmail utilizza SSL per l'intero sito.

Oltre alla risposta di WhirlWind, è necessario considerare il costo e l'applicabilità dei certificati SSL, i problemi di accesso (è possibile, sebbene improbabile, che un client possa non essere in grado di comunicare tramite la porta SSL), ecc.

L'uso di SSL non è una garanzia di sicurezza garantita. Questo tipo di protezione deve essere integrato nell'architettura dell'applicazione, piuttosto che cercare di fare affidamento su alcuni proiettili magici.

Mi è stato detto che in un progetto della nostra azienda, hanno scoperto che la larghezza di banda assorbita dai messaggi SSL era significativamente più che per i messaggi semplici. Credo che qualcuno mi abbia detto che i dati erano 12 volte più sorprendenti. Non l'ho verificato da solo e sembra molto alto, ma se c'è una sorta di intestazione aggiunta a ogni pagina e la maggior parte delle pagine ha una piccola quantità di contenuto, potrebbe non essere così lontano.

Detto questo, la seccatura di andare avanti e indietro tra http e https e tenere traccia di quali pagine mi sembrano troppi sforzi. Ho provato solo una volta a costruire un sito che li mescolava e abbiamo finito per abbandonare il piano quando siamo rimasti inciampati da cose complesse come le finestre pop-up create da Javascript che hanno collegato il protocollo sbagliato a loro e quel genere di cose. Abbiamo finito per rendere l'intero sito https meno problemi. Immagino che in semplici casi in cui hai solo una schermata di accesso e una schermata di pagamento che devono essere protette e che siano semplici pagine, non sarebbe un grosso problema combinare.

Non mi preoccuperei molto dell'onere che il cliente deve decifrare. Normalmente il cliente impiegherà molto più tempo ad aspettare che i dati passino sul filo di quanti ne occorrano per elaborarli. Fino a quando gli utenti non dispongono abitualmente di connessioni Internet gigabit / sec, la potenza di elaborazione del client è probabilmente irrilevante. La potenza della CPU richiesta dal server per crittografare le pagine è un problema diverso. Potrebbero esserci problemi di non essere in grado di tenere il passo con centinaia o migliaia di utenti.

Un altro piccolo punto (forse qualcuno può verificarlo), se un utente digita i dati in un elemento del modulo come una casella di testo e quindi per qualche motivo aggiorna la pagina o il server si arresta in modo anomalo per un secondo, i dati inseriti dall'utente vengono persi utilizzando HTTPS ma viene conservato tramite HTTP.

Nota: non sono sicuro che questo sia specifico del browser, ma certamente succede con il mio browser Firefox.

windows Server 2012 con IIS 8.0 ora offre SNI che è l'indicazione del nome del server che consente a più applicazioni Web SSL in IIS di essere ospitate su un indirizzo IP.