Domanda:
Perché abbiamo bisogno di HTTPS per i contenuti statici? Se possiamo avere un checksum alla fine firmato dalla chiave privata, non ne dimostrerà la validità?
kalyan
2017-03-12 08:59:19 UTC
view on stackexchange narkive permalink

Questo metodo di cui sto parlando può migliorare la memorizzazione nella cache di immagini, video e CSS da parte dell'ISP piuttosto che dipendere solo dalla cache del browser. E prova anche la validità del mittente. C'è qualche motivo per cui questo semi-HTTP non viene considerato?

Il costo della firma asimmetrica è una cosa a cui riesco a pensare. Ma se raggruppiamo blocchi di contenuto statico e calcoliamo il checksum sha256 in batch, la convalida della firma nel browser può essere un compromesso migliore rispetto al costo di rete end-to-end per ogni richiesta non nella cache del browser.

Vuoi dedicare molto tempo alla CPU a calcolare questi hash?Inoltre, come intendi verificare di aver ricevuto gli hash corretti dal server?Come "decifrerai" usando un hash?L'hashing non è crittografia.
L'hash sarà firmato dalla chiave privata del sito.Quindi il certificato del sito può anche essere memorizzato nella cache che ha la chiave pubblica.Ora l'hash del contenuto statico viene convalidato dalla chiave pubblica a condizione che il certificato sia attendibile.È possibile utilizzare contenuti per adulti registrati o contenuti dinamici HTTPS.HTTPS e questa tecnica di hashing possono coesistere ma gli oggetti HTTP e HTTPS non possono coesistere nella stessa pagina
Penso che tu stia parlando fondamentalmente delle cosiddette suite di cifratura "NULL" come `TLS_RSA_WITH_NULL_SHA256`.Sono molto scoraggiati e li ho visti implementati solo per caso.
Sì, simile a null suite.Le suite di cifratura nulle sono scoraggiate da openssl in quanto non forniscono riservatezza.Ma il contenuto statico può essere visibile fino a quando non viene dimostrata la validità del mittente
@MarkBuffalo Penso che tu abbia frainteso la premessa alla base della domanda.Inoltre, considerando ciò che già fa TLS, il calcolo dell'hash dei dati trasferiti è banale.
Potresti dare un'occhiata alla [bozza delle firme http] (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/).Ma questo è ancora in fase di elaborazione da quasi 4 anni.
So che il contesto è per i browser, ma per quanto riguarda le applicazioni, principalmente quelle che utilizzano la crittografia end-to-end?Quelli possono usare HTTP per il trasporto dei dati?Quali sono i problemi di farlo?MEGA, ad esempio, utilizza sempre HTTP quando possibile.
@MarkBuffalo Se l'argomento del tempo della CPU non funziona per TLS, perché pensi che funzionerebbe per qualcosa di più semplice di TLS?
@Scovetta Bene, questo perché si presume che chiunque utilizzi TLS desideri tutta la sicurezza di TLS e quindi utilizzare la crittografia nulla è un errore.Ma la domanda è: cosa succede se non si desiderano tutte le funzionalità di sicurezza di TLS?(Inoltre, non sono sicuro che TLS con crittografia nulla fornisca ancora l'autenticazione o meno; dovrei cercarlo. Lo schema proposto * fornirebbe * l'autenticazione senza crittografia)
Penso che il problema più grande di gran lunga con questo sia il replay che fa notare John Wu.Non voglio che gli aggressori sostituiscano parti di un sito Web a cui accedo con altre parti di esso;potrebbe causare gravi danni.
L'attacco di sostituzione concordato è molto possibile @sudo
Perché le persone continuano a cercare motivi artificiosi per * non * utilizzare HTTPS?Di solito è sia il percorso migliore che quello più facile!* (stridio autistico) *
@xDaizu niente di sbagliato nella discussione che sento di avere una nozione preconcetta
HTTPS riguarda anche la privacy.Le firme digitali non lo assicurano.
Sette risposte:
Out of Band
2017-03-12 14:53:07 UTC
view on stackexchange narkive permalink

Perché abbiamo bisogno di HTTPS per i contenuti statici? Se possiamo avere un checksum alla fine firmato dalla chiave privata, non ne dimostrerà la validità?

Penso che tu stia creando un uomo di paglia con questa domanda. In realtà non abbiamo bisogno di HTTPS per il contenuto statico e lo scopo di HTTPS non è solo quello di dimostrare la validità del contenuto. Questo è solo uno di diversi scopi. Il passaggio a passare un numero enorme di siti a 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 spiano gli utenti; per esempio. il passaggio su larga scala a HTTPS è avvenuto principalmente per motivi di privacy (vedere ad esempio RFC 7258, Pervasive Monitoring is an Attack - grazie a Michael Kjörling per averlo sottolineato).

Il tuo l'idea di utilizzare un checksum firmato è già in produzione su Internet: il software che scarichi viene spesso verificato in questo modo. I gestori di pacchetti / sistemi di aggiornamento della maggior parte dei sistemi operativi lo fanno e i singoli progetti software lo fanno su scala minore pubblicando firme pgp / gpg insieme ai loro download di software.

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

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

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

Qualche motivo particolare per cui questo semi HTTP non viene considerato?

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ì tanta parte di Internet che ora viene crittografata per proteggere la nostra privacy, sembra che non ci sarebbe molto uso di un altro protocollo che non proteggere dallo spionaggio.

Ha molto senso rispetto alla privacy.Le persone non riescono a capire chi ha visto quali video o immagini.I problemi di privacy riducono i casi d'uso.
Dovresti davvero fare riferimento [Internet best current practice (BCP) 188] (https://tools.ietf.org/html/bcp188).Noto anche come [RFC 7258] (https://tools.ietf.org/html/rfc7258).Nelle parole del titolo, * Pervasive Monitoring Is an Attack *.Dalla parte inferiore della sezione 2: "le funzionalità attuali consentono ad alcuni attori di monitorare contenuti e metadati su Internet a una scala mai vista prima. Questo monitoraggio pervasivo è un attacco alla privacy su Internet. L'IETF si adopererà per produrre specifiche che mitighino il monitoraggio pervasivoattacchi. "Non si ottiene una dichiarazione politica molto più chiara in una RFC.
tim
2017-03-12 14:39:57 UTC
view on stackexchange narkive permalink

Il tuo suggerimento è fondamentalmente di dividere HTTPS in due cose: Signing-Only e Encryption: Signing-Only impedisce a un uomo attivo nel mezzo di iniettare il proprio contenuto, come i tag di script, e la crittografia proteggerebbe i dati sensibili.

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

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

  • I file JS vengono utilizzati per scambiare 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:

  • E l'HSTS? Forza tutto il traffico tramite HTTPS ed è fortemente consigliato. Il tuo HTTP di sola firma conterebbe? Come funzionerebbe in pratica?
  • E l'usabilità? L'interfaccia del browser dovrebbe indicare all'utente quale "modalità" è attualmente utilizzata. E richiederebbe un'ulteriore educazione dell'utente su cosa significano le modalità e quando quale modalità è appropriata. Ciò porterà a molta confusione (gli utenti non capiscono nemmeno tutti gli elementi dell'interfaccia corrente, come il lucchetto o i vari avvisi).
  • In qualche modo dovresti segnalare al server di caching dell'ISP che stai richiedendo questo file. Non puoi semplicemente avere la richiesta al server tramite HTTP, perché ciò perderebbe cookie e altri dati sensibili. Oppure è necessario 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 un'importante riprogettazione dei siti web esistenti. E se quei 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 memorizzano più nella cache 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 per lo sviluppatore.

La privacy ha molto senso.Bootstrap CSS o jQuery molto comuni possono adattarsi. Ma i problemi di privacy riducono il caso d'uso poiché il referer può essere visibile nell'intestazione HTTP
Curiosità: ci sono già cypers SSL che forniscono [autenticazione senza crittografia] (https://www.rfc-editor.org/rfc/rfc4785.txt).I browser li consentono però, perché potrebbero essere utilizzati per dare all'utente un falso senso di riservatezza.
@user2428118 Volevi dire "I browser NON lo consentono però", giusto?
AiliodbswiCMT Sì
@kalyan "Un agente utente NON DEVE inviare un campo di intestazione Referer in una richiesta HTTP non protetta se la pagina di riferimento è stata ricevuta con un protocollo protetto."([RFC 7231 § 5.5.2] (https://tools.ietf.org/html/rfc7231#section-5.5.2))
+1 Sono un po 'scioccato dal fatto che, tra così tante risposte, tu sia l'unico a menzionare le intestazioni HTTP dei cookie.È di gran lunga il motivo più significativo per utilizzare HTTPS.
@RaduMurzea Per definizione, i dati pubblici statici non richiedono alcun cookie.
Xiong Chiamiov
2017-03-12 13:15:44 UTC
view on stackexchange narkive permalink

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

È anche generalmente consigliato usare protocolli standard a meno che tu non abbia una buona ragione per non farlo.

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

Ma il contenuto statico che potrebbe essere memorizzato nella cache dall'ISP non è possibile con HTTPS.E HTTP e HTTPS che rimangono insieme nella stessa pagina non è possibile.Ha senso perché la validità del mittente non può essere verificata.La firma del checksum ne verificherà la validità.La parte di privacy della parte dinamica può essere preservata consentendo la coesistenza di HTTPS e firma digitale del contenuto statico.Sto pensando perché questa tecnica non è considerata o è considerata?In caso affermativo quali sono gli svantaggi?
Inoltre, TLS è ovviamente ... beh, ** TL ** S.
@kalyan Ho già abbastanza problemi con i browser che non rispettano le impostazioni della cache e gli aggiornamenti duri.Gli ISP che memorizzano nella cache i miei contenuti statici sarebbero un ** incubo **.
@ceejayoz concordato.Ma i contenuti HTTP vengono persino memorizzati nella cache da ISP e istituti.Il proxy Squid o altri proxy diretti lo fanno
@kalyan Un motivo in più per utilizzare HTTPS completo per tutto.
@kaylan l'ISP perderà rapidamente tutti i suoi clienti se il loro contenuto memorizzato nella cache non corrisponde più al checksum inviato dal server di origine.
@ceejayoz: Questo potrebbe essere risolto incorporando un hash nell'URL.Lo scenario di utilizzo tipico che posso vedere per il contenuto statico autenticato comporterebbe un server https che sa esattamente quale dovrebbe essere il contenuto statico e dovrebbe quindi essere in grado di includere un hash all'interno dell'URL.Se il contenuto deve essere modificato, il server https dovrebbe saperlo e fornire un URL diverso per esso, il che renderebbe irrilevante il contenuto memorizzato nella cache precedente.
Non è necessario il caching dell'ISP.I CDN hanno già vinto.
John Wu
2017-03-13 00:44:37 UTC
view on stackexchange narkive permalink

Ci sono alcuni problemi di sicurezza a cui riesco a pensare.

Riproduzione e sostituzione

Non c'è nulla che impedisce a un uomo nel mezzo di sostituire una risorsa firmata con un'altra risorsa firmata ( catturato in precedenza). Ad esempio, potrei essere in grado di far apparire un pulsante verde GO dove dovrebbe essere un pulsante STOP, facendoti precipitare da un dirupo. Oppure potrei far sembrare che il tuo trasferimento di denaro non sia andato a buon fine in modo che tu lo invii ancora e ancora e io venga pagato più volte.

Se alcuni dei contenuti statici di un sito sono un file Javascript, forse posso scambiarlo con un file Javascript diverso lo stesso sito. Se sono intelligente, forse posso trovarne uno che abbia gli stessi nomi di funzione ma che faccia cose diverse o che non abbia determinate convalide.

Reindirizzamento

Potrei intercettare la tua richiesta di un'immagine e rispondere con un reindirizzamento 302 a un URL i cui parametri di stringa di query 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 lo schema delle richieste http per le risorse statiche.

DoS tramite avvelenamento della 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 supera la convalida e visualizzeranno un errore, senza mezzi semplici per aggirare il problema.

P.S. Problema di prestazioni

Inoltre, c'è un problema di prestazioni: le risorse soggette a un checksum non potranno essere renderizzate progressivamente, perché l'intero BLOB è richiesto per calcolare il checksum. Quindi le tue immagini appariranno più lente e il tuo film non inizierà fino a quando tutto non sarà passato attraverso il tubo.

+1 Buona risposta.Per quanto riguarda 1) "replay" è un po 'fuorviante, penso che solo "sostituzione" sarebbe più chiara 2) presumo che anche le intestazioni siano in qualche modo firmate (forse separatamente).Altrimenti, ci sarebbero un sacco di problemi 4) Presumo che la maggior parte dei mitm si trovi tra l'utente e l'ISP, ma qui dovrebbero sedersi tra l'ISP e il server.Comunque un buon punto.
Bella risposta.Per quanto riguarda il DOS tramite avvelenamento, anche ora in https è possibile DOS tramite man in the middle con certificato autofirmato o imitazione.Ma la parte di sostituzione ha molto senso
"forse riesco a trovarne uno che abbia gli stessi nomi di funzione ma che faccia cose diverse o che non abbia certe convalide" - cosa più pericolosa, usa la versione dello stesso file prima che risolva qualche difetto di sicurezza critico.Se il replay è possibile, allora le correzioni di bug (per le persone attaccate dal replay) sono impossibili.Ovviamente questo è un problema per i contenuti memorizzati nella cache in generale e le firme digitali potrebbero avere date di scadenza e così via.Ma è necessaria una certezza piuttosto elevata che sia una buona idea, prima di lasciare che una terza parte memorizzi nella cache qualcosa per cui normalmente farebbe affidamento su https per la sicurezza.
Che ne dici di fare un hash della firma come parte dell'URL?Ciò limiterebbe i casi di utilizzo a quelli in cui l'entità che fornisce l'URL sapeva quale contenuto era previsto, ma se la funzione di hashing è buona dovrebbe evitare qualsiasi problema di memorizzazione nella cache e bloccare eventuali attacchi di sostituzione.
Potresti forse affrontare il problema delle prestazioni firmando parti del file piuttosto che l'intero file.Un maggiore controllo dell'hash è negativo, ma almeno sarai in grado di iniziare a caricare le risorse prima che vengano completamente ricevute.
Lie Ryan
2017-03-12 21:24:04 UTC
view on stackexchange narkive permalink

Questo è in parte risolto dall ' integrità della sottorisorsa. Servi la pagina principale su HTTPS e questo include i metadati / hash delle sottorisorse, le sottorisorse possono quindi essere recuperate su HTTP per essere memorizzate nella cache dai proxy ISP o su HTTPS per essere memorizzate nella cache da un CDN e puoi essere certo che la risorsa non sia manomessa dagli intermediari fintanto che l'hash corrisponde.

Tuttavia, i browser considerano ancora le sottorisorse fornite in questo modo come contenuto misto perché qualsiasi modello che consente la memorizzazione nella cache dell'ISP manca di riservatezza. Invece il modello che viene diffuso al giorno d'oggi è che i proprietari dei siti configurino una CDN per eseguire il caching di rete edge, quindi le cache edge sono pagate dal proprietario del sito, piuttosto che dagli utenti. Questo è anche di buon auspicio con l'ISP come modello stupido di neutralità della rete.

Se possiamo avere un checksum alla fine firmato dalla chiave privata, non ne dimostrerà la validità? ... Qualche motivo particolare per cui questo semi-HTTP non viene considerato?

Probabilmente perché è banale rimuovere la firma e ricadrai in contenuti non firmati. Il modello SRI, d'altra parte, richiede che il documento principale indichi quando si prevede che la sottorisorsa sarà protetta.

L'integrità delle sottorisorse è molto simile alla strategia di cui sopra.Ma la riservatezza e la neutralità della rete sono un problema
L'integrità della sotto-fonte serve a verificare che la risorsa non sia stata alterata da * nessuno *, incluso il legittimo proprietario della risorsa.Non ha nulla a che fare con l'intercettazione e non è intercambiabile in alcun modo con https.In effetti, tutti gli esempi nel [link] (https://www.w3.org/TR/2015/WD-SRI-20150707/) che hai fornito utilizzano effettivamente https.
+1 per aver menzionato l'integrità delle sottorisorse che è qualcosa che viene utilizzato irl e molto vicino a ciò che OP ha chiesto
@JohnWu se il proprietario della risorsa è anche il proprietario della pagina che la include, allora il proprietario può modificarla modificando anche il checksum.
Non sono sicuro di quale sia il tuo punto Immibis.Se il proprietario della risorsa è anche il proprietario della pagina, non è una risorsa di terze parti e SRI non è necessario.
zwol
2017-03-13 00:24:34 UTC
view on stackexchange narkive permalink

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

Scommetto che questo è il vero motivo.Niente a che vedere con i fornitori di browser che non sono soddisfatti delle connessioni non crittografate.
sampablokuper
2017-03-13 13:59:10 UTC
view on stackexchange narkive permalink

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

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

  • sono poco facili da implementare;
  • il cambiamento culturale verso uno sviluppo web più sicuro (di cui l'uso diffuso di 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 e memorizzata in modo sicuro.

Ciononostante, queste tecniche costituiscono in linea di principio un ottimo meccanismo per verificare l ' integrità delle risorse statiche sui siti web.

Anche se tale firma di risorse web statiche fossero universali, tuttavia, l'implementazione di HTTPS avrebbe ancora un vantaggio: la riservatezza . La sola firma non lo fornirebbe, ma la crittografia fornita da HTTPS lo fornirebbe. (Almeno, HTTPS fornirebbe riservatezza purché la specifica applicabile per HTTPS non presenti bug critici e sia stata implementata correttamente.)

Perché tutti sembrano pensare che "c'è ancora un vantaggio per HTTPS che è che è riservato" è un argomento conclusivo a favore di HTTPS?C'è ancora un vantaggio nell'implementazione della firma HTTP + che è memorizzabile nella cache.
@immibis, Non sono sicuro del motivo per cui hai pubblicato quella domanda nella mia risposta, poiché la mia risposta non afferma che la riservatezza equivale a un argomento conclusivo a favore di HTTPS.Forse mi stai confondendo con qualcun altro?


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...