Pourquoi n'y a-t-il pas de transport https pour l'outil debian apt?

45

Avec toute la paranoïa qui accompagne les révélations de la NSA et tout le reste, je me demande pourquoi le mécanisme d’installation du paquet Debian ne prend pas en charge le protocole HTTPS pour son transport, sans parler de l’utiliser par défaut.

Je sais que les paquets debian ont une sorte de validation de signature utilisant GPG, mais je ne pense toujours pas qu’utiliser le transport HTTPS au lieu de HTTP serait trop difficile, compte tenu de l’importance cruciale que cela a pour la sécurité.

Edit: Je veux surtout me protéger des attaques MitM (y compris uniquement du reniflage du trafic), et non des administrateurs en miroir Debian. Les référentiels HTTP mettent toute la configuration du système sur la table, si quelqu'un m'inflige du trafic sur mes miroirs Debian.

zaadeh
la source
pas besoin ... c'est du contenu public ... les paquets ont signé des sommes de contrôle
Skaperen
ok, vous ne voulez donc pas que votre administrateur réseau sache quels paquets vous installez / mettez à niveau.
Skaperen
administrateurs, ou tout autre espion.
zaadeh

Réponses:

49

Il y a. Vous devez installer le package apt-transport-https. Ensuite, vous pouvez utiliser des lignes comme

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

dans votre sources.listdossier. Mais en général, cela n’est pas nécessaire, car l’ensemble du contenu est public et ajoute une surcharge de chiffrement et de la latence. Puisque vous ne faites pas confiance à la clé publique d'un attaquant, même le trafic http est à l'abri des attaques MitM. aptvous avertit et ne parvient pas à installer les packages lorsqu'un attaquant injecte des packages manipulés.

EDIT: Comme mentionné dans les commentaires, il est effectivement plus sûr d’utiliser le référentiel TLS . Les recherches montrent que l'utilisation d'apt 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 par rejeu.

Marco
la source
7
Non, la plupart des miroirs ne prennent pas en charge https. Tout simplement parce que le chiffrement de ce type de trafic n’a pas grand sens. Les paquets sont quand même vérifiés et les informations sont publiques.
Marco
4
Je peux penser à deux ou trois raisons pour lesquelles je préférerais peut-être continuer à télécharger via TLS: 1) la confidentialité de mes informations personnelles lors de l’installation de packages, et 2) des erreurs dans le code de vérification de la signature des packages, qu’un opérateur MITM pourrait exploiter.
Jack O'Connor
2
@ JackO'Connor, alors que la première objection à la confidentialité est compréhensible, la seconde revient à dire que j'aime bien que les sites Web signent leur contenu avec des clés PGP car il pourrait y avoir des bogues dans le code TLS. PGP et TLS établissent tous deux la confiance; vous n'avez pas besoin des deux pour cela.
Paul Draper
7
@Marco, ta réponse est incorrecte; de nombreux travaux de recherche ont montré que les référentiels APT et YUM étaient vulnérables aux attaques par rejeu 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.
Joe Damato,
6
Voici le papier @ Joe Damato fait référence - voir aussi sa réponse ici
SauceCode
17

Votre hypothèse est fausse: vous pouvez utiliser les téléchargements HTTPS. Vous devez juste trouver un miroir qui le supporte et mettre son URL dans votre liste de sources. Vous aurez besoin d'installer le apt-transport-httpspaquet.

Debian ne facilite pas les téléchargements HTTPS car il y a très peu d'avantages. La distribution de paquets Debian inclut déjà un mécanisme de vérification des paquets: tous les paquets sont signés avec Gpg . Si un intermédiaire actif redirige votre trafic vers un serveur dont les packages sont corrompus, la corruption sera détectée car les signatures GPG ne seront pas valides. L'utilisation de GPG plutôt que de HTTPS présente l'avantage de protéger contre davantage de menaces: non seulement contre l'homme actif au milieu de la connexion de l'utilisateur final, mais également contre un miroir non fiable ou infecté ou d'autres problèmes n'importe où dans la chaîne de distribution de paquets. .

HTTPS offre un léger avantage en termes de confidentialité en masquant les packages que vous téléchargez. Cependant, un observateur passif peut toujours détecter le trafic entre votre ordinateur et un serveur de paquets, afin de savoir que vous êtes en train de télécharger 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 serait pour l’amorçage de la confiance, pour obtenir une image d’installation valide connue. Debian ne semble pas fournir cela: il existe des sommes de contrôle du support d'installation , mais uniquement via HTTP.

Gilles, arrête de faire le mal
la source
Il existe une version HTTPS du support d'installation: cdimage.debian.org/debian-cd
Fedir RYKHTIK
2
Très peu d'avantages? Qu'en est-il de justi.cz/security/2019/01/22/apt-rce.html ?
Aaron Franke
@AaronFranke Un bogue spécifique, plus facile à exploiter avec HTTP qu'avec HTTPS, représente un très petit avantage, oui. Ce n'est pas comme si HTTP avait une surface d'attaque plus grande que HTTPS: en fait, HTTPS lui-même a une surface d'attaque plus grande puisqu'il implique plus de code. Ce n’est donc même pas un avantage net: c’est un compromis entre deux risques marginaux.
Gilles, arrête de faire le mal le
9

Récemment, j'ai rencontré le problème avec le référentiel apt de mon entreprise. Le problème était que si nous utilisions le transport http standard, tout le monde pourrait facilement obtenir un paquet. Comme la société empaquette son propre logiciel propriétaire et ne veut pas la partager avec tout le monde, le transport http devient un problème. Pas une tragédie mais un problème. Il existe différentes manières de limiter l'accès aux packages: pare-feu, restriction d'accès au niveau du serveur Web, utilisation de ssh en tant que transport. Vous trouverez assez facilement la lecture sur ce sujet ici: Restreindre l'accès à votre référentiel Debian privé

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

  1. Préparer des certificats auto-signés, client et serveur (avec easy-rsa);
  2. Configurez le serveur Web auquel le référentiel frontal n'accepte 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 d’Ubuntu, 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"; };

N'oubliez pas que si vous utilisez un certificat auto-signé, il est important de désactiver la vérification de l'hôte. Verify-Host "false";Si vous ne le faites pas, vous obtiendrez une erreur: SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'

Et voilà, il n'y a plus d'accès non autorisé au référentiel. C'est donc une chose très utile et puissante.

at0S
la source
3
Merci pour la bonne réponse. Mais je pense que le problème principal est toujours là. HTTPS devrait vraiment devenir le protocole par défaut pour les transferts sur le Web et les paquets Debian en particulier. L'argument ne devrait pas être pourquoi HTTPS, mais pourquoi pas?
zaadeh
1
@aalizadeh, je suis d'accord avec vous, l'utilisation de https entraîne des frais généraux, mais pas de frais généraux élevés. Je pense que la raison principale pour laquelle https n'est pas un transport par défaut est que certaines organisations interdisent explicitement tout trafic chiffré (car elles veulent pouvoir se mêler de ce que les employés font sur Internet), ce qui signifie que les référentiels doivent prendre en charge les transports http et https. Peut-être y a-t-il d'autres considérations
at0S
1
L'utilisation de »Verify-Host" false ";« est incorrecte, même avec des certificats auto-signés. Vous devez plutôt informer vos clients du certificat de serveur (correct).
Axel Beckert
1
En effet, mais ici mes clients n'étaient que des systèmes internes. Donc, au lieu de créer toute l'infrastructure pki appropriée, je coupe le coin. Et oui, plus tard, pki a été réglé correctement et Verify-Host false; était retirer. Et oui, le point est valide.
at0S
1
Avec Ubuntu Xenial, les packages apt sont récupérés en tant qu'utilisateur _apt sans privilège. Pourriez-vous s'il vous plaît mettre à jour ce fil avec des détails sur la façon dont vous avez géré ou résolu les problèmes d'autorisation de fichiers.
David le
7

Notez qu'en raison de vulnérabilités telles que

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

... qui contourne la signature InRelease, il est probablement préférable de configurer le protocole HTTPS.

Royce Williams
la source
1
Et maintenant, celui-ci également: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501. La signature d'InRelease n'est 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 d'InRelease.
Royce Williams
1
Voici un autre exemple, issu d'un écosystème différent - Alpine. Son système de gestion de paquets n'utilise pas le protocole HTTPS par défaut et repose uniquement sur la signature pour vérifier l'intégrité des paquets ... et que cette vérification avait un bogue exploitable à distance en septembre 2018: justi.cz/security/2018/09/13/alpine- apk-rce.html Alpine devrait maintenant commencer à utiliser HTTPS par défaut.
Royce Williams
4

Pour le cas d'utilisation "anonymat", il existe également une apt-transport-torpossibilité qui vous permet de mettre des URI comme tor+http://dans les fichiers sources.list. C'est une bien meilleure protection de l'anonymat que le simple cryptage de la connexion à votre miroir.

Par exemple, un observateur local sait toujours que vous mettez à jour ou installez un logiciel même avec HTTPS, et peut probablement deviner de façon décente lequel de ceux que vous êtes en train de faire (et peut-être même quels paquets, en fonction de leur taille).

Debian fournit des référentiels APT via Tor "Onion Services" afin que vous puissiez obtenir un cryptage de bout en bout (similaire à TLS) sans avoir à faire confiance au système de noms de domaines. Consultez onion.debian.org pour tous les services Debian disponibles de cette manière. Le référentiel FTP principal de Debian est àvwakviie2ienjx6t.onion

meejah
la source