it-swarm.dev

Perché i download di applicazioni non vengono eseguiti abitualmente su HTTPS?

Sappiamo tutti che dovremmo usare SSL ogni volta che raccogliamo password o altre informazioni sensibili. SSL offre due vantaggi principali:

  • Crittografia: I dati non possono essere letti da un intermediario durante il trasporto.
  • Protezione contro gli attacchi MITM: Un uomo in mezzo non può fingere di essere un server, poiché non può produrre un certificato firmato dalla CA per il server.

Se sto scaricando un'applicazione, probabilmente la eseguirò ad un certo punto, forse anche come root. Alcuni programmi saranno firmati, ma molti non lo sono. I download non dovrebbero essere eseguiti su SSL in modo che io sappia che non è stato manomesso durante il transito?

Se qualcuno ruba la mia password, non va bene. Ma se qualcuno pianta un keylogger sul mio computer, è molto, molto peggio.

58
Tom Marthenal

Perché HTTPS non è molto adatto per proteggere i download di file pubblici di grandi dimensioni. Per questo caso d'uso, è lento e non molto utile. Ci sono ragioni per non usare HTTPS ben oltre l'incompetenza o l'inconsapevolezza.

HTTPS non risolve completamente il problema . Questo Se si ottiene l'applicazione direttamente dal sito Web del fornitore, HTTPS garantisce l'autenticità dell'applicazione. Ma se stai ricevendo la tua applicazione da una terza parte (es. Mirror di software libero), HTTPS protegge solo la connessione con la terza parte. Uno schema di firma del pacchetto funziona meglio: può proteggere l'intera catena dal fornitore. La distribuzione dell'applicazione richiede una protezione end-to-end e HTTPS non lo fornisce .

HTTPS utilizza più larghezza di banda . Il sovraccarico per download è minimo se non si tiene conto della memorizzazione nella cache. Questa è la mucca sferica di "HTTPS non costa di più": se si utilizza SSL, non è possibile memorizzare nella cache i dati se non agli endpoint SSL. I download di applicazioni sono estremamente estremi: sono file di grandi dimensioni che molte persone scaricano.

HTTPS è eccessivo . La riservatezza del download di un'applicazione è raramente un problema, tutto ciò di cui abbiamo bisogno è l'autenticità. Purtroppo, HTTPS non fornisce autenticità senza fornire riservatezza. L'autenticità è compatibile con la memorizzazione nella cache, ma la riservatezza no.

HTTPS richiede più risorse sul server. Google mail è arrivato a un overhead dell'1% e un overhead della larghezza di banda del 2%, ma questo è per un caso d'uso molto diverso. I server front-end di Gmail servono molto più che servire i file senza pensare; un file server non ha bisogno di una potente CPU in primo luogo (è fortemente legato all'IO), quindi è probabile che l'overhead sia significativamente più grande. Lo stesso vale per l'overhead di memoria: in primo luogo un file server richiede pochissima memoria per sessione, quasi tutta la sua memoria è una cache del disco. Ridurre l'utilizzo delle risorse richiede na notevole quantità di lavoro .

HTTPS non aiuterebbe molte persone . Il responsabile della sicurezza verificherà l'hash fornito dal fornitore ( that dovrebbe essere su HTTPS). Chi non è attento alla sicurezza farà clic beato sul messaggio "questa connessione non è sicura" (ci sono così tanti server mal configurati là fuori che molti utenti sono addestrati a ignorare gli errori HTTPS). E questo per non parlare delle CA sciatte che rilasciano certificati che non dovrebbero.


Se vuoi assicurarti di ottenere l'applicazione originale, controlla la sua firma o il suo hash rispetto a un valore di riferimento che ottieni con una firma (ad esempio su HTTPS).

I buoni venditori lo rendono automatico. Ad esempio, Ubuntu fornisce firme GPG del suo supporto di installazione . Fornisce anche hash su HTTPS (purtroppo non collegato da nessuna parte vicino alla pagina di download, per quanto posso vedere). Successivamente, lo strumento di installazione del software verifica automaticamente che i pacchetti abbiano una firma valida. Vedi Come usare https con apt-get?

Nota: se si ottiene l'applicazione direttamente dal fornitore (anziché tramite un repository di pacchetti o un marketplace di applicazioni), HTTPS fornisce protezione. Quindi, se sei un fornitore che fornisce l'applicazione direttamente per il download sul tuo sito Web, proteggilo con HTTPS!

È lo stesso motivo per cui non tutti i prompt di accesso utilizzano ancora https: le persone sono troppo pigre, pensano che un certificato sia troppo costoso o abbiano un hosting che paga di più per l'utilizzo di https.

La vera domanda è perché i download sono offerti su una semplice connessione più spesso dei moduli di accesso. E Penso che questo sia principalmente a causa dell'inconsapevolezza. I checksum sono spesso forniti, ma non sono sicuri se inviati su http. Una buona implementazione di checksum che ho visto è dove sono stati pubblicati su Twitter (che utilizza https e si può ragionevolmente supporre che siano senza compromessi). Tuttavia non conosco nessuno che abbia mai verificato il checksum, forse solo se il software non funziona. Di solito TCP esegua un ragionevole controllo degli errori.

Ovviamente, https è più pesante sul server di http. Per i siti Web ad alto traffico questo potrebbe essere un motivo. Ma ancora una volta, i siti Web ad alto traffico possono anche generare "denaro elevato" per finanziarlo.

19
Luc

Probabilmente, quando gli utenti scaricano un'applicazione sul Web, il download dell'applicazione dovrebbe essere su HTTPS, perché è l'esperienza utente più pulita per gli utenti che fornisce sicurezza che possono comprendere. È probabilmente realistico aspettarsi che molti utenti controllino un bagliore verde nella barra degli indirizzi prima di scaricare, ma non è ragionevole (ad esempio) aspettarsi che calcolino gli hash e li controllino in modo sicuro.

Tuttavia, questi download di applicazioni spesso non vengono offerti su HTTPS, per una serie di possibili motivi:

  • Buoni motivi: HTTPS impedisce la memorizzazione nella cache della rete. Ciò può aumentare il traffico di rete, caricare sul server e caricare sulla rete lato client.

  • Cattivi motivi: le persone hanno erroneamente convinto che "HTTPS è lento" (che è n mito ), perché ci vuole un lavoro extra per configurare un server con SSL, perché si affidano ai mirror e ai siti mirror non usare HTTPS o perché le persone non ci hanno pensato o non pensano di essere a rischio. Per software ampiamente diffusi, queste credenze sono probabilmente miopi. Apparentemente, anche alcuni siti potrebbero utilizzare bilanciatori del carico o acceleratori che sono cerebralmente morti e che non comprendono correttamente HTTPS e che non vogliono o non possono permettersi di progettare una corretta distribuzione in grado di parlare correttamente HTTPS.

Alcuni siti di distribuzione delle applicazioni utilizzano l'utilizzo di HTTPS. Ma molti non lo fanno.

Firefox è un esempio di alto profilo di un'applicazione che non utilizza HTTPS per impostazione predefinita quando si scarica l'applicazione (vedere Quanto sono sicure le copie di Firefox che si trovano su vari siti mirror di Mozilla? ).

Windows Update viene eseguito su un canale sicuro (simile a HTTPS). I gestori di pacchetti Linux utilizzano la crittografia per proteggere il software scaricato, sebbene non lo stesso HTTPS.

9
D.W.

Il più delle volte ci saranno somme MD5sums e SHA1 per l'applicazione. Dopo averlo scaricato è necessario controllare questo a quello che viene visualizzato sul sito Web. Se quello che hai calcolato è lo stesso, non ci sono problemi.

4
Lucas Kauffman