apt-get
N'utiliser https ou tout type de cryptage? Y a-t-il un moyen de le configurer pour l'utiliser?
apt-get
N'utiliser https ou tout type de cryptage? Y a-t-il un moyen de le configurer pour l'utiliser?
Réponses:
apt-get
(et d’autres commandes de manipulation de paquetages, qui sont une interface pour les mêmes bibliothèques APT) peuvent utiliser HTTP, HTTPS et FTP (et les systèmes de fichiers montés). Si vous spécifiez des https://
URL dans /etc/apt/sources.list
et /etc/apt/sources.list.d/*
, APT utilisera HTTPS.
APT vérifie la signature des packages. Vous n'avez donc pas besoin d'un moyen de transport permettant l'authentification des données. Si un attaquant modifie les fichiers que vous téléchargez, cela sera remarqué. Utiliser une vérification de signature est préférable à une connexion HTTPS, car elle détectera une attaque sur le serveur à partir duquel vous effectuez le téléchargement, et pas seulement une attaque en transit.
Plus précisément, le flux de données (simplifié) pour un package est le suivant:
HTTPS garantit que l'étape 4 se déroule correctement. Les signatures de package garantissent que les étapes 2 à 4 se déroulent correctement.
En fait, il existe un petit avantage pour HTTPS pour l'étape 4: les signatures de package garantissent uniquement l'authenticité du package. À l'étape 4, un attaquant pourrait emprunter l'identité d'un serveur légitime et diffuser des versions obsolètes 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é de votre ordinateur que vous auriez corrigée s'il n'y avait pas eu d'attaque. Ce scénario n’est pas très réaliste, car il nécessite un attaquant actif (il devrait donc s'agir de quelqu'un qui contrôle votre connexion Internet), mais cela pourrait se produire en principe.
L'autre avantage de HTTPS serait si vous essayez de cacher le fait que vous téléchargez des paquets Ubuntu à quelqu'un qui surveille votre connexion réseau. Même dans ce cas, l’espionneur pouvait voir à quel hôte vous vous connectiez; Si vous vous connectez à un miroir Ubuntu et téléchargez des centaines de mégaoctets, il est évident que vous téléchargez des paquets Ubuntu. L’espionneur pourrait également déterminer les paquets que vous téléchargez à partir de la taille des fichiers. Donc, HTTPS ne serait utile que si vous téléchargez à partir d'un serveur qui propose également d'autres fichiers de taille similaire - je ne vois aucun intérêt, à l'exception des packages tiers, et uniquement dans des circonstances très inhabituelles.
Pour rappel, l'avantage habituel du protocole HTTPS, à savoir que vous savez que vous êtes connecté au serveur réel, est inutile lorsque vous téléchargez des packages Ubuntu. La vérification de la signature sur les paquets donne une garantie plus forte que ce que HTTPS peut fournir.
apt-get update
je rapportais une erreur en essayant d'accéder aux liens. Avec les ppas: pareil. Quelqu'un at-il essayé?
archive.ubuntu.com
n'en a pas . Vous pouvez vérifier dans votre navigateur si un serveur le prend en charge en ajoutant https: // à l'URL et en vérifiant si vous obtenez une liste de répertoires, etc.
Avec APT, le plus important n’est généralement pas que votre connexion soit cryptée, mais que les fichiers que vous recevez n’ont pas été falsifiés.
APT dispose d'une vérification de signature intégrée pour s'assurer de cela.
Le chiffrement 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 guère controversé: ce sera la même chose que des milliers d’autres utilisateurs d’Ubuntu sont en train de télécharger et les fichiers ne contiennent rien d’autre que ce n’est rien. t disponible gratuitement sur de nombreux serveurs. Néanmoins, si vous avez besoin de confidentialité concernant les packages que vous téléchargez, HTTPS peut être utilisé (spécifiez-le dans votre fichier sources.list).
La vérification de la signature intégrée à APT garantit que les fichiers que vous recevez n'ont pas été falsifiés. Peu importe l’origine des fichiers et il est même possible d’avoir des proxys ou des proxys inversés entre vous et le serveur afin de réduire la charge du serveur ou de vous accélérer. La vérification de la signature garantit toujours que vous obtenez le fichier non modifié correspondant à la signature qui ne peut être produite de manière cryptographique qu'avec le fichier d'origine et une copie de la clé privée d'Ubuntu.
Si vous passez à HTTPS, vous ne pourrez plus utiliser les serveurs proxy pour accélérer l'accès ou réduire la charge. Et cela n'apporterait aucune assurance supplémentaire quant à la non-falsification que la vérification de la signature d'APT ne donne pas déjà. Cela signifierait toutefois que les espions (tels que votre fournisseur de services Internet) ne pourront pas voir les paquets que vous téléchargez (ce qui n'est probablement pas confidentiel et, comme Gilles l'a fait remarquer, ils pourraient deviner à partir de la taille du fichier).
apt update
et un homme au milieu vous nourrissez de faux index, apt prend avec bonheur ce que l’homme au milieu vous donne et écrit dans / var / lib / apt / lists. Ce n'est pas seulement avec un homme diabolique au milieu, mais comme si vous êtes sur le WiFi de l'hôtel et que vous êtes redirigé vers une page de connexion, si vous apt update
vous connectez avant de vous connecter, votre / var / lib / apt / listes sera mis à la corbeille. avec la page d'accueil de l'hôtel HTML. FAUX! Quoi qu'il en soit, la vérification de base des certifications TLS éliminerait cela immédiatement.
Les versions récentes d'APT intègrent la prise en charge de TLS. Il vous suffit donc de remplacer les URL de miroir de votre référentiel de https
paquets par des -prefixées. 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 main
Cela est utile, même si APT inclut son propre protocole de signature pour garantir que les packages ne sont pas falsifiés, car il peut y avoir des bogues dans APT (comme il y a eu: CVE-2016-1252 , CVE-2019-3462 ). Les protocoles HTTP / TLS et leurs chiffrements sont soumis à un examen minutieux. Par conséquent, une vulnérabilité grave du jour zéro est beaucoup moins probable si vous ajoutez cette couche de sécurité.
Je pense que cette question pourrait utiliser une réponse avec des instructions pour le profane, alors…
APT n'utilise toujours pas HTTPS par défaut dans les versions quotidiennes d'Ubuntu 19.10 (Eoan) (en cours de développement). Vous pouvez le vérifier en examinant le fichier /etc/apt/sources.list et en notant que toutes les URL sources utilisent le schéma "http:".
Pour le configurer pour utiliser HTTPS, on peut suivre les instructions suivantes:
Tout d’abord , trouvez un miroir d’archive Ubuntu officiel digne de confiance qui prend en charge HTTPS:
Par exemple, je considère que la Wikimedia Foundation est digne de confiance. J'ai donc visité l' URL miroir http://mirrors.wikimedia.org/ubuntu/ et je l'ai par la suite modifiée en https://mirrors.wikimedia.org/ubuntu/ , qui est résolue avec succès.
Si vous utilisez Firefox (67.0.4) et que vous avez l' extension HTTPS Everywhere (2019.6.27) installée avec la fonctionnalité "Crypter tous les sites éligibles" activée (via le panneau de boutons de la barre d'outils), vous pouvez omettre les étapes (4) et (5). parce que l'extension modifiera automatiquement l'URL pour utiliser HTTPS, ce qui permet de déterminer immédiatement si la version "https:" de l'URL sera résolue.
Deuxièmement , mettez à jour votre liste de sources APT:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup
pour sauvegarder votre liste de sources de mise à jour.sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.list
par l' URL de base du miroir de votre miroir préféré, puis exécutez la commande.Troisièmement , vous devriez examiner le contenu du répertoire /etc/apt/sources.list.d/ pour rechercher les sources "http:" qui pourraient être remplacées par "https:" après l'installation de logiciels en dehors de l'archive Ubuntu.
Par exemple, le package de code Visual Studio de Microsoft ajoute à ce répertoire un fichier vscode.list qui spécifie une URL "http:". Changer simplement le schéma d'URL de "http:" à "https:" permet les mises à jour via HTTPS.
Pensez à sauvegarder ces fichiers source avant de les modifier.
Enfin , effectuez une mise à jour pour vous assurer que les mises à jour fonctionneront correctement:
sudo apt-get update
commande.sudo cp /etc/apt/sources.list.backup /etc/apt/sources.list
commande.Il convient également de noter qu’il existe un paquet apt-transport-https pour ajouter la prise en charge 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
.