Les listes de référentiels sont-elles sécurisées? Existe-t-il une version HTTPS?
Les mises à jour du référentiel sont-elles sécurisées?
En tant que petit cerveau du côté du développeur, je ne comprends pas pourquoi la liste de référentiels est http://security.ubuntu.com et les autres sites http (non sécurisés) répertoriés dans /etc/apt/sources.list. Sans correspondance de chaîne de certificats, cela apparaît sous la forme "demander à tout répondeur la liste des paquets à mettre à jour" au lieu de "demander au site ubuntu.com ..."
Tout réseau peut-il choisir d'usurper les sites de mise à jour, et s'agit-il d'une pratique courante de fournir une copie mise en cache et vérifiée localement?
En bref, oui, ils sont sécurisés, en raison de la cryptographie à clé publique utilisée pour signer les fichiers.
Tous les fichiers téléchargés par APT ont une signature qui permet de vérifier le fichier téléchargé par rapport aux clés publiques stockées sur votre ordinateur, comme signée par Ubuntu et uniquement par Ubuntu. Cela permet de vérifier que le fichier que vous avez reçu a été autorisé par Ubuntu à un moment donné et qu’il n’a pas été modifié ni falsifié depuis.
Une explication technique de la façon dont cela fonctionne est disponible sous Ubunt (et sous Debian , qui utilise le même système).
En raison de l'utilisation de HTTP au lieu de HTTPS, oui, les oreilles indiscrètes pourraient voir quels fichiers vous téléchargez, mais la confidentialité ne vous concernera probablement pas dans ce cas. Une tentative de l'homme du milieu de modifier les packages pour injecter du code préjudiciable échouerait quand même, car cela briserait le mécanisme de signature.
Ce mécanisme de signature présente un inconvénient: il ne garantit pas que vous obtenez la version la plus récente du paquet (en fait, la mise à jour des miroirs est parfois lente). Pour atténuer ce problème, le fichier de version signé comprend une date "Valable jusqu'au" après laquelle tous les fichiers qu'il référence doivent être considérés comme périmés. Il serait plausible pour un intermédiaire de substituer à une archive une version antérieure non modifiée de cette archive au cours de cette date de validité-avant et de faire croire à votre APT qu'il n'y a aucune mise à jour. Mais ils ne peuvent apporter aucune modification arbitraire aux paquets et ils ne peuvent pas remonter dans le temps après un certain point.
Les mécanismes de signature offrent une bien meilleure sécurité que HTTPS dans ce type d'environnement distribué où les fichiers sont mis en miroir sur de nombreux serveurs non contrôlés par Ubuntu. Essentiellement, vous devez uniquement faire confiance à Ubuntu et non au miroir. Vous devez donc prouver que les fichiers proviennent à l'origine d'Ubuntu et n'ont pas été modifiés depuis - il n'est pas nécessaire de vérifier l'identité du miroir.
Notez que lorsque vous ajoutez un référentiel non officiel à votre liste de sources, tel qu'un PPA, vous recevrez des fichiers qui ne sont pas signés par Ubuntu. APT devrait vous en avertir, car ils n'ont pas été signés par un certificat correspondant à l'une des clés publiques installées sur votre ordinateur, comme autorisé par Ubuntu.
La réponse la mieux notée ici est clairement dépassée. Depuis lors, 2 exploit graves liés à l'exécution de code à distance ont été découverts dans apt en raison de la vérification de paquet buggy. Bulletins de sécurité ici et ici .
Ceci est bien pire que les préoccupations concernant la confidentialité/la fuite d'informations et la version obsolète du package; cela permet l'exécution de code arbitraire en tant qu'utilisateur root, défaillance de sécurité complète. Et le problème est le suivant: ces attaques auraient été empêchées si https avait été utilisé à la place de http.
Cela prouve que le principe défense en profondeur s'applique ici autant que partout ailleurs. Les nombreuses affirmations selon lesquelles https ne fournit aucun avantage ou un avantage minime en matière de sécurité dans le contexte d’apt sont tout simplement incorrectes, comme l’ont montré ces exploits.
La question est alors de savoir si l'avantage de sécurité de https en vaut la peine en termes de mise en cache, de frais généraux accrus, etc. .
Supplément important ： En fait, lors de la mise à niveau et du téléchargement initial de l'installation en ligne, il faut beaucoup de trafic et la source de ce trafic, c'est-à-dire des flux de code binaire et texte, est reproductible. Il existe donc un grand nombre de passerelles et de périphériques de cache sur Internet. Un nombre considérable de FAI avaient mis en place un cache basé sur le protocole http afin de sauvegarder la bande passante d'exportation, et le protocole https ne peut exister en tant que cache transparent.
Une autre raison est que le programme de mise en miroir basé sur http est beaucoup plus simple, il n'est pas nécessaire de vérifier le certificat tls-ssl ni de se soucier de l'invalidation du certificat ou des problèmes de configuration du serveur Web.
Il n'y a pas si longtemps, environ 20 ans plus tard, au début d'Internet, le trafic Internet et le trafic Internet étaient encore des jeux très coûteux. Par conséquent, http incluait également le protocole ftp, qui est sur le point d'être obsolète, en tant que moyen principal de fournir l'installation et la mise à jour pour la distribution de packages logiciels en ligne.
De même, Microsoft Windows et Office sont également mis à niveau à l'aide de http. Vous pouvez constater qu'il ne s'agit généralement pas du package d'installation téléchargé à partir du serveur de Microsoft, mais du serveur de cache que votre FAI a lui-même construit.