apt-transport-https - APT-Transportmethode zum Herunterladen mittels
HTTP-Sicherheitsprotokoll (HTTPS)
Diese APT-Transportmethode ermöglicht die Verwendung von Depots, auf die
mittels des HTTP-Sicherheitsprotokolls (HTTPS), auch unter HTTP über
TLS bekannt, zugegriffen werden kann. Es ist standardmäßig seit
APT 1.5 verfügbar und war zuvor im Paket apttransport-https
verfügbar. Beachten Sie, dass eine Transportmethode niemals direkt
durch einen Benutzer aufgerufen wird, jedoch von APT-Werkzeugen basierend auf
der Konfiguration des Benutzers.
HTTP selbst ist ein unverschlüsseltes Transportprotokoll (vergleichen Sie
apt-transport-http(1)), das, wie es das angehängte S angibt, in
eine verschlüsselte Ebene, bekannt als Transport Layer Security (TLS),
eingepackt wird, um eine Ende-zu-Ende-Verschlüsselung bereitzustellen.
Ein Angreifer mit ausreichenden Fähigkeiten kann die
Kommunikationspartner immer noch beobachten und eine tiefere Analyse der
verschlüsselten Kommunikation könnte immer noch wichtige
Einzelheiten offenbaren. Einen Überblick über alternative
Transportmethoden finden Sie in der
sources.list(5).
Das HTTPS-Protokoll basiert auf dem HTTP-Protokoll, daher sind alle von
apt-transport-http(1) unterstützten Optionen auch mittels
Acquire::https verfügbar und haben dieselben Voreinstellungen, wie die,
die für Acquire::http angegeben wurden. Diese Handbuchseite wird nur
die Optionen beschreiben, die
einzig für HTTPS gelten.
Standardmäßig werden alle Zertifikate, denen das System vertraut
(siehe das Paket ca-certificates), für die Prüfung des
Serverzertifikats benutzt. Eine alternative Zertifizierungstelle (CA) kann mit
der Option Acquire::https::CAInfo und der zugehörigen
rechnerspezifischen Option Acquire::https::CAInfo::
Rechner
konfiguriert werden. Die Option CAInfo gibt eine Datei an, die aus
CA-Zertifikaten (im PEM-Format) besteht, die zur Erstellung der Kette
aneinandergereiht wurde, die APT zur Prüfung des Pfads bis zur Wurzel
(dem selbstsignierten Zertifikat) benutzen soll. Falls der ferne Server
während des Austauschs die ganze Kette bereitstellt, muss die Datei nur
das Wurzelzertifikat enthalten. Andernfalls wird die ganze Kette
benötigt. Falls Sie mehrere Zertifizierungstellen unterstützen
müssen, besteht die einzige Möglichkeit darin, alles aneinander
zu hängen.
Eine benutzerdefinierte Zertifikatwiderrufsliste (CRL) kann mit den Optionen
Acquire::https::CRLFile beziehungsweise Acquire::https::CRLFile::
Rechner konfiguriert werden. Wie bei der vorherigen Option muss eine
Datei im PEM-Format angegeben werden.
Wenn bei der Authentifizierung des Servers die Prüfung des Zertifikats
aus irgendeinem Grund fehlschlägt (abgelaufen, zurückgezogen,
Mann in der Mitte, usw.) scheitert der Verbindungsaufbau. Dies ist offenkundig
das, was Sie auf jeden Fall wollen und der Vorgabewert (»true«)
der Option Acquire::https::Verify-Peer und was ihre rechnerspezifische
Variante bereitstellt. Falls Sie
genau wissen, was Sie tun,
ermöglicht Ihnen das Setzen dieser Variable auf »false«,
die Prüfung des Partnerzertifikats zu überspringen und den
Austausch erfolgreich durchzuführen. Nochmals – diese Option
dient nur der Fehlersuche und zu Testzwecken, da sie alle durch die Verwendung
von HTTPS bereitgestellte Sicherheit entfernt.
Ebenso kann die Option Acquire::https::Verify-Host und ihre rechnerspezifischen
Variante zum Deaktivieren einer Sicherheitsfunktionalität verwendet
werden: Das vom Server bereitgestellte Zertifikat enthält die
Identität des Servers, der dem DNS-Namen entsprechen sollte, der zum
Zugriff darauf benutzt wird. Standardmäßig wird, wie von RFC
2818 verlangt, der Name des Spiegelservers mit der im Zertifikat gefundenen
Identität geprüft. Dieses Standardverhalten ist sicher und
sollte nicht geändert werden, falls Sie jedoch wissen, dass der Server,
den Sie verwenden, einen DNS-Namen hat, der nicht der Identität in
seinem Zertifikat entspricht, können Sie die Option auf
»false« setzen, wodurch das Vergleichen verhindert wird.
Abseits der unterstützten passwortbasierten Authentifizierung (siehe
apt_auth.conf(5)) unterstützt HTTPS auch die Authentifizierung
auf Basis von Client-Zertifikaten mittels Acquire::https::SSLCert und
Acquire::https::SSLKey. Sie sollten jeweils auf den Dateinamen des
X.509-Client-Zertifikats und des zugehörigen (unverschlüsselten)
privaten Schlüssels gesetzt werden, beide im PEM-Format. In der Praxis
wird die Verwendung der rechnerspezifischen Varianten der beiden Optionen
wärmstens empfohlen.
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 "Mein APT-HTTPS";
SendAccept "false";
CAInfo "/Pfad/zu/ca/certs.pem";
CRLFile "/Pfad/zu/all/crl.pem";
Verify-Peer "true";
Verify-Host::broken.example.org "false";
SSLCert::example.org "/Pfad/zu/client/cert.pem";
SSLKey::example.org "/Pfad/zu/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 berichten
möchten, lesen Sie bitte /usr/share/doc/debian/bug-reporting.txt oder
den
reportbug(1)-Befehl. Verfassen Sie Fehlerberichte bitte auf
Englisch.
Die deutsche Übersetzung wurde 2009 von Chris Leick
<
[email protected]> in Zusammenarbeit mit dem deutschen l10n-Team von
Debian <
[email protected]> angefertigt.
Beachten Sie, dass diese Übersetzung Teile enthalten kann, die nicht
übersetzt wurden. Dies ist so, damit kein Inhalt verloren geht, wenn
die Übersetzung hinter dem Originalinhalt hinterherhängt.
APT-Team
- 1.
- APT-Fehlerseite