apt-transport-https - Le transport d'APT pour télécharger par
HTTPS (protocole de transfert hypertexte sécurisé)
Ce transport d'APT permet d'utiliser les dépôts auxquels on
accède au moyen de HTTPS (protocole HTTP Secure), aussi appelé
HTTP sur TLS. Il est disponible par défaut depuis apt 1.5 et
était disponible auparavant dans lepaquet apt-transport-https. Veuillez
noter qu'un transport n'est jamais appelé directement par
l'utilisateur, maisutilisé par les outils d'APT s'appuyant sur la
configuration de l'utilisateur.
HTTP est un protocole de transport non chiffré (comparez avec
apt-transport-http(1)), qui, comme l'indique le S ajouté, est
enveloppé dans une couche chiffrée, connue sous le nom de
« Transport Layer Security » (TLS), pour fournir
un chiffrement de bout en bout. Un attaquant suffisamment compétent
peut encore observer les partenaires de la communication et une analyse
approfondie de la communication chiffrée pourrait toujours
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, aussi toutes les
options prises en charge par
apt-transport-http(1) sont aussi
disponibles au moyen de Acquire::https et ont par défaut les
même valeurs que celles spécifiées pour Acquire::http.
Cette page de manuel ne documentera que les options
propres à
https.
Par défaut, tous les certificats de confiance du système (voir le
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 de l'hôte Acquire::https::CAInfo::
hôte. L'option CAInfo spécifie un fichier composé
des certificats de CA (au format PEM) concaténés pour
créer la chaîne qu'APT peut utiliser pour vérifier le
chemin à partir du certificat racine auto-signée. Si le serveur
distant fournit toute la chaîne pendant l'échange, le fichier ne
doit contenir que le certificat racine. Autrement, toute la chaîne est
requise. Si la gestion de plusieurs autorités est nécessaire, le
seul moyen est de tout concaténer.
Une liste de révocation de certificats (CRL) personnalisée peut
être configurée avec l'option Acquire::https::CRLFile et
Acquire::https::CRLFile::
hôte. Comme avec l'option
précédente, il faut spécifier un fichier au format PEM.
Durant l'authentification du serveur, si la vérification du certificat
échoue pour une raison quelconque (expiré,
révoqué, homme du milieu, etc.), la connexion
échoue. C'est certainement ce que vous souhaitez dans tous les cas et
ce que fournit la valeur par défaut
(« true ») de l'option Acquire::https::Verify-Peer
et de ses variantes spécifiques à l'hôte. Si vous savez
exactement ce que vous faites, la configuration de cette option
à « false » vous permet d'ignorer la
vérification du certificat du pair et de faire réussir
l'échange. Une fois de plus, cette option est seulement destinée
au test ou au débogage dans la mesure où elle supprime toute la
sécurité apportée par l'utilisation de HTTPS.
De la même façon, l'option Acquire::https::Verify-Host et sa
variante spécifique à l'hôte peuvent être
utilisées pour désactiver la fonction de sécurité.
Le certificat fourni par le serveur comprend l'identité du serveur qui
devrait correspondre au nom de DNS utilisé pour y accéder. Par
défaut, comme cela est requis 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 devrait pas être modifié, mais si vous savez
que le serveur que vous utilisez à un nom de DNS qui ne correspond pas
à l'identité de son certificat, il est possible de régler
l'option à "false", ce qui empêchera la
réalisation de la comparaison.
Outre la gestion de l'authentification basée sur les mots de passe (voir
apt_auth.conf(5)) HTTPS prend aussi en charge l'authentification
basée sur les certificats du client avec Acquire::https::SSLCert et
Acquire::https::SSLKey. Leurs valeurs doivent être respectivement celle
du nom de fichier du certificat X.509 du client et celle de la clé
privée (non chiffrée) associée, toutes les 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:[email protected]: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 des bogues d'APT[1]. Si vous souhaitez signaler un bogue à
propos d'APT, veuillez lire /usr/share/doc/debian/bug-reporting.txt ou
utiliser la commande
reportbug(1).
Jérôme Marant, Philippe Batailler, Christian Perrier
<
[email protected]> (2000, 2005, 2009, 2010), Équipe de
traduction francophone de Debian <
[email protected]>
Veuillez noter que cette traduction peut contenir des parties non traduites.
Cela est volontaire, pour éviter de perdre du contenu quand la
traduction est légèrement en retard sur le contenu d'origine.
Équipe de développement d'APT
- 1.
- Page des bogues d'APT