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!