APT-TRANSPORT-HTTP(1) APT APT-TRANSPORT-HTTP(1) NOM apt-transport-https - Le transport d'APT pour telecharger par HTTPS (protocole de transfert hypertexte securise) DESCRIPTION Ce transport d'APT permet d'utiliser les depots auxquels on accede au moyen de HTTPS (protocole HTTP Secure), aussi appele HTTP sur TLS. Il est disponible par defaut depuis apt 1.5 et etait disponible auparavant dans lepaquet apt-transport-https. Veuillez noter qu'un transport n'est jamais appele directement par l'utilisateur, maisutilise par les outils d'APT s'appuyant sur la configuration de l'utilisateur. HTTP est un protocole de transport non chiffre (comparez avec apt- transport-http(1)), qui, comme l'indique le S ajoute, est enveloppe dans une couche chiffree, connue sous le nom de << Transport Layer Security >> (TLS), pour fournir un chiffrement de bout en bout. Un attaquant suffisamment competent peut encore observer les partenaires de la communication et une analyse approfondie de la communication chiffree pourrait toujours reveler des details importants. Un apercu des methodes de transport alternatives disponibles est donne dans sources.list(5). OPTIONS Le protocole HTTPS est base 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 defaut les meme valeurs que celles specifiees pour Acquire::http. Cette page de manuel ne documentera que les options propres a https. Accreditations du serveur Par defaut, tous les certificats de confiance du systeme (voir le paquet ca-certificates sont utilises pour la verification du certificat du serveur. Une autre autorite de certification (CA) peut etre configuree avec l'option Acquire::https::CAInfo et son option specifique de l'hote Acquire::https::CAInfo::hote. L'option CAInfo specifie un fichier compose des certificats de CA (au format PEM) concatenes pour creer la chaine qu'APT peut utiliser pour verifier le chemin a partir du certificat racine auto-signee. Si le serveur distant fournit toute la chaine pendant l'echange, le fichier ne doit contenir que le certificat racine. Autrement, toute la chaine est requise. Si la gestion de plusieurs autorites est necessaire, le seul moyen est de tout concatener. Une liste de revocation de certificats (CRL) personnalisee peut etre configuree avec l'option Acquire::https::CRLFile et Acquire::https::CRLFile::hote. Comme avec l'option precedente, il faut specifier un fichier au format PEM. Desactiver la securite Durant l'authentification du serveur, si la verification du certificat echoue pour une raison quelconque (expire, revoque, homme du milieu, etc.), la connexion echoue. C'est certainement ce que vous souhaitez dans tous les cas et ce que fournit la valeur par defaut (<< true >>) de l'option Acquire::https::Verify-Peer et de ses variantes specifiques a l'hote. Si vous savez exactement ce que vous faites, la configuration de cette option a << false >> vous permet d'ignorer la verification du certificat du pair et de faire reussir l'echange. Une fois de plus, cette option est seulement destinee au test ou au debogage dans la mesure ou elle supprime toute la securite apportee par l'utilisation de HTTPS. De la meme facon, l'option Acquire::https::Verify-Host et sa variante specifique a l'hote peuvent etre utilisees pour desactiver la fonction de securite. Le certificat fourni par le serveur comprend l'identite du serveur qui devrait correspondre au nom de DNS utilise pour y acceder. Par defaut, comme cela est requis par la RFC 2818, le nom du miroir est verifie par rapport a l'identite trouvee dans le certificat. Ce comportement par defaut est sur et ne devrait pas etre modifie, mais si vous savez que le serveur que vous utilisez a un nom de DNS qui ne correspond pas a l'identite de son certificat, il est possible de regler l'option a "false", ce qui empechera la realisation de la comparaison. Authentification du client Outre la gestion de l'authentification basee sur les mots de passe (voir apt_auth.conf(5)) HTTPS prend aussi en charge l'authentification basee sur les certificats du client avec Acquire::https::SSLCert et Acquire::https::SSLKey. Leurs valeurs doivent etre respectivement celle du nom de fichier du certificat X.509 du client et celle de la cle privee (non chiffree) associee, toutes les deux au format PEM. En pratique, l'utilisation des variantes specifiques a l'hote des deux options est fortement recommandee. 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 a propos d'APT, veuillez lire /usr/share/doc/debian/bug-reporting.txt ou utiliser la commande reportbug(1). TRADUCTEURS Jerome Marant, Philippe Batailler, Christian Perrier (2000, 2005, 2009, 2010), Equipe de traduction francophone de Debian Veuillez noter que cette traduction peut contenir des parties non traduites. Cela est volontaire, pour eviter de perdre du contenu quand la traduction est legerement en retard sur le contenu d'origine. AUTEUR Equipe de developpement d'APT NOTES 1. Page des bogues d'APT https://bugs.debian.org/src:apt APT 2.9.5 11 mai 2018 APT-TRANSPORT-HTTP(1)