web-dev-qa-db-fra.com

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

Avec toute la paranoïa accompagnant les révélations NSA et tout le reste, je me demande pourquoi le mécanisme d'installation du paquet debian ne prend pas en charge HTTPS pour son transport, sans parler de son utilisation par défaut.

Je sais que les paquets Debian ont une sorte de validation de signature en utilisant GPG, mais je ne pense toujours pas que l'utilisation du transport HTTPS au lieu de HTTP serait trop difficile, étant donné à quel point cela est crucial pour la sécurité.

Edit: Je veux surtout me protéger contre les attaques MitM (y compris juste le reniflage du trafic), pas les administrateurs miroir Debian. Les référentiels HTTP mettent toute la configuration du système sur la table, si quelqu'un espionne mon trafic vers les miroirs Debian.

debiansecurityapthttps
47
zaadeh

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 ton sources.list fichier. Mais ce n'est généralement pas nécessaire, car le contenu entier est de toute façon public et il ajoute une surcharge de chiffrement et une latence. Comme vous ne faites pas confiance à la clé publique d'un attaquant, même le trafic http est à l'abri des attaques MitM. apt vous avertira et échouera à installer les packages lorsqu'un attaquant injecte des packages manipulés.

EDIT: Comme mentionné dans les commentaires, il est en effet plus sûr d'utiliser le référentiel TLS . La recherche montre 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 de relecture.

50
Marco

Votre hypothèse est fausse: vous pouvez utiliser les téléchargements HTTPS. Il vous suffit de trouver un miroir qui le supporte et de mettre son URL dans votre liste de sources. Vous devrez installer le apt-transport-https package.

Debian ne facilite pas les téléchargements HTTPS car il y a très peu d'avantages. 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. L'utilisation de GPG plutôt que de HTTPS présente l'avantage de protéger contre plus de menaces: non seulement contre l'homme actif au milieu de la connexion de l'utilisateur final, mais également contre un miroir malveillant ou infecté ou d'autres problèmes n'importe où dans la chaîne de distribution de packages. .

HTTPS fournit un léger avantage de confidentialité en ce qu'il masque 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 qu'il sache que vous téléchargez des paquets Debian. Ils pourraient également avoir une bonne idée des packages que vous téléchargez à partir des tailles de fichier.

Le seul endroit où HTTPS aiderait est pour la confiance d'amorçage, pour obtenir une image d'installation valide connue. Debian ne semble pas fournir cela: il y a des sommes de contrôle de support d'installation , mais uniquement sur HTTP.

17
Gilles 'SO- stop being evil'

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 le transport http standard, n'importe qui d'autre peut obtenir un package facilement. Comme la société met en package son propre logiciel propriétaire et ne veut pas le partager avec tout le monde, le transport http devient un problème. Pas une tragédie mais un problème. Il existe deux façons de limiter l'accès au package: pare-feu, restriction d'accès au niveau du serveur Web, utilisation de ssh comme transport. Assez facile à consommer pour lire sur ce sujet se trouve ici: Restreindre l'accès à votre dépôt Debian privé

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

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

  2. Configurer le serveur Web qui fait face au référentiel pour accepter uniquement https; En 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. Mettez le certificat client, la clé client et le certificat ca dans/etc/apt/ssl et, dans le cas avec 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"; };

Gardez à l'esprit 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 c'est parti, il n'y a plus d'accès non autorisé au référentiel. C'est donc une chose assez utile et puissante.

9
at0S

Notez qu'en raison de vulnérabilités comme

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

... qui contourne la signature d'InRelease, c'est probablement une bonne idée de configurer HTTPS de toute façon.

Et ce n'est pas un exemple unique - de nombreux autres systèmes de mise à jour qui utilisent par défaut HTTP ont également eu un historique d'échecs de vérification de signature.

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

8
Royce Williams

Pour le cas d'utilisation "anonymat", il existe également apt-transport-tor qui vous permet ensuite 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 faire des suppositions décentes quant à celles que vous faites (et peut-être même quels packages, en fonction de la taille).

Debian fournit APT référentiels via Tor "Onion services" 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 oignon .debian.org pour tous les services Debian disponibles de cette façon. Le référentiel FTP Debian principal est à vwakviie2ienjx6t.onion

4
meejah