APT-TRANSPORT-HTTP(1) APT APT-TRANSPORT-HTTP(1) NAME apt-transport-https - APT-Transportmethode zum Herunterladen mittels HTTP-Sicherheitsprotokoll (HTTPS) BESCHREIBUNG Diese APT-Transportmethode ermoglicht die Verwendung von Depots, auf die mittels des HTTP-Sicherheitsprotokolls (HTTPS), auch unter HTTP uber TLS bekannt, zugegriffen werden kann. Es ist standardmassig seit APT 1.5 verfugbar und war zuvor im Paket apttransport-https verfugbar. 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 unverschlusseltes Transportprotokoll (vergleichen Sie apt-transport-http(1)), das, wie es das angehangte S angibt, in eine verschlusselte Ebene, bekannt als Transport Layer Security (TLS), eingepackt wird, um eine Ende-zu-Ende-Verschlusselung bereitzustellen. Ein Angreifer mit ausreichenden Fahigkeiten kann die Kommunikationspartner immer noch beobachten und eine tiefere Analyse der verschlusselten Kommunikation konnte immer noch wichtige Einzelheiten offenbaren. Einen Uberblick uber 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) unterstutzten Optionen auch mittels Acquire::https verfugbar und haben dieselben Voreinstellungen, wie die, die fur Acquire::http angegeben wurden. Diese Handbuchseite wird nur die Optionen beschreiben, die einzig fur HTTPS gelten. Serveranmeldedaten Standardmassig werden alle Zertifikate, denen das System vertraut (siehe das Paket ca-certificates), fur die Prufung des Serverzertifikats benutzt. Eine alternative Zertifizierungstelle (CA) kann mit der Option Acquire::https::CAInfo und der zugehorigen 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 Prufung des Pfads bis zur Wurzel (dem selbstsignierten Zertifikat) benutzen soll. Falls der ferne Server wahrend des Austauschs die ganze Kette bereitstellt, muss die Datei nur das Wurzelzertifikat enthalten. Andernfalls wird die ganze Kette benotigt. Falls Sie mehrere Zertifizierungstellen unterstutzen mussen, besteht die einzige Moglichkeit darin, alles aneinander zu hangen. 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 Prufung des Zertifikats aus irgendeinem Grund fehlschlagt (abgelaufen, zuruckgezogen, 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, ermoglicht Ihnen das Setzen dieser Variable auf >>false<<, die Prufung des Partnerzertifikats zu uberspringen und den Austausch erfolgreich durchzufuhren. 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 Sicherheitsfunktionalitat verwendet werden: Das vom Server bereitgestellte Zertifikat enthalt die Identitat des Servers, der dem DNS-Namen entsprechen sollte, der zum Zugriff darauf benutzt wird. Standardmassig wird, wie von RFC 2818 verlangt, der Name des Spiegelservers mit der im Zertifikat gefundenen Identitat gepruft. Dieses Standardverhalten ist sicher und sollte nicht geandert werden, falls Sie jedoch wissen, dass der Server, den Sie verwenden, einen DNS-Namen hat, der nicht der Identitat in seinem Zertifikat entspricht, konnen Sie die Option auf >>false<< setzen, wodurch das Vergleichen verhindert wird. Client-Authentifizierung Abseits der unterstutzten passwortbasierten Authentifizierung (siehe apt_auth.conf(5)) unterstutzt 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 zugehorigen (unverschlusselten) privaten Schlussels gesetzt werden, beide im PEM-Format. In der Praxis wird die Verwendung der rechnerspezifischen Varianten der beiden Optionen warmstens empfohlen. BEISPIELE 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 "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 mochten, lesen Sie bitte /usr/share/doc/debian/bug-reporting.txt oder den reportbug(1)-Befehl. Verfassen Sie Fehlerberichte bitte auf Englisch. UBERSETZUNG Die deutsche Ubersetzung wurde 2009 von Chris Leick in Zusammenarbeit mit dem deutschen l10n-Team von Debian angefertigt. Beachten Sie, dass diese Ubersetzung Teile enthalten kann, die nicht ubersetzt wurden. Dies ist so, damit kein Inhalt verloren geht, wenn die Ubersetzung hinter dem Originalinhalt hinterherhangt. AUTOR APT-Team FUssNOTEN 1. APT-Fehlerseite https://bugs.debian.org/src:apt APT 2.9.6 11 Mai 2018 APT-TRANSPORT-HTTP(1)