APT-TRANSPORT-HTTP(1) APT APT-TRANSPORT-HTTP(1)
NOM
apt-transport-https - Le transport d'APT pour télécharger par HTTPS
(protocole de transfert hypertexte sécurisé)
DESCRIPTION
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).
OPTIONS
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.
Accréditations du serveur
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.
Désactiver la sécurité
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.
Authentification du client
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.
EXEMPLES
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"
};
VOIR AUSSI
apt-transport-http(1) apt.conf(5) apt_auth.conf(5) sources.list(5)
BOGUES
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).
TRADUCTEURS
Jérôme Marant, Philippe Batailler, Christian Perrier
<bubulle@debian.org> (2000, 2005, 2009, 2010), Équipe de traduction
francophone de Debian <debian-l10n-french@lists.debian.org>
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.
AUTEUR
Équipe de développement d'APT
NOTES
1. Page des bogues d'APT
http://bugs.debian.org/src:apt
APT 2.6.1 11 mai 2018 APT-TRANSPORT-HTTP(1)
Generated by dwww version 1.15 on Sat Jun 29 01:49:26 CEST 2024.