Pourquoi les téléchargements d'applications ne sont-ils pas systématiquement effectués via HTTPS?
Nous savons tous que nous devons utiliser SSL chaque fois que nous collectons des mots de passe ou d'autres informations sensibles. SSL offre deux avantages principaux:
- Cryptage: Les données ne peuvent pas être lues par un intermédiaire en transit.
- Protection contre les attaques MITM: Un homme au milieu ne peut pas prétendre être un serveur, car il ne peut pas produire de certificat signé par l'AC pour le serveur.
Si je télécharge une application, je vais probablement l'exécuter à un moment donné, peut-être même en tant que root. Certains programmes seront signés, mais beaucoup ne le sont pas. Les téléchargements ne doivent-ils pas être effectués via SSL afin que je sache qu'il n'a pas été falsifié pendant le transport?
Si quelqu'un vole mon mot de passe, c'est mauvais. Mais si quelqu'un plante un enregistreur de frappe sur mon ordinateur, c'est bien pire.
Parce que HTTPS n'est pas très bien adapté pour sécuriser les téléchargements de gros fichiers publics. Pour ce cas d'utilisation, c'est lent et pas très utile. Il y a des raisons de ne pas utiliser HTTPS bien au-delà de l'incompétence ou de l'ignorance.
HTTPS ne résout pas complètement le problème . Si vous obtenez votre application directement sur le site Web du fournisseur, HTTPS garantit l'authenticité de l'application. Mais si vous obtenez votre application d'un tiers (par exemple, des miroirs de logiciels gratuits), HTTPS protège uniquement la connexion avec le tiers. Un schéma de signature de package fonctionne mieux: il peut protéger toute la chaîne du fournisseur. La distribution des applications nécessite une protection de bout en bout et HTTPS ne fournit pas cela .
HTTPS utilise plus de bande passante . La surcharge par téléchargement est minime si vous ne prenez pas en compte la mise en cache. Il s'agit de la vache sphérique de "HTTPS ne coûte pas plus cher": si vous utilisez SSL, vous ne pouvez pas mettre en cache les données sauf aux points de terminaison SSL. Les téléchargements d'applications sont extrêmement complexes: ce sont de gros fichiers que de nombreuses personnes téléchargent.
HTTPS est exagéré . La confidentialité du téléchargement d'une application est rarement un problème, tout ce dont nous avons besoin est d'authenticité. Malheureusement, HTTPS ne fournit pas d'authenticité sans fournir également la confidentialité. L'authenticité est compatible avec la mise en cache, mais pas la confidentialité.
HTTPS nécessite plus de ressources sur le serveur. Google mail est descendu à une surcharge de 1% et une surcharge de bande passante de 2%, mais c'est pour un cas d'utilisation très différent. Les serveurs frontaux Gmail font plus que servir les fichiers sans réfléchir; un serveur de fichiers n'a pas besoin d'un processeur puissant en premier lieu (il est très fortement lié aux E/S), de sorte que la surcharge est probablement beaucoup plus importante. Il en va de même pour la surcharge de mémoire: un serveur de fichiers a besoin de très peu de mémoire par session en premier lieu, presque toute sa mémoire est un cache disque. Pour réduire l'utilisation des ressources, il faut beaucoup de travail .
HTTPS n'aiderait pas beaucoup de gens . Les personnes soucieuses de la sécurité vérifieront le hachage fourni par le vendeur ( ça devrait être via HTTPS). Les personnes non soucieuses de sécurité cliqueront allègrement sur le message "cette connexion n'est pas sécurisée" (il y a tellement de serveurs mal configurés que de nombreux utilisateurs sont formés pour ignorer les erreurs HTTPS). Et cela sans parler des CA douteuses qui accordent des certificats qu'elles ne devraient pas.
Si vous voulez vous assurer que vous obtenez l'application authentique, vérifiez sa signature ou comparez son hachage à une valeur de référence que vous obtenez avec une signature (par exemple via HTTPS).
Les bons vendeurs rendent cela automatique. Par exemple, Ubuntu fournit signatures GPG de son support d'installation . Il fournit également le hachages sur HTTPS (malheureusement pas lié de près de la page de téléchargement pour autant que je puisse voir). Après cela, l'outil d'installation du logiciel vérifie automatiquement que les packages sont livrés avec une signature valide. Voir Comment utiliser https avec apt-get?
Remarque: si vous obtenez l'application directement auprès du fournisseur (par opposition à via un référentiel de packages ou un marché d'applications), HTTPS fournit une protection. Donc, si vous êtes un fournisseur fournissant votre application directement en téléchargement sur votre site Web, protégez-la avec HTTPS!
C'est la même raison pour laquelle toutes les invites de connexion n'utilisent pas encore https: les gens sont trop paresseux, pensent qu'un certificat est trop cher ou ont un hébergement qui coûte plus cher pour utiliser https.
La vraie question est de savoir pourquoi les téléchargements sont diffusés via une connexion simple plus souvent que les formulaires de connexion. Et je pense que c'est principalement à cause de l'ignorance. Les sommes de contrôle sont souvent fournies, mais elles ne sont pas sécurisées si elles sont envoyées via http. Une bonne mise en œuvre des sommes de contrôle que j'ai vues est l'endroit où elles ont été publiées sur Twitter (qui utilise https, et peut raisonnablement être considérée comme sans compromis). Cependant, je ne connais personne qui vérifie la somme de contrôle, peut-être seulement si le logiciel ne fonctionne pas. Généralement TCP est supposé faire une vérification d'erreur raisonnable.
Bien sûr, https est plus lourd sur le serveur que http. Pour les sites Web à fort trafic, cela peut être une raison. Mais là encore, les sites Web à fort trafic peuvent également générer de "l'argent élevé" pour le financer.
On peut dire que lorsque les utilisateurs téléchargent une application sur le Web, le téléchargement de l'application devrait se faire sur HTTPS, car c'est l'expérience utilisateur la plus propre pour les utilisateurs qui offre une sécurité qui ils peuvent comprendre. Il est sans doute réaliste de s'attendre à ce que de nombreux utilisateurs recherchent une lueur verte dans la barre d'adresse avant de télécharger, mais il n'est pas raisonnable (par exemple) de s'attendre à ce qu'ils calculent les hachages et les vérifient en toute sécurité.
Cependant, ces téléchargements d'applications ne sont souvent pas proposés via HTTPS, pour diverses raisons:
Bonnes raisons: HTTPS empêche la mise en cache dans le réseau. Cela peut augmenter le trafic réseau, la charge sur le serveur et la charge sur le réseau côté client.
Mauvaises raisons: les gens croient à tort que "HTTPS est lent" (ce qui est n mythe ), car il faut du travail supplémentaire pour configurer un serveur avec SSL, car ils dépendent des miroirs et des sites miroirs n'utilisez pas HTTPS, ou parce que les gens n'y ont pas pensé ou ne pensent pas qu'ils sont à risque. Pour les logiciels largement utilisés, ces croyances sont probablement à courte vue. Apparemment, certains sites peuvent également utiliser des équilibreurs de charge ou des accélérateurs dont le cerveau est mort et qui ne comprennent pas correctement HTTPS, et ils ne veulent pas ou ne peuvent pas se permettre de concevoir un déploiement approprié capable de parler correctement HTTPS.
Certains sites de distribution d'applications utilisent HTTPS. Mais beaucoup ne le font pas.
Firefox est un exemple très médiatisé d'une application qui n'utilise pas HTTPS par défaut lorsque vous téléchargez l'application (voir La sécurité des copies de Firefox qui se trouvent sur divers sites miroir de Mozilla? ).
Windows Update se fait sur un canal sécurisé (semblable à HTTPS). Les gestionnaires de packages Linux utilisent la cryptographie pour protéger le logiciel qu'ils téléchargent, mais pas HTTPS lui-même.
La plupart du temps, il y aura des sommes MD5 et des sommes SHA1 pour l'application. Après l'avoir téléchargé, vous devez le vérifier sur celui qui est affiché sur le site Web. Si celui que vous avez calculé est le même, il n'y a pas de problème.