apt-transport-https - APT-Transport zum Herunterladen über das HTTP Secure-Protokoll (HTTPS)
Dieser APT-Transport ermöglicht die Nutzung von Repositories, auf die über das HTTP Secure-Protokoll (HTTPS), auch HTTP over TLS genannt, zugegriffen wird. Es ist seit apt 1.5 standardmäßig verfügbar und war davor im Paket apt-transport-https verfügbar. Beachten Sie, dass ein Transport niemals direkt von einem Benutzer aufgerufen wird, sondern von APT-Tools basierend auf der Benutzerkonfiguration verwendet wird.
HTTP ist an sich ein unverschlüsseltes Transportprotokoll (vgl. apt-transport-http(1)), das, wie durch das angehängte S angezeigt, in eine verschlüsselte Schicht eingebettet ist, die als Transport Layer Security (TLS) bekannt ist. um eine Ende-zu-Ende-Verschlüsselung bereitzustellen. Ein ausreichend fähiger Angreifer kann die Kommunikationspartner weiterhin beobachten und eine tiefergehende Analyse der verschlüsselten Kommunikation könnte dennoch wichtige Details offenbaren. Eine Übersicht über verfügbare alternative Transportmethoden finden Sie in sources.list(5).
Das HTTPS-Protokoll basiert auf dem HTTP-Protokoll, sodass alle von apt-transport-http(1) unterstützten Optionen auch über Acquire::https verfügbar sind und standardmäßig dieselben Werte verwenden, die für Acquire: angegeben wurden. http. Diese Manpage dokumentiert nur die Optionen einzigartig für https.
Standardmäßig werden alle vom System vertrauenswürdigen Zertifikate (siehe Paket ca-certificates) für die Überprüfung des Serverzertifikats verwendet. Eine alternative Zertifizierungsstelle (CA) kann mit der Option Acquire::https::CAInfo und ihrer hostspezifischen Option Acquire::https::CAInfo::host konfiguriert werden. Die Option CAInfo gibt eine Datei an, die aus CA-Zertifikaten (im PEM-Format) besteht, die miteinander verkettet sind, um die Kette zu erstellen, die APT verwenden soll, um den Pfad von Ihrem selbstsignierten Stammzertifikat zu überprüfen. Wenn der Remote-Server beim Austausch die gesamte Kette bereitstellt, muss die Datei nur das Root-Zertifikat enthalten. Andernfalls ist die gesamte Kette erforderlich. Wenn Sie mehrere Autoritäten unterstützen müssen, besteht die einzige Möglichkeit darin, alles zu verketten.
Eine benutzerdefinierte Zertifikatssperrliste (CRL) kann mit den Optionen Acquire::https::CRLFile und Acquire::https::CRLFile::host konfiguriert werden. Wie bei der vorherigen Option muss eine Datei im PEM-Format angegeben werden.
Wenn während der Serverauthentifizierung die Zertifikatsüberprüfung aus irgendeinem Grund fehlschlägt (abgelaufen, widerrufen, Man-in-the-Middle usw.), schlägt die Verbindung fehl. Dies ist natürlich in jedem Fall das, was Sie wollen und was der Standardwert (true) der Option Acquire::https::Verify-Peer und seiner hostspezifischen Variante bereitstellt. Wenn Sie genau wissen, was Sie tun, können Sie durch Setzen dieser Option auf „false“ die Überprüfung des Peer-Zertifikats überspringen und den Austausch erfolgreich durchführen. Auch diese Option dient nur Debug- oder Testzwecken, da sie sämtliche durch die Verwendung von HTTPS gebotene Sicherheit aufhebt.
Ebenso kann die Option Acquire::https::Verify-Host und ihre hostspezifische Variante verwendet werden, um eine Sicherheitsfunktion zu deaktivieren: Das vom Server bereitgestellte Zertifikat enthält die Identität des Servers, die mit dem DNS-Namen übereinstimmen sollte, der für den Zugriff verwendet wird. Standardmäßig wird, wie in RFC 2818 gefordert, der Name des Spiegels mit der im Zertifikat gefundenen Identität verglichen. Dieses Standardverhalten ist sicher und sollte nicht geändert werden. Wenn Sie jedoch wissen, dass der von Ihnen verwendete Server einen DNS-Namen hat, der nicht mit der Identität in seinem Zertifikat übereinstimmt, können Sie die Option auf „false“ setzen, wodurch der Vergleich verhindert wird von der Durchführung abgehalten wird.
Neben der Unterstützung der passwortbasierten Authentifizierung (siehe apt_auth.conf(5)) unterstützt HTTPS auch die Authentifizierung basierend auf Client-Zertifikaten über Acquire::https::SSLCert und Acquire::https::SSLKey. Diese sollten jeweils auf den Dateinamen des X.509-Client-Zertifikats und den zugehörigen (unverschlüsselten) privaten Schlüssel eingestellt werden, beide im PEM-Format. In der Praxis ist die Verwendung der hostspezifischen Varianten beider Optionen dringend zu empfehlen.
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)
APT-Fehlerseite[1]. Wenn Sie einen Fehler in APT melden möchten, lesen Sie bitte /usr/share/doc/debian/bug-reporting.txt oder den Befehl reportbug(1).
APT-Team
1. APT-Fehlerseite: http://bugs.debian.org/src:apt