Fait apt-get utiliser https ou tout autre type de cryptage ? Existe-t-il un moyen de le configurer pour l'utiliser ?
Réponses
Trop de publicités?
apt-get (et d'autres commandes de manipulation de paquets, qui sont une interface avec les mêmes bibliothèques APT) peut utiliser HTTP, HTTPS et FTP (et les systèmes de fichiers montés). Si vous spécifiez https:// URLs en /etc/apt/sources.list y /etc/apt/sources.list.d/* alors APT utilisera HTTPS.
APT vérifie la signature des paquets. Il n'est donc pas nécessaire d'avoir un moyen de transport qui assure l'authentification des données. Si un attaquant modifie les fichiers que vous téléchargez, cela sera remarqué. L'utilisation d'une vérification de la signature est préférable à l'utilisation d'une connexion HTTPS, car elle permettra de détecter une attaque sur le serveur à partir duquel vous téléchargez, et pas seulement une attaque en transit.
Plus précisément, le flux de données (simplifié) pour un paquet est le suivant :
- Le paquet est produit sur une machine de construction.
- Le paquet est signé sur la machine de construction.
- Le paquet signé est copié sur un miroir de téléchargement.
- Vous téléchargez le paquet.
HTTPS garantit que l'étape 4 se déroule correctement. Les signatures des paquets garantissent que les étapes 2 à 4 se déroulent correctement.
En fait, il y a un petit avantage à utiliser HTTPS pour l'étape 4 : les signatures du paquet garantissent seulement que le paquet est authentique. Un attaquant à l'étape 4 pourrait se faire passer pour un serveur légitime et servir des versions périmées du paquet. Par exemple, l'attaquant pourrait vous empêcher de télécharger des mises à jour de sécurité, dans l'espoir d'exploiter une vulnérabilité sur votre machine que vous auriez corrigée sans l'attaque. Ce scénario n'est pas très réaliste, car il nécessite un attaquant actif (il faudrait donc que ce soit quelqu'un qui contrôle votre connexion Internet), mais il pourrait se produire en principe.
L'autre avantage de HTTPS est que vous essayez de cacher le fait que vous téléchargez des paquets Ubuntu à quelqu'un qui espionne votre connexion réseau. Si vous vous connectez à un miroir Ubuntu et téléchargez des centaines de mégaoctets, il est clair que vous téléchargez des paquets Ubuntu. L'espion pourrait également déterminer quels paquets vous téléchargez à partir de la taille des fichiers. Ainsi, HTTPS ne serait utile que si vous téléchargez à partir d'un serveur qui offre également d'autres fichiers de taille similaire - je ne vois pas l'intérêt sauf pour les paquets tiers, et seulement dans des circonstances très inhabituelles.
Je le répète : l'avantage habituel de HTTPS, qui est que vous savez que vous êtes connecté au vrai serveur, est inutile lorsque vous téléchargez des paquets Ubuntu. La vérification des signatures sur les paquets donne une garantie plus forte que ce que HTTPS peut fournir.
thomasrutter
Points
33791
Avec l'APT, le plus important n'est généralement pas que votre connexion soit chiffrée, mais que les fichiers que vous recevez n'aient pas été altérés.
APT a une vérification de signature intégrée pour garantir cela.
Le cryptage empêcherait les oreilles indiscrètes de voir ce que vous téléchargez, mais ce que vous téléchargez (et demandez) n'est pas contesté : ce sera la même chose que ce que des milliers d'autres utilisateurs d'Ubuntu téléchargent et les fichiers ne contiennent rien qui ne soit pas librement disponible sur de nombreux serveurs. Néanmoins, si vous avez besoin de confidentialité concernant les paquets que vous téléchargez, HTTPS peut être utilisé (spécifiez-le dans votre sources.list).
La vérification des signatures intégrée à APT garantit que les fichiers que vous recevez n'ont pas été altérés. La provenance des fichiers n'a pas vraiment d'importance et il est même possible d'avoir des proxies ou des reverse proxies entre vous et le serveur pour réduire la charge du serveur ou vous accélérer. La vérification de la signature garantit toujours que vous recevez le fichier non modifié, correspondant à la signature qui ne peut être produite cryptographiquement qu'avec le fichier original et une copie de la clé privée d'Ubuntu.
Si vous passez au protocole HTTPS, vous ne pourrez plus tirer parti des serveurs proxy pour accélérer l'accès ou réduire la charge. De plus, la vérification de la signature de l'APT n'apporte aucune garantie supplémentaire de non-violation. Cela signifierait cependant que les oreilles indiscrètes (comme votre fournisseur d'accès) ne pourront pas voir quels paquets vous téléchargez (ce qui n'est probablement pas confidentiel, et comme Gilles l'a souligné, ils pourraient le deviner à partir de la taille du fichier).
Patrick Dark
Points
301
Je pense que cette question aurait besoin d'une réponse avec des instructions pour le profane, donc
APT n'utilise toujours pas HTTPS par défaut dans les constructions quotidiennes d'Ubuntu 19.10 (Eoan) (qui est toujours en développement). On peut le vérifier en examinant le fichier /etc/apt/sources.list et en notant que toutes les URLs des sources utilisent le schéma d'URL "http :".
Pour le configurer afin d'utiliser HTTPS, on peut suivre les instructions suivantes :
Premier trouver un miroir d'archives officiel Ubuntu digne de confiance qui supporte HTTPS :
- Naviguez jusqu'au Miroirs d'archives officiels pour Ubuntu page web.
- Dans le tableau de cette page Web, identifiez les miroirs qui (A) sont hébergés sur des sites Web que vous considérez comme fiables, (B) ont un miroir "http :" et, éventuellement, (C) répondent à vos préférences en matière de proximité géographique, de vitesse du serveur et de fraîcheur des mises à jour.
- Dans le tableau de cette page web, cliquez sur le lien "http" d'un miroir identifié à l'étape (2) pour visiter la version "http :" du miroir.
- Dans la barre d'adresse du navigateur, remplacez manuellement "http :" dans l'URL de la page Web par "https :".
- Naviguez à nouveau vers le miroir (via l'URL "https :") pour voir s'il se résout.
Par exemple, je considère que la Fondation Wikimedia est digne de confiance, j'ai donc visité le site de la http://mirrors.wikimedia.org/ubuntu/ et l'a modifié par la suite en https://mirrors.wikimedia.org/ubuntu/ qui se résout avec succès.
Si vous utilisez Firefox (67.0.4) et que vous disposez de l'option HTTPS partout (2019.6.27) installée avec la fonction "Crypter tous les sites admissibles" activée (via le panneau de boutons de la barre d'outils), les étapes (4) et (5) peuvent être omises car l'extension modifiera automatiquement l'URL pour utiliser HTTPS, ce qui permettra de déterminer plus immédiatement si la version "https :" de l'URL sera résolue.
Deux , mettez à jour votre liste de sources APT :
- Exécuter la commande
sudo cp /etc/apt/sources.list /etc/apt/sources.list.backuppour sauvegarder votre liste de sources de mise à jour. - Remplacez l'URL de la base du miroir - affichée ici en tant que https://mirrors.wikimedia.org -dans la commande
sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.listavec le miroir URL de base de votre miroir préféré et, ensuite, exécutez la commande.
Troisièmement, vous devriez examiner le contenu du répertoire /etc/apt/sources.list.d/ à la recherche de sources "http :" qui pourraient être changées en "https :" après l'installation de logiciels en dehors de l'archive Ubuntu.
Par exemple, le paquetage Visual Studio Code de Microsoft ajoute à ce répertoire un fichier vscode.list qui spécifie une URL "http :". Le simple fait de changer le schéma d'URL de "http :" à "https :" permet d'effectuer des mises à jour via HTTPS.
Pensez à sauvegarder ces fichiers sources avant de les modifier.
Enfin , effectuez une mise à jour pour vous assurer que les mises à jour fonctionneront correctement :
- Exécuter le
sudo apt-get updatecommandement. - Si cela ne fonctionne pas comme prévu, restaurez le(s) fichier(s) de liste source de sauvegarde que vous avez fait(s) en exécutant la commande
sudo cp /etc/apt/sources.list.backup /etc/apt/sources.listcommandement.
Il convient également de noter qu'il y a une apt-transport-https pour ajouter le support HTTPS à APT. Cependant, ce paquet est apparemment inutile selon la page web https://launchpad.net/ubuntu/eoan/+package/apt-transport-https et n'est plus nécessaire depuis APT 1.5 selon les informations affichées après l'exécution de la commande apt-cache show apt-transport-https .
Leif Arne Storset
Points
363
Les versions récentes d'APT intègrent la prise en charge de TLS. Il vous suffit donc de remplacer les URL des miroirs de votre dépôt de paquets par les suivantes https -préfixés. Pour Debian, cela pourrait ressembler à ceci :
deb https://deb.debian.org/debian/ stretch main
deb https://deb.debian.org/debian-security stretch/updates main
deb https://deb.debian.org/debian/ stretch-updates mainC'est utile, même si APT inclut son propre protocole de signature pour garantir que les paquets ne sont pas altérés, parce qu'il peut y avoir des bogues dans APT (comme il y en a eu) : CVE-2016-1252 , CVE-2019-3462 ). Les protocoles HTTP/TLS et leurs chiffres font l'objet d'un examen approfondi, de sorte qu'une grave vulnérabilité de type "jour zéro" est beaucoup moins probable si vous ajoutez cette couche de sécurité.
Jereme Hall
Points
83
Apt 1.5 La version 2017 prend en charge https dès le départ. Il n'est plus nécessaire d'installer le paquet apt-transport-https séparément.
Il existe de multiples attaques et vulnérabilités contre apt avec des dépôts http :
