Pourquoi ny a-t-il pas de transport https pour loutil debian apt?

Il y en a. Vous devez installer le package apt-transport-https . Vous pouvez ensuite utiliser des lignes telles que

 deb https://some.server.com/debian stable main 

dans votre fichier sources.list. Mais ce nest généralement pas nécessaire, puisque tout le contenu est de toute façon public et cela ajoute une surcharge de chiffrement et une latence. Puisque vous ne faites pas confiance à la clé publique dun attaquant, même le trafic http est à labri des attaques MitM. apt vous avertira et ne parviendra pas à installer les packages lorsquun attaquant injecte des packages manipulés.

EDIT: Comme mentionné dans les commentaires, il est en effet plus sûr dutiliser le Dépôt TLS . Des recherches montrent que lutilisation dapt sur des référentiels non chiffrés peut en effet poser un risque de sécurité car le transport HTTP est vulnérable aux attaques de relecture.

Commentaires

• Non, la plupart des miroirs ne prennent pas en charge https. Simplement parce quil nest pas ‘ de crypter ce type de trafic. Les packages sont en cours de vérification de toute façon et les informations sont publiques.
• Je peux penser à quelques raisons pour lesquelles je préfère peut-être encore télécharger via TLS: 1) Je peux me soucier de ma confidentialité lors de linstallation des packages, et 2) là-bas pourrait être des bogues dans le code de vérification de la signature du paquet, quun MITM pourrait exploiter.
• @JackO ‘ Connor, alors que la première objection concernant la confidentialité est compréhensible, la seconde cest comme dire que jaime que les sites Web signent leur contenu avec des clés PGP parce quil peut y avoir des bogues dans le code TLS. PGP et TLS établissent la confiance; vous navez ‘ pas besoin des deux pour cela.
• @Marco votre réponse est incorrecte; De nombreux documents de recherche ont montré que les référentiels APT et YUM étaient vulnérables aux attaques de relecture lorsque le référentiel est accessible via HTTP, même avec des signatures GPG. Les référentiels ne doivent être accessibles que via TLS, 100% du temps.
• Voici larticle auquel @Joe Damato fait référence – voir aussi son Répondez ici

Votre lhypothèse est erronée: vous pouvez utiliser les téléchargements HTTPS. Il vous suffit de trouver un miroir qui le prend en charge et de mettre son URL dans votre liste de sources. Vous devrez installer le paquet apt-transport-https .

Debian ne fait pas de HTTPS téléchargements faciles car il y a très peu davantages. La distribution des paquets Debian inclut déjà un mécanisme pour vérifier les paquets: tous les paquets sont signés avec Gpg . Si un homme du milieu actif redirige votre trafic vers un serveur avec des packages corrompus, la corruption sera détectée car les signatures GPG ne seront pas valides. Utiliser GPG plutôt que HTTPS présente lavantage de protéger contre plus de menaces: non seulement contre lhomme du milieu actif sur la connexion de lutilisateur final, mais aussi contre un miroir non autorisé ou infecté ou dautres problèmes nimporte où dans la chaîne de distribution de paquets.

HTTPS offre un léger avantage de confidentialité en ce sens que cela masque les paquets que vous téléchargez. Cependant, un observateur passif peut toujours détecter le trafic entre votre ordinateur et un serveur de paquets, ainsi il saurait que vous téléchargez des paquets Debian. Ils pourraient également avoir une bonne idée des paquets que vous « téléchargez à partir de la taille des fichiers.

Le seul endroit où HTTPS aiderait est pour amorcer la confiance, pour obtenir une image dinstallation connue et valide. Debian ne le fait pas » Il semble que: il existe des sommes de contrôle du support dinstallation , mais uniquement via HTTP.

Commentaires

• Il existe une version HTTPS du support dinstallation: cdimage.debian.org/debian -cd
• Très peu davantages? Quen est-il de justi.cz/security/2019/01/22/apt-rce.html ?
• @AaronFranke Un bogue spécifique qui est plus facile à exploiter avec HTTP quavec HTTPS ne compte que très peu davantages, oui. Ce ‘ nest pas comme si HTTP avait une plus grande surface dattaque que HTTPS: en fait, HTTPS lui-même a une plus grande surface dattaque car il implique plus de code. Ce nest donc pas ‘ t même un avantage net du tout: cest ‘ un compromis entre deux risques marginaux.

Tout récemment, je suis tombé sur le problème avec le référentiel apt de ma société. Le problème était que si nous utilisons http standard transport nimporte qui dautre peut facilement obtenir un paquet. Comme lentreprise empaquete son propre logiciel propriétaire et ne veut pas le partager avec tout le monde, le transport http devient un problème. Ce nest pas une tragédie mais un problème. Il y a plusieurs façons de limiter laccès au paquet – pare-feu, restriction daccès au niveau du serveur Web, utilisant ssh comme moyen de transport. Une lecture assez facile à lire sur ce sujet peut être trouvée ici: Restreindre laccès à votre référentiel Debian privé

Dans notre cas, nous avons décidé dutiliser le transport https + lauthentification par certificat client. En bref, il suffit de:

1. Préparer les certificats auto-signés, le client et serveur (en utilisant easy-rsa);

2. Configurez le serveur Web qui fronts le référentiel pour naccepter que https; Dans le cas de nginx, cela pourrait ressembler à:

   server { listen 443; root /path/to/public; server_name secure_repo; ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:; ssl_prefer_server_ciphers on; ssl_client_certificate /etc/nginx/ssl/ca.crt; ssl_verify_client on; location / { autoindex on; } } 

3. Placez le certificat client, la clé client et le certificat CA dans / etc / apt / ssl et, dans le cas dUbuntu, ajoutez le fichier 00https à /etc/apt/apt.conf.d:

   Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

Gardez à lesprit que si vous utilisez un certificat auto-signé, il est important de désactiver la vérification dhôte: Verify-Host "false"; Si vous ne le faites pas, vous « ll attrapera une erreur: SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

Et voilà, il ny a plus daccès non autorisé au dépôt. Cest donc une chose assez utile et puissante.

Commentaires

• Merci pour cette excellente réponse. Mais je pense que le principal problème est toujours là. HTTPS devrait vraiment devenir le protocole par défaut pour les transferts sur le Web et les paquets Debian en particulier. Largument ne devrait pas être pourquoi HTTPS, mais pourquoi pas?
• @aalizadeh, je suis daccord avec vous, il y a une surcharge lors de lutilisation de https, mais il ny a pas de surcharge massive. Je pense que la principale raison pour laquelle https nest pas un transport par défaut est que certaines organisations interdisent explicitement tout trafic crypté (car elles veulent pouvoir se mettre le nez dans ce que font les employés sur Internet), ce qui signifie que les référentiels doivent prendre en charge les transports http et https. Il y a peut-être dautres considérations
• Utilisation de » Verify-Host  » false « ; « est faux, même avec des certificats auto-signés. Vous devez plutôt informer vos clients du certificat de serveur (correct).
• En effet, mais ici mes clients nétaient que des systèmes internes. Donc, au lieu de créer toute linfrastructure de pki appropriée, jai coupé le coin. Et oui, plus tard, pki a été réglé correctement et Verify-Host est faux; a été supprimé. Et oui, le point est valide.
• avec ubuntu xenial, les packages apt sont récupérés en tant quutilisateur non privilégié _apt, pouvez-vous mettre à jour ce fil avec des détails sur la façon dont vous avez géré ou résolu les problèmes dautorisation de fichier.

Notez quen raison de vulnérabilités telles que

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

… qui contourne la signature dInRelease, cest probablement une bonne idée de configurer le HTTPS de toute façon.

Et ce nest pas un exemple unique – de nombreux autres systèmes de mise à jour qui utilisent par défaut HTTP ont également connu des échecs de vérification de signature.

Les mécanismes de mise à jour critiques pour la sécurité devraient utiliser à la fois HTTPS et vérification de la signature pour être robuste. Chacun atténue léchec de lautre.

Commentaires

• Et maintenant celui-ci aussi: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. La signature InRelease nest pas suffisante .  » Mais déplacer tous les miroirs vers HTTPS prendra du temps et de la coordination! « . Oui. Commencez maintenant. Ce ne sera pas le dernier échec dInRelease.
• Voici ‘ un autre exemple, dun autre écosystème – Alpine. Son système de gestion de paquets nutilise ‘ pas HTTPS par défaut et repose uniquement sur la signature pour vérifier lintégrité des paquets …et cette vérification avait un bogue exploitable à distance en septembre 2018: justi.cz/security/2018/09/13/alpine-apk-rce.html Alpine devrait démarrer passer maintenant à lutilisation de HTTPS par défaut.
• (Divulgation complète: mon propre sens, mais cest ‘ la seule référence que je connaisse of), voici une liste de tous les échecs des échecs de vérification de signature côté client dont je ‘ ai connaissance. La liste est de taille non triviale et augmente régulièrement. Ajoute la bienvenue. gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

Pour le cas dutilisation » anonymat « , il y a aussi apt-transport-tor qui vous permet ensuite de mettre des URI comme tor+http:// dans fichiers sources.list. Cest une bien meilleure protection de lanonymat que le simple cryptage de la connexion à votre miroir.

Par exemple, un observateur local saurait toujours que vous mettez à jour ou installez un logiciel même avec HTTPS, et peut probablement faire des suppositions décentes pour savoir lesquels de ceux que vous faites (et peut-être même quels paquets, en fonction de leur taille).

Debian fournit des dépôts APT via les «services Onion» de Tor afin que vous puissiez obtenir un chiffrement de bout en bout (similaire à TLS) sans avoir à faire confiance au système de nom de domaine. Voir onion.debian.org pour tous les services Debian disponibles de cette manière. Le référentiel FTP principal de Debian se trouve à vwakviie2ienjx6t.onion