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 qu'ours du petit cerveau du côté des développeurs, je ne comprends pas pourquoi la liste des référentiels est http://security.ubuntu.comet les autres httpsites (non sécurisés) répertoriés dans /etc/apt/sources.list. Sans correspondance de chaîne de certificats, cela apparaît comme "demandez à n'importe quel répondeur une liste de packages à mettre à jour" au lieu de "demandez au site ubuntu.com ..."

Un réseau peut-il choisir d'usurper les sites de mise à jour, et est-ce 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 étant signé par Ubuntu et uniquement Ubuntu. Cela vérifie que le fichier que vous recevez a été autorisé par Ubuntu à un moment donné et n'a pas été modifié ou falsifié depuis.

Une explication technique de la façon dont cela fonctionne est disponible à partir d'Ubuntu (et de Debian qui utilise le même système).

En raison de l'utilisation de HTTP au lieu de HTTPS, oui, les écoutes peuvent voir quels fichiers vous téléchargez, mais la confidentialité ne sera probablement pas votre préoccupation dans ce cas. Une tentative man-in-the-middle de modifier les packages pour injecter du code nuisible échouerait toujours car elle briserait le mécanisme de signature.

Un problème possible dans ce mécanisme de signature est qu'il ne garantit pas que vous obtenez la version la plus récente du package (en effet, les miroirs sont parfois lents à mettre à jour). Pour aider à atténuer ce problème, le fichier de version signée inclut une date «valide jusqu'à» après laquelle tous les fichiers auxquels il fait référence doivent être considérés comme périmés. Il serait plausible pour un homme du milieu de remplacer une archive par une version antérieure non modifiée de l'archive dans cette date de validité jusqu'à ce que votre APT pense qu'il n'y a pas de mises à jour. Mais ils ne peuvent pas apporter de modifications arbitraires aux packages ni remonter dans le temps au-delà d'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. En substance, vous devez seulement faire confiance à Ubuntu, pas 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, il y a eu 2 exploits graves d'exécution de code à distance trouvés dans apt à cause de la vérification du paquet bogué. Bulletins de sécurité ici et ici .

C'est bien pire que les inquiétudes concernant la fuite de confidentialité / d'informations et la version périmée du package; cela permet l'exécution de code arbitraire en tant que root, échec de sécurité complet. Et le fait est que ces attaques auraient été évitées si https avait été utilisé à la place de http.

Cela prouve que le principe de défense en profondeur s'applique ici autant qu'ailleurs. Les nombreuses affirmations flottant autour du fait que https n'offre aucun ou un avantage minimal en termes de sécurité dans le contexte d'apt sont tout simplement incorrectes, comme l'ont montré ces exploits.

La question devient alors de savoir si les avantages de la sécurité de https en valent le coût en termes de mise en cache, de surcharge supplémentaire, etc. .

Supplément important: en fait, comme la mise à niveau et l'installation initiale sont téléchargées en ligne, cela prend beaucoup de trafic, et la source de ce trafic, c'est-à-dire les flux de code binaire et texte, est reproductible. Il existe donc un grand nombre de passerelles et de dispositifs de cache sur Internet pour cela. Un nombre considérable de FAI ont mis en place un cache basé sur le protocole http afin d'économiser la bande passante d'exportation, et le protocole https ne peut pas 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 s'inquiéter de l'invalidation du certificat ou des problèmes de configuration du serveur Web.

Il n'y a pas si longtemps, environ 20 ans, au début d'Internet, https et le trafic Internet étaient encore des jeux très chers. Par conséquent, http incluait également le protocole ftp, qui est presque obsolète, comme principal moyen 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 que ce n'est généralement pas le package d'installation téléchargé depuis le serveur de Microsoft, mais le serveur de cache auto-construit de votre FAI.