L'intero web * veramente * dovrebbe essere crittografato? Il testo in chiaro non è talvolta più veloce / migliore? [duplicare]

1

Sembra essere comunemente accettato al giorno d'oggi che tutte le comunicazioni via Internet debbano essere crittografate.
(Ad esempio, questo è evidente nel modo in cui lo standard HTTP 2.0 richiede HTTPS.)

Tuttavia, ho difficoltà a credere che questa sia la strada giusta da percorrere, ma sento di essere solo in questa posizione.

Si consideri, ad esempio, il download di file di grandi dimensioni (filmati, programmi di installazione delle applicazioni, ecc.).
Se i file non sono crittografati, è possibile inviare la stessa copia esatta a più client, consentendo un migliore caching e prestazioni di rete. (Naturalmente ciò vale anche per i file di piccole dimensioni, ma la motivazione per i file di grandi dimensioni è più evidente.)
Inoltre, ciò non implica una vulnerabilità di sicurezza: un server può inviare l'hash crittografico del file su HTTPS, ma ospitare il file stesso su HTTP. Il client può quindi facilmente controllare l'hash del file per verificarne l'integrità.

Perché questo approccio è indesiderato? Perché l'intero Web deve essere crittografato, anche quando il contenuto della comunicazione è di per sé chiaramente di dominio pubblico e facilmente protetto tramite un hash?

    
posta Mehrdad 13.12.2014 - 12:00
fonte

2 risposte

2

L'overhead aggiuntivo causato dalla crittografia del payload è quasi zero poiché le CPU oggi possono crittografare a velocità fino a centinaia di MB / s. L'unico ritardo evidente è durante l'impostazione della connessione, poiché sono necessari alcuni round trip aggiuntivi per configurare SSL / TLS. Tuttavia, se trasferisci file di grandi dimensioni, il costo di andata e ritorno è trascurabile.

Sì, la memorizzazione nella cache di file non crittografati aumenterà le prestazioni. Tuttavia, c'è una mancanza di privacy. L'operatore del server di memorizzazione nella cache può vedere il contenuto del download poiché non è crittografato. Pertanto, l'approccio sopra descritto non è così comune.

Tuttavia, se hai solo bisogno di verificare l'integrità e non hai bisogno di mantenere la privacy, allora il metodo qui sopra va bene.

    
risposta data 13.12.2014 - 13:25
fonte
1

Ci sono alcuni malintesi o mezze verità su HTTPS:

  • Prestazioni :
    • Se disponi di molte connessioni brevi, sarà molto più lento perché i costi principali sono nello scambio di chiavi iniziale e nei round trip aggiuntivi necessari per stabilire la connessione SSL sulla parte superiore della connessione TCP. La crittografia è di per sé economica, cioè più si trasferisce sulla stessa connessione, meno significativo sarà l'overhead iniziale.
    • La memorizzazione nella cache dei dati nelle middlebox (proxy, firewall) non sarà possibile, ma il caching nell'endpoint (browser) funziona ancora. Questo potrebbe non essere un problema per la maggior parte degli utenti domestici, ma è un problema per le connessioni a bassa larghezza di banda o ad alta latenza (collegamenti satellitari) che utilizzano spesso i proxy di memorizzazione nella cache per ottimizzare le connessioni. Sarà anche un problema con il caching di contenuti di uso comune (video ecc.) Presso l'ISP.
  • Privacy :
    • HTTPS protegge solo dallo sniffare o manipolare il contenuto. Non nasconde gli endpoint della connessione né il modello di traffico né le richieste DNS. Per il contenuto pubblico queste informazioni sono in genere sufficienti per scoprire quali siti l'utente sta visitando e anche quali contenuti di questo sito sono visualizzati.
    • Il tracciamento di google-analytics e reti simili sarà ancora eseguito, quindi questi servizi di tracciamento sanno ancora abbastanza su di te, anche se un intruso solitario sulla rete non lo farà. Lo stesso vale per la pubblicità e i social network.
    • E mentre l'intestazione Referer viene eliminata quando si effettua una richiesta HTTP da una risorsa HTTPS, verrà comunque inviata tra domini purché entrambe le richieste siano HTTPS.
  • Sicurezza :
    • HTTPS fornisce protezione contro lo sniffing o la manipolazione del contenuto.
    • HTTPS non fa nulla per proteggersi dagli attacchi attuali come Cross Site Scripting, Cross Site Request Forgery, SQL Injection, Drive-By-Download o altri tipi di download di malware. Ma renderà più difficile rilevare tali attacchi all'interno di middleboxes. Mentre l'intercettazione SSL può essere utilizzata nella maggior parte dei casi, alcune applicazioni come Dropbox utilizzano il blocco dei certificati e non fanno eccezioni per gli ancoraggi di trust aggiunti dall'utente come Chrome o Firefox. In questo modo queste applicazioni non possono essere intercettate e quindi devono essere bloccate o passeranno senza controllo.
    • HTTPS protegge dalla manipolazione del contenuto, che non lo fa HTTP. Anche se si ama memorizzare nella cache il contenuto pubblico, la resistenza contro la manipolazione è una caratteristica desiderata. Lo stesso vale per l'identificazione, cioè è una caratteristica desiderata per verificare l'origine anche del contenuto pubblico. Ma questa è una funzionalità che potrebbe essere fornita senza HTTPS, come l'utilizzo del certificato dei siti per aggiungere una firma al contenuto.
risposta data 14.12.2014 - 08:49
fonte

Leggi altre domande sui tag