it-swarm.dev

Perché HTTPS non è il protocollo predefinito?

Perché l'HTTP è ancora comunemente usato, invece quello che riterrei HTTPS molto più sicuro?

75
blunders

SSL/TLS ha un leggero sovraccarico. Quando Google ha cambiato Gmail in HTTPS (da una funzione opzionale all'impostazione predefinita), hanno scoperto che l'overhead della CPU era di circa + 1% e l'overhead di rete + 2%; vedere questo testo per i dettagli. Tuttavia, questo è per Gmail, che consiste in dati privati, dinamici, non condivisi e ospitati sui sistemi di Google, che sono 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 di rete aggiuntivi. Poiché tali connessioni vengono "mantenute vive" 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 principalmente contenuti statici possono ritenere l'overhead di rete non trascurabile.

  • I server proxy non possono memorizzare nella cache le pagine fornite con HTTPS (poiché non vedono nemmeno quelle pagine). Anche in questo caso, non c'è nulla di statico da memorizzare nella cache con Gmail, ma questo è un contesto molto specifico. Gli ISP amano molto la memorizzazione nella cache poiché la larghezza di banda della rete è la loro forza vitale.

  • HTTPS è HTTP all'interno di SSL/TLS. Durante l'handshake TLS, il server mostra il suo certificato, che deve designare il nome del server previsto - e questo si verifica prima la stessa richiesta HTTP viene inviata al server. Questo impedisce l'hosting virtuale, a meno che non venga utilizzata un'estensione TLS nota come Server Name Indication ; questo richiede supporto dal client. 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 del server; lo stato corrente della distribuzione IPv6 e IPv4 la carenza di indirizzo rende questo un problema.

  • HTTPS è "più sicuro" di HTTP nel senso seguente: i dati vengono autenticati come provenienti da un server denominato e il trasferimento è riservato rispetto a chiunque possa intercettare sulla linea. Questo è un modello di sicurezza che non ha senso in molte situazioni: ad esempio, quando guardi un video da Youtube, non ti importa davvero 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 un dato pubblico, quindi la riservatezza è di scarsa rilevanza qui. Inoltre, l'autenticazione viene eseguita solo relativamente al certificato del server, che proviene da un'autorità di certificazione di cui il browser client è a conoscenza. I certificati non sono gratuiti, poiché il punto dei certificati è che implicano l'identificazione fisica del proprietario del certificato da parte della CA (non sto dicendo che i prezzi dei certificati CA siano equi; ma anche il più equo dei CA, gestito dallo stesso Buddha, devo ancora addebitare una commissione per un certificato). L'autorità di certificazione commerciale adorerebbe HTTPS come "predefinito". Inoltre, non è chiaro se il modello PKI incorporato nei certificati X.509 sia realmente ciò 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 la categoria include tutti i tipi di filtri di contenuto e software antivirus. Rendere HTTPS predefinito renderebbe molti amministratori di sistema molto infelici.

Tutti questi sono motivi per cui HTTPS non è necessariamente una buona idea come protocollo predefinito per il Web. Tuttavia, non sono il motivo per cui HTTPS non è, attualmente, il protocollo predefinito per il Web; HTTPS non è il valore predefinito semplicemente perché prima c'era HTTP.

68
Thomas Pornin

Mentre ci sono già ottime risposte, credo che finora un aspetto sia stato 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 le preoccupazioni di sicurezza di alcuni siti Web/applicazioni. Ma a volte possiamo dimenticare quanto traffico Web:

  • contiene solo informazioni completamente pubbliche
  • o ha poco o nessun valore
  • o dove avere più visitatori è visto come aumentare il valore del sito (mezzi di informazione, effetto rete siti)

Alcuni brevi esempi, sono sicuro che puoi rapidamente fare di più nella tua mente:

  • Quasi tutti i siti Web aziendali, a volte chiamati "siti di brochure", che elencano informazioni pubbliche su un'azienda.
  • Quasi tutti i media, i blog, le emittenti televisive, ecc. Che hanno scelto il supporto pubblicitario come principale strategia di monetizzazione.
  • Servizi che possono offrire accessi e personalizzazioni aggiuntive, ma che regalano i loro contenuti gratuitamente a chiunque navighi in modo anonimo (YouTube FX).
31
Jesper M
  • Aumenta notevolmente il carico della CPU sul server, soprattutto per i contenuti statici.
  • È più difficile eseguire il debug con acquisizioni di pacchetti
  • Non supporta server virtuali basati sul nome
5
Mike Scott

Http è sempre stato il valore predefinito. Inizialmente https non era necessario per nulla, era praticamente un'aggiunta aggiunta poiché divenne evidente 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 sostituire completamente http.

Con meccanismi sempre più efficaci per l'esecuzione di connessioni protette TLS, l'overhead della CPU sta diventando molto meno problematico.

5
Rory Alsop

Nessuno ha sottolineato un chiaro problema che deriva dall'uso di http come predefinito, piuttosto che https.

Quasi nessuno si preoccupa di scrivere l'uri completo quando richiede una risorsa che deve essere crittografata e/o firmata per vari scopi.

Prendi ad esempio gmail, quando gli utenti visitano gmail.com, in realtà stanno visitando il protocollo predefinito di http, anziché https. A questo punto la sicurezza non è riuscita negli scenari in cui l'avversario sta intercettando il traffico. Perché? Perché è possibile rimuovere HTML dalla richiesta HTTPS e indirizzarli a http.

Se https fosse in effetti il ​​protocollo predefinito, le sessioni sui siti Web sarebbero state protette.

Alla domanda sul perché http sia scelto su https, si applicano le varie risposte sopra. Il mondo non è ancora pronto per l'uso diffuso della crittografia.

5

Oltre ai motivi che altri hanno già indicato:

  • Lavoro aggiuntivo richiesto per impostare HTTPS sul server

    L'amministratore del server deve configurare i certificati per ciascun dominio. Ciò implica l'interazione con un'autorità di certificazione per dimostrare di essere il vero proprietario del dominio e ottenere il rinnovo del certificato. Ciò potrebbe significare generare manualmente richieste di firma del certificato e rinnovare gli acquisti o impostare un processo automatizzato per farlo (come certbot utilizzando Let's Encrypt). In entrambi i casi, è più lavoro che non usare HTTPS.

  • indirizzi IP aggiuntivi richiesti

    Questo non è un vero problema da quando il supporto SNI (Server Name Identification) è diventato molto 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 determinato server e porta. Ciò è stato integrato con la possibilità di eseguire l'hosting basato sul nome (hosting virtuale), una pratica ampiamente utilizzata che consente di ospitare molti domini diversi dallo stesso indirizzo IP. Con HTTPS, l'hosting basato su nomi regolari non funziona perché il server dovrebbe sapere quale nome host presentare nel livello di convalida SSL/TLS prima la richiesta HTTP, contenente il nome host, può essere decifrata.

    Server Name Identification (SNI), che implementa efficacemente l'hosting basato su nomi a livello SSL/TLS, rimuove questa limitazione.

  • Ritmo lento del cambiamento

    HTTPS era una modifica a un protocollo esistente, HTTP, che era già molto radicato prima che molte persone iniziassero a pensare alla sicurezza. Una volta che una tecnologia è diventata consolidata e onnipresente come l'HTTP, il mondo può impiegare molto tempo per passare al suo successore, anche se le ragioni del cambiamento sono convincenti.

3
thomasrutter

Thomas ha già scritto una risposta eccellente, ma ho pensato di offrire un paio di motivi in ​​più per cui HTTPS non è più usato ...

  • Non necessario. Come la risposta di Jesper sottolinea perspicace "la maggior parte delle informazioni sul web non ha bisogno di sicurezza". Comunque, con la crescente quantità di tracciamento effettuata da motori di ricerca, società pubblicitarie, filtri Internet a livello nazionale e altri programmi "Big Brother" (es. NSA); sta aumentando la necessità di maggiori misure sulla privacy.

  • Velocità. Spesso sembra lento a causa dei viaggi di andata e ritorno extra e delle richieste extra per gli elenchi di revoche di certificati ( OCSP ecc.). Per fortuna SPDY (creato da Google e ora supportato in tutti i principali browser), e alcuni lavoro interessante di CloudFlare stanno aiutando a spostare questo .

  • Prezzo dei certificati. La maggior parte delle autorità di certificazione addebita importi esorbitanti (centinaia di dollari) per un certificato. Per fortuna ci sono opzioni gratuite , ma queste non ottengono tanta pubblicità (non sai 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 sta rendendo possibile l'uso di più certificati su un singolo indirizzo IP, ma senza supporto SNI in Windows XP o IE 6, la maggior parte dei siti necessita ancora 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ù costoso dal punto di vista computazionale ".

2
Simon East

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.

1
blfoleyus

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, poiché le persone prendono scorciatoie per fare solo cose. Lo dico come qualcuno che si occupa abitualmente di SSL a 2 vie (certificati PKI), le incompatibilità dello stack TLS create dalla complessità delle specifiche e il folle numero di combinazioni di configurazioni (limiti di cifratura, opzioni, bug della libreria specifici della lingua , ecc.) chiamati "TLS".

Guarda l'ascesa di LetsEncrypt come prova che questo è vero.

Caddy è un progetto proxy inverso che utilizza LetsEncrypt. Può rinnovare i certificati mentre il server è in esecuzione e le persone utilizzano scadenze molto brevi perché i rinnovi sono automatizzati.

1
Rob