NAME
apt-transport-https - APT-Transportmethode zum Herunterladen mittels HTTP-Sicherheitsprotokoll (HTTPS)
BESCHREIBUNG
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).
OPTIONEN
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.
Serveranmeldedaten
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.
Sicherheit
deaktivieren
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.
Client-Authentifizierung
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.
BEISPIELE
Acquire::https {
|
Proxy::example.org "DIRECT"; | ||
|
Proxy "socks5h://apt:pass [AT] 127.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 "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" |
};
SIEHE AUCH
apt-transport-http(1) apt.conf(5) apt_auth.conf(5) sources.list(5)
FEHLER
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.
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2009 von Chris Leick <c.leick [AT] vollbio.de> in Zusammenarbeit mit dem deutschen l10n-Team von Debian <debian-l10n-german [AT] lists.org> 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.
AUTOR
APT-Team
FUßNOTEN
|
1. |
APT-Fehlerseite |