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

Perché HTTPS non è molto adatto alla protezione dei download di file pubblici di grandi dimensioni. Per questo caso d'uso, è lento e non così utile. Ci sono ragioni per non utilizzare HTTPS ben oltre l'incompetenza o l'inconsapevolezza.

HTTPS non risolve completamente il problema . Questo Se stai ricevendo l'applicazione direttamente dal sito Web del fornitore, HTTPS garantisce l'autenticità dell'applicazione. Ma se stai ricevendo la tua domanda da una terza parte (ad esempio specchi del 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 venditore. La distribuzione delle applicazioni richiede una protezione end-to-end e HTTPS non le fornisce .

HTTPS utilizza più larghezza di banda . Il sovraccarico per download è minimo se non si prende in considerazione la memorizzazione nella cache. Questa è la mucca sferica di "HTTPS non costa di più": se si utilizza SSL, non è possibile memorizzare nella cache i dati ad eccezione degli endpoint SSL. I download delle applicazioni sono al massimo livello: sono file di grandi dimensioni che molti utenti 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 anche riservatezza. L'autenticità è compatibile con il caching, ma la riservatezza non lo è.

HTTPS richiede più risorse sul server. Google mail ha ottenuto un overhead dell'1% e un overhead della larghezza di banda del 2%, ma questo è per un caso d'uso molto diverso. I server di frontend Gmail fanno più che servire irrimediabilmente i file; un file server non ha bisogno di una potente CPU in primo luogo (è molto strongmente legato all'IO), quindi il sovraccarico è probabilmente molto più grande. Lo stesso vale per il sovraccarico della memoria: un file server ha bisogno di pochissima memoria per sessione, in primo luogo, quasi tutta la sua memoria è una cache del disco. Ottenere l'utilizzo delle risorse verso il basso richiede una quantità notevole di lavoro .

HTTPS non aiuterebbe molte persone . Il responsabile della sicurezza controllerà l'hash fornito dal venditore ( che dovrebbe essere su HTTPS). La persona non attenta alla sicurezza farà il bloc del messaggio "questa connessione non è sicura" (ci sono così tanti server mal configurati là fuori che molti utenti sono addestrati ad ignorare gli errori HTTPS). E questo non fa menzione delle CA evasive che concedono certificati che non dovrebbero.

Se vuoi assicurarti di ottenere l'applicazione autentica, controlla la sua firma o controlla il suo hash con 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 gli hash su HTTPS (purtroppo non collegati 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 stai ricevendo l'applicazione direttamente dal fornitore (diversamente da un repository di pacchetti o un marketplace di applicazioni), HTTPS fornisce protezione. Quindi, se sei un fornitore che fornisce direttamente la tua applicazione per il download sul tuo sito web, proteggi 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 che l'hosting richieda ulteriori addebiti per l'utilizzo di https.

La vera domanda è il motivo per cui i download vengono pubblicati su una semplice connessione più spesso dei moduli di accesso. E penso che questo sia principalmente dovuto all'incoscienza . I checksum sono spesso forniti, ma non sono sicuri se inviati su http. Una buona implementazione dei checksum che ho visto è dove sono stati pubblicati su Twitter (che usa https, e si può ragionevolmente presumere che non siano compromessi). Tuttavia non conosco nessuno che controlli il checksum, forse solo se il software non funziona. Di solito si presuppone che TCP esegua un ragionevole controllo degli errori.

Ovviamente, https è più pesante sul server di http. Per i siti Web con traffico elevato, questo potrebbe essere un motivo. Ma anche in questo caso, i siti Web ad alto traffico possono anche generare "high-money" per finanziarlo.

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. È verosimilmente realistico aspettarsi che molti utenti controllino il bagliore verde nella barra degli indirizzi prima di scaricarli, ma non è ragionevole (ad esempio) aspettarsi che calcolino gli hash e li controllino in modo sicuro.

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

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

• Cattive ragioni: le persone credono erroneamente che "HTTPS sia lento" (che è un mito ), perché ci vuole del lavoro extra per configurare un server con SSL, perché si basano sui mirror e i siti mirror non usano HTTPS, o perché le persone non ci hanno pensato o no pensano di essere a rischio. Per software ampiamente utilizzati, queste credenze sono probabilmente miopi. Apparentemente, anche alcuni siti potrebbero utilizzare load balancers o acceleratori che sono cerebralmente morti e non capiscono correttamente HTTPS, e non vogliono o non possono permettersi di progettare una corretta implementazione che possa parlare correttamente HTTPS.

Alcuni siti di distribuzione di applicazioni fanno utilizzano HTTPS. Ma molti no.

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 di 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 che scaricano, anche se non lo stesso HTTPS.

La maggior parte delle volte ci saranno somme MD5sum e SHA1 per l'applicazione. Dopo averlo scaricato, devi controllare questo a quello che viene visualizzato sul sito web. Se quello che hai calcolato è lo stesso, allora non ci sono problemi.