apt-transport-https - Transport APT pour le téléchargement via le protocole HTTP Secure (HTTPS)
Ce transport APT permet l'utilisation de référentiels accessibles via le protocole HTTP Secure (HTTPS), également appelé HTTP sur TLS. Il est disponible par défaut depuis apt 1.5 et était disponible avant cela dans le package apt-transport-https. Notez qu'un transport n'est jamais appelé directement par un utilisateur mais utilisé par les outils APT en fonction de la configuration de l'utilisateur.
HTTP est en soi un protocole de transport non crypté (comparez apt-transport-http(1)), qui, comme indiqué par le S ajouté, est enveloppé dans une couche cryptée connue sous le nom de Transport Layer Security (TLS) pour fournir un cryptage de bout en bout. Un attaquant suffisamment capable peut toujours observer les partenaires de communication et une analyse plus approfondie de la communication cryptée peut encore révéler des détails importants. Un aperçu des méthodes de transport alternatives disponibles est donné dans sources.list(5).
Le protocole HTTPS est basé sur le protocole HTTP, donc toutes les options prises en charge par apt-transport-http(1) sont également disponibles via Acquire::https et prendront par défaut les mêmes valeurs spécifiées pour Acquire: : http. Cette page de manuel ne documentera que les options uniques à https.
Par défaut, tous les certificats approuvés par le système (voir paquet ca-certificates) sont utilisés pour la vérification du certificat du serveur. Une autre autorité de certification (CA) peut être configurée avec l'option Acquire::https::CAInfo et son option spécifique à l'hôte Acquire::https::CAInfo::host. L'option CAInfo spécifie un fichier constitué de certificats CA (au format PEM) concaténés pour créer la chaîne qu'APT doit utiliser pour vérifier le chemin depuis votre certificat racine auto-signé. Si le serveur distant fournit toute la chaîne lors de l'échange, le fichier ne doit contenir que le certificat racine. Sinon, toute la chaîne est nécessaire. Si vous avez besoin de prendre en charge plusieurs autorités, le seul moyen est de tout concaténer.
Une liste de révocation de certificats (CRL) personnalisée peut être configurée avec les options Acquire::https::CRLFile et Acquire::https::CRLFile::host. Comme pour l'option précédente, un fichier au format PEM doit être spécifié.
Lors de l'authentification du serveur, si la vérification du certificat échoue pour une raison quelconque (expiré, révoqué, homme au milieu, etc.), la connexion échoue. C'est évidemment ce que vous voulez dans tous les cas et ce que fournit la valeur par défaut (true) de l'option Acquire::https::Verify-Peer et sa variante spécifique à l'hôte. Si vous savez exactement ce que vous faites, définir cette option sur "false" vous permet d'ignorer la vérification du certificat par les pairs et de faire en sorte que l'échange réussisse. Encore une fois, cette option est uniquement à des fins de débogage ou de test car elle supprime toute la sécurité fournie par l'utilisation de HTTPS.
De même, l'option Acquire::https::Verify-Host et sa variante spécifique à l'hôte peuvent être utilisées pour désactiver une fonctionnalité de sécurité : le certificat fourni par le serveur inclut l'identité du serveur qui doit correspondre au nom DNS utilisé pour y accéder. Par défaut, comme demandé par la RFC 2818, le nom du miroir est vérifié par rapport à l'identité trouvée dans le certificat. Ce comportement par défaut est sûr et ne doit pas être modifié, mais si vous savez que le serveur que vous utilisez a un nom DNS qui ne correspond pas à l'identité de son certificat, vous pouvez définir l'option sur "false", ce qui empêchera la comparaison. d'être exécuté.
Outre la prise en charge de l'authentification par mot de passe (voir apt_auth.conf(5)), HTTPS prend également en charge l'authentification basée sur les certificats clients via Acquire::https::SSLCert et Acquire::https::SSLKey. Ceux-ci doivent être définis respectivement sur le nom de fichier du certificat client X.509 et sur la clé privée associée (non chiffrée), tous deux au format PEM. En pratique, l'utilisation des variantes spécifiques à l'hôte des deux options est fortement recommandée.
Acquire::https { Proxy::example.org "DIRECT"; Proxy "socks5h://apt:pass@127.0.0.1:9050"; Proxy-Auto-Detect "/usr/local/bin/apt-https-proxy-auto-detect"; No-Cache "true"; Max-Age "3600"; No-Store "true"; Timeout "10"; Dl-Limit "42"; Pipeline-Depth "0"; AllowRedirect "false"; User-Agent "My APT-HTTPS"; SendAccept "false"; CAInfo "/path/to/ca/certs.pem"; CRLFile "/path/to/all/crl.pem"; Verify-Peer "true"; Verify-Host::broken.example.org "false"; SSLCert::example.org "/path/to/client/cert.pem"; SSLKey::example.org "/path/to/client/key.pem" };
apt-transport-http(1) apt.conf(5) apt_auth.conf(5) sources.list(5)
Page de bogues APT[1]. Si vous souhaitez signaler un bogue dans APT, veuillez consulter /usr/share/doc/debian/bug-reporting.txt ou la commande reportbug(1).
Équipe APT
1. Page de bogues APT : http://bugs.debian.org/src:apt