Perché abbiamo bisogno di HTTPS per il contenuto statico? Se possiamo avere un checksum alla fine firmato dalla chiave privata, non lo dimostrerà la validità?

Why do we need HTTPS for static content? If we can have a checksum at the end signed by the private key, won't that prove the validity?

Penso che tu stia preparando un uomo di paglia con quella domanda. In effetti, non abbiamo bisogno di HTTPS per i contenuti statici e lo scopo di HTTPS non è solo quello di dimostrare la validità del contenuto. Questo è solo uno di diversi scopi. Il passaggio a un numero elevato di siti su HTTPS (anche quelli che servono contenuti statici innocui, come wikipedia) negli ultimi due anni, non è avvenuto principalmente perché le persone erano preoccupate di ottenere il contenuto sbagliato; è perché le persone erano preoccupate per le agenzie di tre lettere che spiavano gli utenti; per esempio. il passaggio su larga scala a HTTPS è avvenuto principalmente per motivi di privacy (vedi ad esempio RFC 7258, Pervasive Monitoring è un attacco - grazie a Michael Kjörling per averlo indicato).

La tua idea di utilizzare un checksum firmato è già in produzione su Internet: il software scaricato viene spesso verificato in questo modo. I gestori dei pacchetti / i sistemi di aggiornamento della maggior parte dei sistemi operativi lo fanno, ei singoli progetti software lo fanno su una scala più piccola pubblicando le firme pgp / gpg insieme ai loro download di software.

Tutto funziona indipendentemente dal fatto che questi download siano forniti tramite https o meno, sebbene https sia spesso usato in aggiunta .

Stai suggerendo di aggiungere un terzo protocollo oltre a http e https, forse uno chiamato httpv per "verificato", che costruisce la verifica del contenuto nel protocollo ma lascia fuori il resto di ssl.

Sono d'accordo che ci sarebbe un vantaggio nel servire alcuni contenuti statici in chiaro in modo che possa essere memorizzato nella cache. Ma questa non è un'opzione se sei preoccupato per problemi di privacy alla luce dei programmi della comunità di intelligence per spiare tutte le nostre comunicazioni.

Any particular reason why this semi HTTPs not considered?

Quindi presumo che il tuo terzo protocollo non possa raccogliere molto vapore perché

1. esistono già soluzioni che funzionano quando abbiamo davvero bisogno di verificare il contenuto, e

2. con così tanto Internet che ora viene crittografato per proteggere la nostra privacy, sembra che non ci sarebbe molto da usare per un altro protocollo che non protegge contro lo spionaggio.

Il tuo suggerimento è fondamentalmente dividere l'HTTPS in due cose: Solo firma e crittografia: la sola firma impedisce a un uomo attivo nel mezzo di iniettare il proprio contenuto, come i tag di script, e la crittografia protegge i dati sensibili. / p>

Ma chi deciderebbe cosa sono i dati sensibili e cosa no? Questo sembra che richiede tempo e soggetto a errori.

Potresti naturalmente dichiarare automaticamente immagini, CSS, video e file JS come non sensibili. Ma sono loro?

• I file JS vengono utilizzati per lo scambio di dati
• Immagini e video possono contenere dati altamente sensibili
• I file CSS possono fornire informazioni su quale pagina specifica una persona sta visualizzando
• Tutte le richieste possono contenere dati sensibili nella risposta dell'intestazione HTTP (come i cookie impostati)

La tua idea richiederebbe anche altre modifiche:

• Che mi dici dell'HSTS? Forza tutto il traffico tramite HTTPS ed è strongmente raccomandato. Conta solo il tuo segnale di firma HTTP? Come funzionerebbe nella pratica?
• E Usabilità? L'interfaccia del browser dovrebbe indicare all'utente quale "modo" è attualmente utilizzato. E richiederebbe un'ulteriore istruzione dell'utente su cosa significano le modalità e quando la modalità è appropriata. Ciò creerà molta confusione (gli utenti non comprendono nemmeno tutti gli elementi dell'interfaccia corrente, come il lucchetto o i vari avvertimenti).
• In qualche modo dovresti segnalare al server di caching dell'ISP che stai richiedendo questo file. Non puoi semplicemente richiedere la richiesta al server via HTTP, perché ciò potrebbe far filtrare i cookie e altri dati sensibili. O dovresti specificare che i cookie non devono mai essere inviati a questi file non sensibili. Ma come lo faresti in modo affidabile? Certo, potrebbero essere serviti da un dominio diverso, ma ciò richiede una grande riprogettazione dei siti web esistenti. E se questi file non sensibili dovessero essere protetti da una sorta di autenticazione?

A parte questo, i vantaggi di questo approccio sembrano bassi. Da quello che sto leggendo, gli ISP raramente nascondono qualcosa in più perché i CDN se ne occupano già.

tl; dr : l'approccio violerebbe la privacy degli utenti e introdurrebbe problemi di sicurezza a causa di problemi di usabilità per l'utente finale e lo sviluppatore.

L'implementazione di una sorta di checksum funzionerebbe, sì. Ma usare TLS è molto più semplice.

Si consiglia inoltre di utilizzare i protocolli standard a meno che non si abbia una buona ragione per non farlo.

Infine, https offre una varietà di altri vantaggi. Entro i limiti del sistema CA, sai che stai ricevendo il file da chi pensi di essere. E fornisce privacy agli utenti, impedendo agli osservatori di vedere quali URL specifici richiedono.

Ci sono alcuni problemi di sicurezza a cui posso pensare.

Riproduzione e sostituzione

Non c'è nulla che impedisca a un uomo nel mezzo di sostituire una risorsa firmata con un'altra risorsa firmata (catturata in precedenza). Per esempio, potrei essere in grado di far apparire un pulsante GO verde dove dovrebbe trovarsi un pulsante STOP, che ti porta a sbandare. Oppure potrei far sembrare che il tuo trasferimento in contanti sia fallito, quindi lo invii ancora e ancora e vengo pagato più volte.

Se parte del contenuto statico di un sito è un file Javascript, forse posso scambiarlo con un file Javascript differente nello stesso sito. Se sono intelligente, forse ne trovo uno che ha lo stesso nome di funzione, ma fa cose diverse, o manca di certe convalide.

reindirizzamento

Potrei intercettare la tua richiesta di un'immagine e rispondere con un reindirizzamento 302 a un URL i cui parametri querystring comprendono un attacco XSRF.

Perdita di privacy

Un hacker che monitora il tuo traffico potrebbe essere in grado di determinare quali pagine stai visitando esaminando il modello delle richieste http per le risorse statiche.

DoS tramite avvelenamento da cache

Un hacker, lavorando un uomo nel mezzo, sostituisce un file non valido per una delle risposte. Il proxy memorizza il file nella cache. I browser che tentano di utilizzare la risorsa memorizzata nella cache scopriranno che non riesce a convalidare e visualizzeranno un errore, senza alcun mezzo facile per aggirare il problema.

P.S. Problema di prestazioni

Inoltre, c'è un problema di prestazioni-- le risorse che sono soggette a un checksum non potranno essere renderizzate progressivamente, perché l'intero BLOB è richiesto per calcolare il checksum. In questo modo le tue immagini appariranno più lente e il tuo film non verrà avviato fino a quando l'intera trama non sarà passata attraverso la pipe.

Ciò è in parte risolto dall'integrità
. Servi la pagina principale su HTTPS, e questo include i metadati / hash subresource, le subresources possono quindi essere recuperate su HTTP per essere memorizzate nella cache dai proxy ISP o su HTTPS per essere memorizzate nella cache da una CDN e puoi essere certo che la risorsa non è stata modificata dagli intermediari fino a quando l'hash corrisponde.

Tuttavia, i browser considerano ancora le risorse secondarie distribuite in questo modo come contenuti misti poiché qualsiasi modello che consente la memorizzazione nella cache dell'ISP non ha confidenza. Invece il modello che viene spinto oggigiorno è che i proprietari dei siti configurino un CDN per fare il caching della rete edge, quindi le cache edge vengono pagate dal proprietario del sito, piuttosto che dagli utenti. Anche questo è di buon auspicio con l'ISP come modello di neutralità della rete.

If we can have a checksum at the end signed by the private key, won't that prove the validity? ... Any particular reason why this semi HTTPs not considered?

Probabilmente perché è banale togliere la firma e ricadere nei contenuti non firmati. Il modello SRI, d'altra parte, richiede che il documento principale indichi quando si prevede che il subresource sia protetto.

Dovrebbe essere chiaro che i produttori di browser non hanno avuto nient'altro che brutte esperienze con "middleboxes" e si sono basati sulla crittografia end-to-end come il modo migliore per impedire loro di interferire. Questo è il motivo per cui, ad esempio, rifiutano di implementare il testo in chiaro HTTP / 2.0. Per lo stesso motivo, qualsiasi cosa sulla falsariga della tua idea è molto improbabile che venga adottata, mai.

Esistono tecniche per firmare il contenuto statico del sito web, in particolare l'HTML, ad esempio:

• link
• link

Tali iniziative non sono ancora diventate popolari. Sospetto che ciò sia dovuto a tre motivi:

• sono poco pratici da implementare;
• la svolta culturale verso uno sviluppo web più sicuro (di cui l'uso diffuso dell'HTTPS è un aspetto) era ancora agli inizi quando furono proposti per la prima volta;
• molti sviluppatori web non sanno come utilizzare gli strumenti OpenPGP, per non parlare di possedere una chiave di firma OpenPGP generata in modo sicuro e archiviata in modo sicuro.

Tuttavia, queste tecniche costituiscono in linea di principio un meccanismo eccellente per verificare l'integrità delle risorse statiche sui siti Web.

Anche se la firma di risorse Web statiche fosse universale, tuttavia, l'implementazione di HTTPS rappresenterebbe ancora un vantaggio: riservatezza . La firma da sola non fornirebbe questo, ma la crittografia fornita da HTTPS lo fornirebbe. (Almeno, HTTPS fornirebbe riservatezza purché le specifiche applicabili per HTTPS non presentino bug critici e siano state implementate correttamente.)