`ssl` — TLS/SSL-Wrapper für Socket-Objekte¶

Quellcode: Lib/ssl.py

Dieses Modul bietet Zugriff auf Transport Layer Security (oft bekannt als „Secure Sockets Layer“) Verschlüsselungs- und Peer-Authentifizierungsfunktionen für Netzwerk-Sockets, sowohl auf Client- als auch auf Serverseite. Dieses Modul verwendet die OpenSSL-Bibliothek. Es ist auf allen modernen Unix-Systemen, Windows, macOS und wahrscheinlich zusätzlichen Plattformen verfügbar, solange OpenSSL auf dieser Plattform installiert ist.

Hinweis

Einige Verhaltensweisen können plattformabhängig sein, da Aufrufe an die Socket-APIs des Betriebssystems erfolgen. Die installierte Version von OpenSSL kann ebenfalls zu Variationen im Verhalten führen. Zum Beispiel kommt TLSv1.3 mit OpenSSL Version 1.1.1.

Warnung

Verwenden Sie dieses Modul nicht, ohne die Sicherheitsüberlegungen zu lesen. Andernfalls kann dies zu einem falschen Sicherheitsgefühl führen, da die Standardeinstellungen des ssl-Moduls nicht unbedingt für Ihre Anwendung geeignet sind.

Verfügbarkeit: nicht WASI.

Dieses Modul funktioniert nicht oder ist nicht auf WebAssembly verfügbar. Weitere Informationen finden Sie unter WebAssembly-Plattformen.

Dieser Abschnitt dokumentiert die Objekte und Funktionen im ssl-Modul; für allgemeinere Informationen über TLS, SSL und Zertifikate wird der Leser auf die Dokumente im Abschnitt „Siehe auch“ unten verwiesen.

Dieses Modul bietet eine Klasse, ssl.SSLSocket, die von der socket.socket-Klasse abgeleitet ist und einen Socket-ähnlichen Wrapper bereitstellt, der die Daten, die über den Socket gehen, mit SSL verschlüsselt und entschlüsselt. Er unterstützt zusätzliche Methoden wie getpeercert(), die das Zertifikat der Gegenseite der Verbindung abrufen, cipher(), die den für die sichere Verbindung verwendeten Cipher abruft, oder get_verified_chain(), get_unverified_chain(), die die Zertifikatskette abrufen.

Für anspruchsvollere Anwendungen hilft die Klasse ssl.SSLContext bei der Verwaltung von Einstellungen und Zertifikaten, die dann von SSL-Sockets, die über die Methode SSLContext.wrap_socket() erstellt wurden, geerbt werden können.

Geändert in Version 3.5.3: Aktualisiert zur Unterstützung der Verlinkung mit OpenSSL 1.1.0

Geändert in Version 3.6: OpenSSL 0.9.8, 1.0.0 und 1.0.1 sind veraltet und werden nicht mehr unterstützt. Zukünftig wird das ssl-Modul mindestens OpenSSL 1.0.2 oder 1.1.0 benötigen.

Geändert in Version 3.10: PEP 644 wurde implementiert. Das ssl-Modul benötigt OpenSSL 1.1.1 oder neuer.

Die Verwendung veralteter Konstanten und Funktionen führt zu Warnungen über veraltete Funktionen.

Funktionen, Konstanten und Ausnahmen¶

Socket-Erstellung¶

Instanzen von SSLSocket müssen mit der Methode SSLContext.wrap_socket() erstellt werden. Die Hilfsfunktion create_default_context() gibt einen neuen Kontext mit sicheren Standardeinstellungen zurück.

Beispiel für einen Client-Socket mit Standardkontext und IPv4/IPv6 Dual-Stack

import socket
import ssl

hostname = 'www.python.org'
context = ssl.create_default_context()

with socket.create_connection((hostname, 443)) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print(ssock.version())

Beispiel für einen Client-Socket mit benutzerdefiniertem Kontext und IPv4

hostname = 'www.python.org'
# PROTOCOL_TLS_CLIENT requires valid cert chain and hostname
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.load_verify_locations('path/to/cabundle.pem')

with socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) as sock:
    with context.wrap_socket(sock, server_hostname=hostname) as ssock:
        print(ssock.version())

Beispiel für einen Server-Socket, der auf localhost IPv4 lauscht

context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain('/path/to/certchain.pem', '/path/to/private.key')

with socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) as sock:
    sock.bind(('127.0.0.1', 8443))
    sock.listen(5)
    with context.wrap_socket(sock, server_side=True) as ssock:
        conn, addr = ssock.accept()
        ...

Kontext-Erstellung¶

Eine Komfortfunktion hilft bei der Erstellung von SSLContext-Objekten für gängige Zwecke.

ssl.create_default_context(purpose=Purpose.SERVER_AUTH, *, cafile=None, capath=None, cadata=None)¶

Gibt ein neues SSLContext-Objekt mit Standardeinstellungen für den angegebenen Zweck zurück. Die Einstellungen werden vom ssl-Modul gewählt und stellen normalerweise eine höhere Sicherheit dar, als wenn der SSLContext-Konstruktor direkt aufgerufen wird.

cafile, capath, cadata repräsentieren optionale CA-Zertifikate, denen für die Zertifikatsüberprüfung vertraut werden kann, wie in SSLContext.load_verify_locations(). Wenn alle drei None sind, kann diese Funktion stattdessen den Standard-CA-Zertifikaten des Systems vertrauen.

Die Einstellungen sind: PROTOCOL_TLS_CLIENT oder PROTOCOL_TLS_SERVER, OP_NO_SSLv2 und OP_NO_SSLv3 mit stark verschlüsselten Cipher-Suiten ohne RC4 und ohne nicht authentifizierte Cipher-Suiten. Das Übergeben von SERVER_AUTH als Zweck setzt verify_mode auf CERT_REQUIRED und lädt entweder CA-Zertifikate (wenn mindestens eines von cafile, capath oder cadata angegeben ist) oder verwendet SSLContext.load_default_certs(), um die Standard-CA-Zertifikate zu laden.

Wenn keylog_filename unterstützt wird und die Umgebungsvariable SSLKEYLOGFILE gesetzt ist, aktiviert create_default_context() die Schlüsselprotokollierung.

Die Standardeinstellungen für diesen Kontext umfassen VERIFY_X509_PARTIAL_CHAIN und VERIFY_X509_STRICT. Diese veranlassen die zugrunde liegende OpenSSL-Implementierung, sich mehr wie eine konforme Implementierung von RFC 5280 zu verhalten, auf Kosten einer geringen Inkompatibilität mit älteren X.509-Zertifikaten.

Hinweis

Das Protokoll, die Optionen, der Cipher und andere Einstellungen können jederzeit ohne vorherige Veraltung auf restriktivere Werte geändert werden. Die Werte stellen ein gutes Gleichgewicht zwischen Kompatibilität und Sicherheit dar.

Wenn Ihre Anwendung bestimmte Einstellungen benötigt, sollten Sie einen SSLContext erstellen und die Einstellungen selbst anwenden.

Hinweis

Wenn Sie feststellen, dass bestimmte ältere Clients oder Server bei der Verbindung mit einem von dieser Funktion erstellten SSLContext eine Fehlermeldung wie „Protocol or cipher suite mismatch“ erhalten, kann es daran liegen, dass sie nur SSL3.0 unterstützen, das von dieser Funktion mit OP_NO_SSLv3 ausgeschlossen wird. SSL3.0 gilt allgemein als vollständig defekt. Wenn Sie diese Funktion weiterhin verwenden möchten, aber SSL 3.0-Verbindungen zulassen wollen, können Sie diese mit folgendem Befehl wieder aktivieren:

ctx = ssl.create_default_context(Purpose.CLIENT_AUTH)
ctx.options &= ~ssl.OP_NO_SSLv3

Hinweis

Dieser Kontext aktiviert standardmäßig VERIFY_X509_STRICT, was vor RFC 5280 oder fehlerhafte Zertifikate, die die zugrunde liegende OpenSSL-Implementierung ansonsten akzeptieren würde, ablehnen kann. Obwohl die Deaktivierung nicht empfohlen wird, können Sie dies mit folgendem Befehl tun:

ctx = ssl.create_default_context()
ctx.verify_flags &= ~ssl.VERIFY_X509_STRICT

Hinzugefügt in Version 3.4.

Geändert in Version 3.4.4: RC4 wurde aus dem Standard-Cipher-String entfernt.

Geändert in Version 3.6: ChaCha20/Poly1305 wurde zum Standard-Cipher-String hinzugefügt.

3DES wurde aus dem Standard-Cipher-String entfernt.

Geändert in Version 3.8: Unterstützung für die Schlüsselprotokollierung an SSLKEYLOGFILE wurde hinzugefügt.

Geändert in Version 3.10: Der Kontext verwendet nun PROTOCOL_TLS_CLIENT oder PROTOCOL_TLS_SERVER anstelle des generischen PROTOCOL_TLS.

Geändert in Version 3.13: Der Kontext verwendet nun VERIFY_X509_PARTIAL_CHAIN und VERIFY_X509_STRICT in seinen Standard-Verifizierungs-Flags.

Ausnahmen¶

exception ssl.SSLError¶

Wird ausgelöst, um einen Fehler von der zugrunde liegenden SSL-Implementierung (derzeit bereitgestellt von der OpenSSL-Bibliothek) zu signalisieren. Dies deutet auf ein Problem in der überlagerten höheren Verschlüsselungs- und Authentifizierungsschicht der zugrunde liegenden Netzwerkverbindung hin. Dieser Fehler ist ein Subtyp von OSError. Der Fehlercode und die Meldung von SSLError-Instanzen werden von der OpenSSL-Bibliothek bereitgestellt.

Geändert in Version 3.3: SSLError war früher ein Subtyp von socket.error.

library¶: Eine Zeichenkette, die das OpenSSL-Untermodul bezeichnet, in dem der Fehler aufgetreten ist, z. B. SSL, PEM oder X509. Der Bereich der möglichen Werte hängt von der OpenSSL-Version ab.

Hinzugefügt in Version 3.3.

reason¶: Eine Zeichenkette, die den Grund für diesen Fehler bezeichnet, z. B. CERTIFICATE_VERIFY_FAILED. Der Bereich der möglichen Werte hängt von der OpenSSL-Version ab.

Hinzugefügt in Version 3.3.

exception ssl.SSLZeroReturnError¶: Eine Unterklasse von SSLError, die ausgelöst wird, wenn versucht wird zu lesen oder zu schreiben und die SSL-Verbindung sauber geschlossen wurde. Beachten Sie, dass dies nicht bedeutet, dass die zugrunde liegende Verbindung (read TCP) geschlossen wurde.

Hinzugefügt in Version 3.3.

exception ssl.SSLWantReadError¶: Eine Unterklasse von SSLError, die von einem nicht-blockierenden SSL-Socket ausgelöst wird, wenn versucht wird, Daten zu lesen oder zu schreiben, aber mehr Daten auf der zugrunde liegenden TCP-Verbindung empfangen werden müssen, bevor die Anforderung erfüllt werden kann.

Hinzugefügt in Version 3.3.

exception ssl.SSLWantWriteError¶: Eine Unterklasse von SSLError, die von einem nicht-blockierenden SSL-Socket ausgelöst wird, wenn versucht wird, Daten zu lesen oder zu schreiben, aber mehr Daten auf der zugrunde liegenden TCP-Verbindung gesendet werden müssen, bevor die Anforderung erfüllt werden kann.

Hinzugefügt in Version 3.3.

exception ssl.SSLSyscallError¶: Eine Unterklasse von SSLError, die ausgelöst wird, wenn ein Systemfehler bei der Erfüllung einer Operation an einem SSL-Socket auftritt. Leider gibt es keine einfache Möglichkeit, die ursprüngliche errno-Nummer abzufragen.

Hinzugefügt in Version 3.3.

exception ssl.SSLEOFError¶: Eine Unterklasse von SSLError, die ausgelöst wird, wenn die SSL-Verbindung abrupt beendet wurde. Im Allgemeinen sollten Sie nicht versuchen, die zugrunde liegende Verbindung wiederzuverwenden, wenn dieser Fehler auftritt.

Hinzugefügt in Version 3.3.

exception ssl.SSLCertVerificationError¶

Eine Unterklasse von SSLError, die ausgelöst wird, wenn die Zertifikatsüberprüfung fehlgeschlagen ist.

Hinzugefügt in Version 3.7.

verify_code¶: Eine numerische Fehlerzahl, die den Verifizierungsfehler angibt.

verify_message¶: Eine menschenlesbare Zeichenkette des Verifizierungsfehlers.

exception ssl.CertificateError¶: Ein Alias für SSLCertVerificationError.

Geändert in Version 3.7: Die Ausnahme ist jetzt ein Alias für SSLCertVerificationError.

Zufallsgenerierung¶

ssl.RAND_bytes(num, /)¶

Gibt num kryptographisch sichere Pseudo-Zufallsbytes zurück. Löst eine SSLError aus, wenn der PRNG nicht mit genügend Daten initialisiert wurde oder wenn die Operation vom aktuellen RAND-Verfahren nicht unterstützt wird. RAND_status() kann verwendet werden, um den Status des PRNG zu überprüfen, und RAND_add() kann zum Initialisieren des PRNG verwendet werden.

Für fast alle Anwendungen ist os.urandom() vorzuziehen.

Lesen Sie den Wikipedia-Artikel, Kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG), um die Anforderungen an einen kryptographisch sicheren Generator zu erfahren.

Hinzugefügt in Version 3.3.

ssl.RAND_status()¶: Gibt True zurück, wenn der SSL-Pseudo-Zufallszahlengenerator mit „genügend“ Zufälligkeit initialisiert wurde, und andernfalls False. Sie können ssl.RAND_egd() und ssl.RAND_add() verwenden, um die Zufälligkeit des Pseudo-Zufallszahlengenerators zu erhöhen.

ssl.RAND_add(bytes, entropy, /)¶: Vermischen Sie die gegebenen Bytes mit dem SSL-Pseudo-Zufallszahlengenerator. Der Parameter entropy (ein Float) ist eine Untergrenze für die im String enthaltene Entropie (Sie können also immer 0.0 verwenden). Lesen Sie RFC 1750 für weitere Informationen über Entropiequellen.

Geändert in Version 3.5: Schreibbare Bytes-ähnliche Objekte werden jetzt akzeptiert.

Zertifikatsbehandlung¶

ssl.cert_time_to_seconds(cert_time)¶

Gibt die Zeit in Sekunden seit dem Epoch zurück, gegeben den cert_time-String, der das Datum „notBefore“ oder „notAfter“ aus einem Zertifikat im "%b %d %H:%M:%S %Y %Z" strptime-Format (C-Locale) darstellt.

Hier ist ein Beispiel

>>> import ssl
>>> timestamp = ssl.cert_time_to_seconds("Jan  5 09:34:43 2018 GMT")
>>> timestamp
1515144883
>>> from datetime import datetime
>>> print(datetime.utcfromtimestamp(timestamp))
2018-01-05 09:34:43

„notBefore“- oder „notAfter“-Daten müssen GMT verwenden (RFC 5280).

Geändert in Version 3.5: Interpretiert die Eingabezeit als UTC-Zeit gemäß der Zeitzone „GMT“ im Eingabe-String. Zuvor wurde die lokale Zeitzone verwendet. Gibt eine Ganzzahl zurück (keine Sekundenbruchteile im Eingabeformat).

ssl.get_server_certificate(addr, ssl_version=PROTOCOL_TLS_CLIENT, ca_certs=None[, timeout])¶: Gegeben die Adresse addr eines SSL-geschützten Servers als Paar (Hostname, Portnummer), ruft das Zertifikat des Servers ab und gibt es als PEM-codierten String zurück. Wenn ssl_version angegeben ist, wird diese Version des SSL-Protokolls verwendet, um eine Verbindung zum Server herzustellen. Wenn ca_certs angegeben ist, sollte es sich um eine Datei handeln, die eine Liste von Stammzertifikaten enthält, im selben Format wie der Parameter cafile in SSLContext.load_verify_locations(). Der Aufruf versucht, das Serverzertifikat anhand dieses Satzes von Stammzertifikaten zu validieren, und schlägt fehl, wenn der Validierungsversuch fehlschlägt. Ein Timeout kann mit dem Parameter timeout angegeben werden.

Geändert in Version 3.3: Diese Funktion ist jetzt IPv6-kompatibel.

Geändert in Version 3.5: Die Standard-ssl_version wird von PROTOCOL_SSLv3 zu PROTOCOL_TLS geändert, um maximale Kompatibilität mit modernen Servern zu gewährleisten.

Geändert in Version 3.10: Der Parameter timeout wurde hinzugefügt.

ssl.DER_cert_to_PEM_cert(der_cert_bytes)¶: Gibt ein Zertifikat als DER-codierten Byte-Blob zurück, und zwar eine PEM-codierte String-Version desselben Zertifikats.

ssl.PEM_cert_to_DER_cert(pem_cert_string)¶: Gibt ein Zertifikat als ASCII-PEM-String zurück und zwar eine DER-codierte Byte-Sequenz desselben Zertifikats.

ssl.get_default_verify_paths()¶

Gibt ein benanntes Tupel mit Pfaden zu den Standard-CA-Dateien und -Verzeichnissen von OpenSSL zurück. Die Pfade sind dieselben, die von SSLContext.set_default_verify_paths() verwendet werden. Der Rückgabewert ist ein benanntes Tupel DefaultVerifyPaths

cafile - aufgelöster Pfad zur CA-Datei oder None, wenn die Datei nicht existiert,
capath - aufgelöster Pfad zum CA-Verzeichnis oder None, wenn das Verzeichnis nicht existiert,
openssl_cafile_env - OpenSSLs Umgebungsschlüssel, der auf eine CA-Datei verweist,
openssl_cafile - fest codierter Pfad zu einer CA-Datei,
openssl_capath_env - OpenSSLs Umgebungsschlüssel, der auf ein CA-Verzeichnis verweist,
openssl_capath - fest codierter Pfad zu einem CA-Verzeichnis

Hinzugefügt in Version 3.4.

ssl.enum_certificates(store_name)¶

Ruft Zertifikate aus dem Windows-Systemzertifikatsspeicher ab. store_name kann CA, ROOT oder MY sein. Windows kann auch zusätzliche Zertifikatsspeicher bereitstellen.

Die Funktion gibt eine Liste von Tupeln (cert_bytes, encoding_type, trust) zurück. Der encoding_type gibt die Codierung von cert_bytes an. Es handelt sich entweder um x509_asn für X.509 ASN.1-Daten oder um pkcs_7_asn für PKCS#7 ASN.1-Daten. Trust gibt den Zweck des Zertifikats als Satz von OIDs oder genau True an, wenn das Zertifikat für alle Zwecke vertrauenswürdig ist.

Beispiel

>>> ssl.enum_certificates("CA")
[(b'data...', 'x509_asn', {'1.3.6.1.5.5.7.3.1', '1.3.6.1.5.5.7.3.2'}),
 (b'data...', 'x509_asn', True)]

Verfügbarkeit: Windows.

Hinzugefügt in Version 3.4.

ssl.enum_crls(store_name)¶

Ruft CRLs aus dem Windows-Systemzertifikatsspeicher ab. store_name kann CA, ROOT oder MY sein. Windows kann auch zusätzliche Zertifikatsspeicher bereitstellen.

Die Funktion gibt eine Liste von Tupeln (cert_bytes, encoding_type, trust) zurück. Der encoding_type gibt die Codierung von cert_bytes an. Es handelt sich entweder um x509_asn für X.509 ASN.1-Daten oder um pkcs_7_asn für PKCS#7 ASN.1-Daten.

Verfügbarkeit: Windows.

Hinzugefügt in Version 3.4.

Konstanten¶

Alle Konstanten sind jetzt enum.IntEnum- oder enum.IntFlag-Sammlungen.

Hinzugefügt in Version 3.6.

ssl.CERT_NONE¶

Möglicher Wert für SSLContext.verify_mode. Mit Ausnahme von PROTOCOL_TLS_CLIENT ist dies der Standardmodus. Bei clientseitigen Sockets wird fast jedes Zertifikat akzeptiert. Validierungsfehler, wie z. B. nicht vertrauenswürdige oder abgelaufene Zertifikate, werden ignoriert und brechen den TLS/SSL-Handshake nicht ab.

Im Servermodus wird vom Client kein Zertifikat angefordert, sodass der Client keines für die Client-Zertifikatsauthentifizierung sendet.

Siehe die Diskussion der Sicherheitsüberlegungen unten.

ssl.CERT_OPTIONAL¶

Möglicher Wert für SSLContext.verify_mode. Im Clientmodus hat CERT_OPTIONAL dieselbe Bedeutung wie CERT_REQUIRED. Es wird empfohlen, stattdessen CERT_REQUIRED für clientseitige Sockets zu verwenden.

Im Servermodus wird eine Client-Zertifikatsanforderung an den Client gesendet. Der Client kann die Anforderung entweder ignorieren oder ein Zertifikat senden, um eine TLS-Client-Zertifikatsauthentifizierung durchzuführen. Wenn der Client ein Zertifikat sendet, wird es überprüft. Jeder Verifizierungsfehler bricht sofort den TLS-Handshake ab.

Die Verwendung dieser Einstellung erfordert, dass ein gültiger Satz von CA-Zertifikaten an SSLContext.load_verify_locations() übergeben wird.

ssl.CERT_REQUIRED¶

Möglicher Wert für SSLContext.verify_mode. In diesem Modus sind Zertifikate von der anderen Seite der Socket-Verbindung erforderlich; eine SSLError wird ausgelöst, wenn kein Zertifikat bereitgestellt wird oder die Validierung fehlschlägt. Dieser Modus ist nicht ausreichend, um ein Zertifikat im Client-Modus zu verifizieren, da er Hostnamen nicht abgleicht. check_hostname muss ebenfalls aktiviert sein, um die Authentizität eines Zertifikats zu überprüfen. PROTOCOL_TLS_CLIENT verwendet CERT_REQUIRED und aktiviert check_hostname standardmäßig.

Bei einem Server-Socket bietet dieser Modus eine zwingende TLS-Client-Zertifikatsauthentifizierung. Eine Client-Zertifikatanforderung wird an den Client gesendet und der Client muss ein gültiges und vertrauenswürdiges Zertifikat bereitstellen.

Die Verwendung dieser Einstellung erfordert, dass ein gültiger Satz von CA-Zertifikaten an SSLContext.load_verify_locations() übergeben wird.

class ssl.VerifyMode¶: enum.IntEnum Sammlung von CERT_* Konstanten.

Hinzugefügt in Version 3.6.

ssl.VERIFY_DEFAULT¶: Möglicher Wert für SSLContext.verify_flags. In diesem Modus werden Zertifikatssperrlisten (CRLs) nicht überprüft. Standardmäßig erfordert und verifiziert OpenSSL keine CRLs.

Hinzugefügt in Version 3.4.

ssl.VERIFY_CRL_CHECK_LEAF¶: Möglicher Wert für SSLContext.verify_flags. In diesem Modus wird nur das Peer-Zertifikat überprüft, aber keine der zwischengeschalteten CA-Zertifikate. Der Modus erfordert eine gültige CRL, die vom Aussteller des Peer-Zertifikats (seiner direkten Vorfahren-CA) signiert wurde. Wenn keine ordnungsgemäße CRL mit SSLContext.load_verify_locations geladen wurde, schlägt die Validierung fehl.

Hinzugefügt in Version 3.4.

ssl.VERIFY_CRL_CHECK_CHAIN¶: Möglicher Wert für SSLContext.verify_flags. In diesem Modus werden CRLs aller Zertifikate in der Peer-Zertifikatkette überprüft.

Hinzugefügt in Version 3.4.

ssl.VERIFY_X509_STRICT¶: Möglicher Wert für SSLContext.verify_flags, um Workarounds für fehlerhafte X.509-Zertifikate zu deaktivieren.

Hinzugefügt in Version 3.4.

ssl.VERIFY_ALLOW_PROXY_CERTS¶: Möglicher Wert für SSLContext.verify_flags, um die Überprüfung von Proxy-Zertifikaten zu ermöglichen.

Hinzugefügt in Version 3.10.

ssl.VERIFY_X509_TRUSTED_FIRST¶: Möglicher Wert für SSLContext.verify_flags. Er weist OpenSSL an, vertrauenswürdige Zertifikate bei der Erstellung der Vertrauenskette zur Validierung eines Zertifikats zu bevorzugen. Dieses Flag ist standardmäßig aktiviert.

Hinzugefügt in Version 3.4.4.

ssl.VERIFY_X509_PARTIAL_CHAIN¶: Möglicher Wert für SSLContext.verify_flags. Er weist OpenSSL an, zwischengeschaltete CAs im Trust-Store als Trust-Anker zu behandeln, genauso wie selbstsignierte Root-CA-Zertifikate. Dies ermöglicht es, Zertifikate, die von einer zwischengeschalteten CA ausgestellt wurden, zu vertrauen, ohne der übergeordneten Root-CA vertrauen zu müssen.

Hinzugefügt in Version 3.10.

class ssl.VerifyFlags¶: enum.IntFlag Sammlung von VERIFY_* Konstanten.

Hinzugefügt in Version 3.6.

ssl.PROTOCOL_TLS¶: Wählt die höchste Protokollversion aus, die sowohl vom Client als auch vom Server unterstützt wird. Trotz des Namens kann diese Option sowohl „SSL“- als auch „TLS“-Protokolle auswählen.

Hinzugefügt in Version 3.6.

Veraltet seit Version 3.10: TLS-Clients und -Server benötigen unterschiedliche Standardeinstellungen für sichere Kommunikation. Die generische TLS-Protokollkonstante ist zugunsten von PROTOCOL_TLS_CLIENT und PROTOCOL_TLS_SERVER veraltet.

ssl.PROTOCOL_TLS_CLIENT¶: Automatische Aushandlung der höchsten Protokollversion, die sowohl vom Client als auch vom Server unterstützt wird, und Konfiguration des Kontexts für Client-seitige Verbindungen. Das Protokoll aktiviert standardmäßig CERT_REQUIRED und check_hostname.

Hinzugefügt in Version 3.6.

ssl.PROTOCOL_TLS_SERVER¶: Automatische Aushandlung der höchsten Protokollversion, die sowohl vom Client als auch vom Server unterstützt wird, und Konfiguration des Kontexts für Server-seitige Verbindungen.

Hinzugefügt in Version 3.6.

ssl.PROTOCOL_SSLv23¶: Alias für PROTOCOL_TLS.

Veraltet seit Version 3.6: Verwenden Sie stattdessen PROTOCOL_TLS.

ssl.PROTOCOL_SSLv3¶

Wählt SSL Version 3 als Kanalverschlüsselungsprotokoll.

Dieses Protokoll ist nicht verfügbar, wenn OpenSSL mit der Option no-ssl3 kompiliert wurde.

Warnung

SSL Version 3 ist unsicher. Seine Verwendung wird dringend abgeraten.

Veraltet seit Version 3.6: OpenSSL hat alle versionsspezifischen Protokolle veraltet. Verwenden Sie stattdessen das Standardprotokoll PROTOCOL_TLS_SERVER oder PROTOCOL_TLS_CLIENT mit SSLContext.minimum_version und SSLContext.maximum_version.

ssl.PROTOCOL_TLSv1¶: Wählt TLS Version 1.0 als Kanalverschlüsselungsprotokoll.

Veraltet seit Version 3.6: OpenSSL hat alle versionsspezifischen Protokolle veraltet.

ssl.PROTOCOL_TLSv1_1¶: Wählt TLS Version 1.1 als Kanalverschlüsselungsprotokoll. Verfügbar nur mit openssl Version 1.0.1+.

Hinzugefügt in Version 3.4.

Veraltet seit Version 3.6: OpenSSL hat alle versionsspezifischen Protokolle veraltet.

ssl.PROTOCOL_TLSv1_2¶: Wählt TLS Version 1.2 als Kanalverschlüsselungsprotokoll. Verfügbar nur mit openssl Version 1.0.1+.

Hinzugefügt in Version 3.4.

Veraltet seit Version 3.6: OpenSSL hat alle versionsspezifischen Protokolle veraltet.

ssl.OP_ALL¶: Aktiviert Workarounds für verschiedene Bugs in anderen SSL-Implementierungen. Diese Option ist standardmäßig gesetzt. Sie setzt nicht unbedingt dieselben Flags wie die SSL_OP_ALL Konstante von OpenSSL.

Hinzugefügt in Version 3.2.

ssl.OP_NO_SSLv2¶: Verhindert eine SSLv2-Verbindung. Diese Option ist nur in Verbindung mit PROTOCOL_TLS anwendbar. Sie verhindert, dass die Peers SSLv2 als Protokollversion wählen.

Hinzugefügt in Version 3.2.

Veraltet seit Version 3.6: SSLv2 ist veraltet

ssl.OP_NO_SSLv3¶: Verhindert eine SSLv3-Verbindung. Diese Option ist nur in Verbindung mit PROTOCOL_TLS anwendbar. Sie verhindert, dass die Peers SSLv3 als Protokollversion wählen.

Hinzugefügt in Version 3.2.

Veraltet seit Version 3.6: SSLv3 ist veraltet

ssl.OP_NO_TLSv1¶: Verhindert eine TLSv1-Verbindung. Diese Option ist nur in Verbindung mit PROTOCOL_TLS anwendbar. Sie verhindert, dass die Peers TLSv1 als Protokollversion wählen.

Hinzugefügt in Version 3.2.

Veraltet seit Version 3.7: Die Option ist seit OpenSSL 1.1.0 veraltet, verwenden Sie stattdessen die neuen SSLContext.minimum_version und SSLContext.maximum_version.

ssl.OP_NO_TLSv1_1¶: Verhindert eine TLSv1.1-Verbindung. Diese Option ist nur in Verbindung mit PROTOCOL_TLS anwendbar. Sie verhindert, dass die Peers TLSv1.1 als Protokollversion wählen. Verfügbar nur mit openssl Version 1.0.1+.

Hinzugefügt in Version 3.4.

Veraltet seit Version 3.7: Die Option ist seit OpenSSL 1.1.0 veraltet.

ssl.OP_NO_TLSv1_2¶: Verhindert eine TLSv1.2-Verbindung. Diese Option ist nur in Verbindung mit PROTOCOL_TLS anwendbar. Sie verhindert, dass die Peers TLSv1.2 als Protokollversion wählen. Verfügbar nur mit openssl Version 1.0.1+.

Hinzugefügt in Version 3.4.

Veraltet seit Version 3.7: Die Option ist seit OpenSSL 1.1.0 veraltet.

ssl.OP_NO_TLSv1_3¶: Verhindert eine TLSv1.3-Verbindung. Diese Option ist nur in Verbindung mit PROTOCOL_TLS anwendbar. Sie verhindert, dass die Peers TLSv1.3 als Protokollversion wählen. TLS 1.3 ist mit OpenSSL 1.1.1 oder neuer verfügbar. Wenn Python gegen eine ältere Version von OpenSSL kompiliert wurde, ist das Flag standardmäßig auf 0 gesetzt.

Hinzugefügt in Version 3.6.3.

Veraltet seit Version 3.7: Die Option ist seit OpenSSL 1.1.0 veraltet. Sie wurde zu 2.7.15 und 3.6.3 zur Abwärtskompatibilität mit OpenSSL 1.0.2 hinzugefügt.

ssl.OP_NO_RENEGOTIATION¶

Deaktiviert alle Neuverhandlungen in TLSv1.2 und früheren Versionen. Sendet keine HelloRequest-Nachrichten und ignoriert Neuverhandlungsanfragen über ClientHello.

Diese Option ist nur mit OpenSSL 1.1.0h und neuer verfügbar.

Hinzugefügt in Version 3.7.

ssl.OP_CIPHER_SERVER_PREFERENCE¶: Verwendet die Cipher-Reihenfolge des Servers anstelle der des Clients. Diese Option hat keine Auswirkung auf Client-Sockets und SSLv2-Server-Sockets.

Hinzugefügt in Version 3.3.

ssl.OP_SINGLE_DH_USE¶: Verhindert die Wiederverwendung desselben DH-Schlüssels für verschiedene SSL-Sitzungen. Dies verbessert die Forward Secrecy, erfordert jedoch mehr Rechenressourcen. Diese Option gilt nur für Server-Sockets.

Hinzugefügt in Version 3.3.

ssl.OP_SINGLE_ECDH_USE¶: Verhindert die Wiederverwendung desselben ECDH-Schlüssels für verschiedene SSL-Sitzungen. Dies verbessert die Forward Secrecy, erfordert jedoch mehr Rechenressourcen. Diese Option gilt nur für Server-Sockets.

Hinzugefügt in Version 3.3.

ssl.OP_ENABLE_MIDDLEBOX_COMPAT¶

Sendet Dummy Change Cipher Spec (CCS) Nachrichten im TLS 1.3 Handshake, damit eine TLS 1.3-Verbindung eher wie eine TLS 1.2-Verbindung aussieht.

Diese Option ist nur mit OpenSSL 1.1.1 und neuer verfügbar.

Hinzugefügt in Version 3.8.

ssl.OP_NO_COMPRESSION¶: Deaktiviert die Kompression auf dem SSL-Kanal. Dies ist nützlich, wenn das Anwendungsprotokoll sein eigenes Komprimierungsschema unterstützt.

Hinzugefügt in Version 3.3.

class ssl.Options¶: enum.IntFlag Sammlung von OP_* Konstanten.

ssl.OP_NO_TICKET¶: Verhindert, dass der Client eine Sitzungs-Ticket-Anfrage stellt.

Hinzugefügt in Version 3.6.

ssl.OP_IGNORE_UNEXPECTED_EOF¶

Ignoriert unerwartete Beendigung von TLS-Verbindungen.

Diese Option ist nur mit OpenSSL 3.0.0 und neuer verfügbar.

Hinzugefügt in Version 3.10.

ssl.OP_ENABLE_KTLS¶

Aktiviert die Verwendung von Kernel TLS. Um von der Funktion zu profitieren, muss OpenSSL mit Unterstützung dafür kompiliert worden sein und die ausgehandelten Cipher-Suiten und Erweiterungen müssen von ihm unterstützt werden (eine Liste der unterstützten kann je nach Plattform und Kernelversion variieren).

Beachten Sie, dass mit aktiviertem Kernel TLS einige kryptografische Operationen direkt vom Kernel und nicht über verfügbare OpenSSL-Provider ausgeführt werden. Dies kann unerwünscht sein, wenn die Anwendung beispielsweise alle kryptografischen Operationen vom FIPS-Provider ausführen lassen möchte.

Diese Option ist nur mit OpenSSL 3.0.0 und neuer verfügbar.

Hinzugefügt in Version 3.12.

ssl.OP_LEGACY_SERVER_CONNECT¶: Erlaubt Legacy-unsichere Neuverhandlungen nur zwischen OpenSSL und ungepatchten Servern.

Hinzugefügt in Version 3.12.

ssl.HAS_ALPN¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für die Application-Layer Protocol Negotiation TLS-Erweiterung gemäß RFC 7301 hat.

Hinzugefügt in Version 3.5.

ssl.HAS_NEVER_CHECK_COMMON_NAME¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für die Nichtprüfung des Subject Common Name hat und SSLContext.hostname_checks_common_name schreibbar ist.

Hinzugefügt in Version 3.7.

ssl.HAS_ECDH¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für den Elliptic Curve-basierten Diffie-Hellman Schlüsselaustausch hat. Dies sollte wahr sein, es sei denn, die Funktion wurde vom Distributor explizit deaktiviert.

Hinzugefügt in Version 3.3.

ssl.HAS_SNI¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für die Server Name Indication Erweiterung hat (wie in RFC 6066 definiert).

Hinzugefügt in Version 3.2.

ssl.HAS_NPN¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für Next Protocol Negotiation hat, wie in der Application Layer Protocol Negotiation beschrieben. Wenn wahr, können Sie die Methode SSLContext.set_npn_protocols() verwenden, um zu werben, welche Protokolle Sie unterstützen möchten.

Hinzugefügt in Version 3.3.

ssl.HAS_SSLv2¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für das SSL 2.0-Protokoll hat.

Hinzugefügt in Version 3.7.

ssl.HAS_SSLv3¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für das SSL 3.0-Protokoll hat.

Hinzugefügt in Version 3.7.

ssl.HAS_TLSv1¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für das TLS 1.0-Protokoll hat.

Hinzugefügt in Version 3.7.

ssl.HAS_TLSv1_1¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für das TLS 1.1-Protokoll hat.

Hinzugefügt in Version 3.7.

ssl.HAS_TLSv1_2¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für das TLS 1.2-Protokoll hat.

Hinzugefügt in Version 3.7.

ssl.HAS_TLSv1_3¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für das TLS 1.3-Protokoll hat.

Hinzugefügt in Version 3.7.

ssl.HAS_PSK¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für TLS-PSK hat.

Hinzugefügt in Version 3.13.

ssl.HAS_PHA¶: Ob die OpenSSL-Bibliothek integrierte Unterstützung für TLS-PHA hat.

Hinzugefügt in Version 3.14.

ssl.CHANNEL_BINDING_TYPES¶: Liste der unterstützten TLS-Kanalbindungsarten. Zeichenketten in dieser Liste können als Argumente für SSLSocket.get_channel_binding() verwendet werden.

Hinzugefügt in Version 3.3.

ssl.OPENSSL_VERSION¶

Der Versionsstring der von dem Interpreter geladenen OpenSSL-Bibliothek

>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2k  26 Jan 2017'

Hinzugefügt in Version 3.2.

ssl.OPENSSL_VERSION_INFO¶

Ein Tupel aus fünf ganzen Zahlen, das Versionsinformationen über die OpenSSL-Bibliothek darstellt

>>> ssl.OPENSSL_VERSION_INFO
(1, 0, 2, 11, 15)

Hinzugefügt in Version 3.2.

ssl.OPENSSL_VERSION_NUMBER¶

Die rohe Versionsnummer der OpenSSL-Bibliothek als einzelne ganze Zahl

>>> ssl.OPENSSL_VERSION_NUMBER
268443839
>>> hex(ssl.OPENSSL_VERSION_NUMBER)
'0x100020bf'

Hinzugefügt in Version 3.2.

ssl.ALERT_DESCRIPTION_HANDSHAKE_FAILURE¶

ssl.ALERT_DESCRIPTION_INTERNAL_ERROR¶

ALERT_DESCRIPTION_*

Alarmbeschreibungen aus RFC 5246 und anderen. Die IANA TLS Alert Registry enthält diese Liste und Verweise auf die RFCs, in denen ihre Bedeutung definiert ist.

Wird als Rückgabewert der Callback-Funktion in SSLContext.set_servername_callback() verwendet.

Hinzugefügt in Version 3.4.

class ssl.AlertDescription¶: enum.IntEnum Sammlung von ALERT_DESCRIPTION_* Konstanten.

Hinzugefügt in Version 3.6.

Purpose.SERVER_AUTH¶: Option für create_default_context() und SSLContext.load_default_certs(). Dieser Wert zeigt an, dass der Kontext zur Authentifizierung von Webservern verwendet werden kann (daher wird er zum Erstellen von Client-seitigen Sockets verwendet).

Hinzugefügt in Version 3.4.

Purpose.CLIENT_AUTH¶: Option für create_default_context() und SSLContext.load_default_certs(). Dieser Wert zeigt an, dass der Kontext zur Authentifizierung von Web-Clients verwendet werden kann (daher wird er zum Erstellen von Server-seitigen Sockets verwendet).

Hinzugefügt in Version 3.4.

class ssl.SSLErrorNumber¶: enum.IntEnum Sammlung von SSL_ERROR_* Konstanten.

Hinzugefügt in Version 3.6.

class ssl.TLSVersion¶: enum.IntEnum Sammlung von SSL- und TLS-Versionen für SSLContext.maximum_version und SSLContext.minimum_version.

Hinzugefügt in Version 3.7.

TLSVersion.MINIMUM_SUPPORTED¶

TLSVersion.MAXIMUM_SUPPORTED¶: Die mindestens bzw. maximal unterstützte SSL- oder TLS-Version. Dies sind magische Konstanten. Ihre Werte spiegeln nicht die niedrigsten und höchsten verfügbaren TLS/SSL-Versionen wider.

TLSVersion.SSLv3¶

TLSVersion.TLSv1¶

TLSVersion.TLSv1_1¶

TLSVersion.TLSv1_2¶

TLSVersion.TLSv1_3¶: SSL 3.0 bis TLS 1.3.

Veraltet seit Version 3.10: Alle TLSVersion Mitglieder mit Ausnahme von TLSVersion.TLSv1_2 und TLSVersion.TLSv1_3 sind veraltet.

SSL Sockets¶

class ssl.SSLSocket(socket.socket)¶

SSL-Sockets bieten die folgenden Methoden von Socket Objects

accept()
bind()
close()
connect()
detach()
fileno()
getpeername(), getsockname()
getsockopt(), setsockopt()
gettimeout(), settimeout(), setblocking()
listen()
makefile()
recv(), recv_into() (aber die Übergabe eines Nicht-Null-flags-Arguments ist nicht erlaubt)
send(), sendall() (mit derselben Einschränkung)
sendfile() (aber os.sendfile wird nur für Plain-Text-Sockets verwendet, andernfalls wird send() verwendet)
shutdown()

Da jedoch das SSL- (und TLS-)Protokoll sein eigenes Framing über TCP hat, kann die SSL-Socket-Abstraktion in gewisser Hinsicht von der Spezifikation normaler, OS-Level-Sockets abweichen. Siehe insbesondere die Hinweise zu nicht-blockierenden Sockets.

Instanzen von SSLSocket müssen mit der Methode SSLContext.wrap_socket() erstellt werden.

Geändert in Version 3.5: Die Methode sendfile() wurde hinzugefügt.

Geändert in Version 3.5: shutdown() setzt das Socket-Timeout nicht jedes Mal zurück, wenn Bytes empfangen oder gesendet werden. Das Socket-Timeout ist nun die maximale Gesamtdauer des Shutdowns.

Veraltet seit Version 3.6: Es ist veraltet, eine SSLSocket-Instanz direkt zu erstellen. Verwenden Sie SSLContext.wrap_socket(), um einen Socket zu wrappen.

Geändert in Version 3.7: SSLSocket-Instanzen müssen mit wrap_socket() erstellt werden. In früheren Versionen war es möglich, Instanzen direkt zu erstellen. Dies wurde nie dokumentiert oder offiziell unterstützt.

Geändert in Version 3.10: Python verwendet nun intern SSL_read_ex und SSL_write_ex. Die Funktionen unterstützen das Lesen und Schreiben von Daten größer als 2 GB. Das Schreiben von Null-Länge-Daten führt nicht mehr zu einem Protokollverletzungsfehler.

SSL-Sockets haben auch die folgenden zusätzlichen Methoden und Attribute

SSLSocket.read(len=1024, buffer=None)¶

Liest bis zu len Bytes aus dem SSL-Socket und gibt das Ergebnis als bytes-Instanz zurück. Wenn buffer angegeben ist, wird stattdessen in den Puffer gelesen, und die Anzahl der gelesenen Bytes wird zurückgegeben.

Löst SSLWantReadError oder SSLWantWriteError aus, wenn der Socket nicht-blockierend ist und das Lesen blockieren würde.

Da jederzeit eine Neuverhandlung möglich ist, kann ein Aufruf von read() auch Schreibvorgänge auslösen.

Geändert in Version 3.5: Das Socket-Timeout wird nicht mehr jedes Mal zurückgesetzt, wenn Bytes empfangen oder gesendet werden. Das Socket-Timeout ist nun die maximale Gesamtdauer zum Lesen von bis zu len Bytes.

Veraltet seit Version 3.6: Verwenden Sie recv() anstelle von read().

SSLSocket.write(data)¶

Schreibt data in den SSL-Socket und gibt die Anzahl der geschriebenen Bytes zurück. Das data-Argument muss ein Objekt sein, das die Buffer-Schnittstelle unterstützt.

Löst SSLWantReadError oder SSLWantWriteError aus, wenn der Socket nicht-blockierend ist und das Schreiben blockieren würde.

Da jederzeit eine Neuverhandlung möglich ist, kann ein Aufruf von write() auch Lesevorgänge auslösen.

Geändert in Version 3.5: Das Socket-Timeout wird nicht mehr jedes Mal zurückgesetzt, wenn Bytes empfangen oder gesendet werden. Das Socket-Timeout ist nun die maximale Gesamtdauer zum Schreiben von data.

Veraltet seit Version 3.6: Verwenden Sie send() anstelle von write().

Hinweis

Die Methoden read() und write() sind die Low-Level-Methoden, die unverschlüsselte Anwendungsdaten lesen und schreiben und diese zu verschlüsselten Daten auf Draht-Ebene entschlüsseln/verschlüsseln. Diese Methoden erfordern eine aktive SSL-Verbindung, d.h. der Handshake wurde abgeschlossen und SSLSocket.unwrap() wurde nicht aufgerufen.

Normalerweise sollten Sie stattdessen die Socket-API-Methoden wie recv() und send() verwenden.

SSLSocket.do_handshake(block=False)¶

Führt den SSL-Setup-Handshake durch.

Wenn block true ist und das durch gettimeout() erhaltene Timeout Null ist, wird der Socket im blockierenden Modus gesetzt, bis der Handshake durchgeführt ist.

Geändert in Version 3.4: Die Handshake-Methode führt auch match_hostname() aus, wenn das Attribut check_hostname des context des Sockets true ist.

Geändert in Version 3.5: Das Socket-Timeout wird nicht mehr jedes Mal zurückgesetzt, wenn Bytes empfangen oder gesendet werden. Das Socket-Timeout ist nun die maximale Gesamtdauer des Handshakes.

Geändert in Version 3.7: Hostname oder IP-Adresse werden während des Handshakes von OpenSSL abgeglichen. Die Funktion match_hostname() wird nicht mehr verwendet. Wenn OpenSSL einen Hostnamen oder eine IP-Adresse ablehnt, wird der Handshake frühzeitig abgebrochen und eine TLS-Alert-Nachricht an den Peer gesendet.

SSLSocket.getpeercert(binary_form=False)¶

Wenn kein Zertifikat für den Peer am anderen Ende der Verbindung vorhanden ist, wird None zurückgegeben. Wenn der SSL-Handshake noch nicht erfolgt ist, wird ValueError ausgelöst.

Wenn der Parameter binary_form auf False gesetzt ist und ein Zertifikat vom Peer empfangen wurde, gibt diese Methode eine dict-Instanz zurück. Wenn das Zertifikat nicht validiert wurde, ist das Dictionary leer. Wenn das Zertifikat validiert wurde, gibt es ein Dictionary mit mehreren Schlüsseln zurück, darunter subject (der Principal, für den das Zertifikat ausgestellt wurde) und issuer (der Principal, der das Zertifikat ausgestellt hat). Wenn ein Zertifikat eine Instanz der Erweiterung *Subject Alternative Name* enthält (siehe RFC 3280), gibt es auch einen Schlüssel subjectAltName im Dictionary.

Die Felder subject und issuer sind Tupel, die die Sequenz von relativen Distinguished Names (RDNs) enthalten, die in der Datenstruktur des Zertifikats für die jeweiligen Felder angegeben sind, und jeder RDN ist eine Sequenz von Namens-Wert-Paaren. Hier ist ein reales Beispiel

{'issuer': ((('countryName', 'IL'),),
            (('organizationName', 'StartCom Ltd.'),),
            (('organizationalUnitName',
              'Secure Digital Certificate Signing'),),
            (('commonName',
              'StartCom Class 2 Primary Intermediate Server CA'),)),
 'notAfter': 'Nov 22 08:15:19 2013 GMT',
 'notBefore': 'Nov 21 03:09:52 2011 GMT',
 'serialNumber': '95F0',
 'subject': ((('description', '571208-SLe257oHY9fVQ07Z'),),
             (('countryName', 'US'),),
             (('stateOrProvinceName', 'California'),),
             (('localityName', 'San Francisco'),),
             (('organizationName', 'Electronic Frontier Foundation, Inc.'),),
             (('commonName', '*.eff.org'),),
             (('emailAddress', 'hostmaster@eff.org'),)),
 'subjectAltName': (('DNS', '*.eff.org'), ('DNS', 'eff.org')),
 'version': 3}

Wenn der Parameter binary_form auf True gesetzt ist und ein Zertifikat bereitgestellt wurde, gibt diese Methode die DER-kodierte Form des gesamten Zertifikats als Bytesequenz zurück oder None, wenn der Peer kein Zertifikat bereitgestellt hat. Ob der Peer ein Zertifikat bereitstellt, hängt von der Rolle des SSL-Sockets ab

für einen Client-SSL-Socket stellt der Server immer ein Zertifikat bereit, unabhängig davon, ob eine Validierung erforderlich war;
für einen Server-SSL-Socket stellt der Client nur dann ein Zertifikat bereit, wenn er vom Server dazu aufgefordert wird; daher gibt getpeercert() None zurück, wenn Sie CERT_NONE (anstelle von CERT_OPTIONAL oder CERT_REQUIRED) verwendet haben.

Siehe auch SSLContext.check_hostname.

Geändert in Version 3.2: Das zurückgegebene Dictionary enthält zusätzliche Elemente wie issuer und notBefore.

Geändert in Version 3.4: ValueError wird ausgelöst, wenn der Handshake noch nicht erfolgt ist. Das zurückgegebene Dictionary enthält zusätzliche X509v3-Erweiterungselemente wie crlDistributionPoints, caIssuers und OCSP URIs.

Geändert in Version 3.9: IPv6-Adressstrings haben kein nachgestelltes Zeilenumbruchszeichen mehr.

SSLSocket.get_verified_chain()¶: Gibt die verifizierte Zertifikatkette des anderen Endes des SSL-Kanals als Liste von DER-kodierten Bytes zurück. Wenn die Zertifikatsprüfung deaktiviert war, verhält sich die Methode gleich wie get_unverified_chain().

Hinzugefügt in Version 3.13.

SSLSocket.get_unverified_chain()¶: Gibt die rohe Zertifikatkette des anderen Endes des SSL-Kanals als Liste von DER-kodierten Bytes zurück.

Hinzugefügt in Version 3.13.

SSLSocket.cipher()¶: Gibt ein dreiwertiges Tupel zurück, das den Namen der verwendeten Chiffre, die Version des SSL-Protokolls, das deren Verwendung definiert, und die Anzahl der verwendeten geheimen Bits enthält. Wenn keine Verbindung hergestellt wurde, wird None zurückgegeben.

SSLSocket.shared_ciphers()¶: Gibt die Liste der Chiffren zurück, die sowohl auf Client- als auch auf Serverseite verfügbar sind. Jeder Eintrag der zurückgegebenen Liste ist ein dreiwertiges Tupel, das den Namen der Chiffre, die Version des SSL-Protokolls, das deren Verwendung definiert, und die Anzahl der geheimen Bits enthält, die die Chiffre verwendet. shared_ciphers() gibt None zurück, wenn keine Verbindung hergestellt wurde oder der Socket ein Client-Socket ist.

Hinzugefügt in Version 3.5.

SSLSocket.compression()¶

Gibt den verwendeten Kompressionsalgorithmus als Zeichenkette zurück oder None, wenn die Verbindung nicht komprimiert ist.

Wenn das übergeordnete Protokoll einen eigenen Kompressionsmechanismus unterstützt, können Sie OP_NO_COMPRESSION verwenden, um die SSL-Komprimierung zu deaktivieren.

Hinzugefügt in Version 3.3.

SSLSocket.get_channel_binding(cb_type='tls-unique')¶

Ruft Channel-Binding-Daten für die aktuelle Verbindung als Bytes-Objekt ab. Gibt None zurück, wenn keine Verbindung besteht oder der Handshake noch nicht abgeschlossen wurde.

Der Parameter cb_type ermöglicht die Auswahl des gewünschten Channel-Binding-Typs. Gültige Channel-Binding-Typen sind in der Liste CHANNEL_BINDING_TYPES aufgeführt. Derzeit wird nur das 'tls-unique'-Channel-Binding, definiert in RFC 5929, unterstützt. ValueError wird ausgelöst, wenn ein nicht unterstützter Channel-Binding-Typ angefordert wird.

Hinzugefügt in Version 3.3.

SSLSocket.selected_alpn_protocol()¶: Gibt das Protokoll zurück, das während des TLS-Handshakes ausgewählt wurde. Wenn SSLContext.set_alpn_protocols() nicht aufgerufen wurde, die andere Partei ALPN nicht unterstützt, dieser Socket keine der vorgeschlagenen Protokolle des Clients unterstützt oder der Handshake noch nicht stattgefunden hat, wird None zurückgegeben.

Hinzugefügt in Version 3.5.

SSLSocket.selected_npn_protocol()¶: Gibt das übergeordnete Protokoll zurück, das während des TLS/SSL-Handshakes ausgewählt wurde. Wenn SSLContext.set_npn_protocols() nicht aufgerufen wurde, die andere Partei NPN nicht unterstützt oder der Handshake noch nicht stattgefunden hat, wird dies None zurückgeben.

Hinzugefügt in Version 3.3.

Veraltet seit Version 3.10: NPN wurde durch ALPN abgelöst

SSLSocket.unwrap()¶: Führt den SSL-Shutdown-Handshake durch, der die TLS-Schicht vom zugrunde liegenden Socket entfernt, und gibt das zugrunde liegende Socket-Objekt zurück. Dies kann verwendet werden, um von verschlüsseltem Betrieb über eine Verbindung zu unverschlüsseltem Betrieb zu wechseln. Der zurückgegebene Socket sollte für weitere Kommunikation mit der anderen Seite der Verbindung verwendet werden, anstatt des ursprünglichen Sockets.

SSLSocket.verify_client_post_handshake()¶

Fordert von einem TLS 1.3-Client eine Post-Handshake-Authentifizierung (PHA) an. PHA kann nur für eine TLS 1.3-Verbindung von einem serverseitigen Socket initiiert werden, nach dem initialen TLS-Handshake und wenn PHA auf beiden Seiten aktiviert ist, siehe SSLContext.post_handshake_auth.

Die Methode führt nicht sofort einen Zertifikataustausch durch. Die Serverseite sendet eine CertificateRequest während des nächsten Schreibereignisses und erwartet, dass der Client auf das nächste Leseereignis mit einem Zertifikat antwortet.

Wenn eine Vorbedingung nicht erfüllt ist (z.B. kein TLS 1.3, PHA nicht aktiviert), wird eine SSLError ausgelöst.

Hinweis

Nur verfügbar mit OpenSSL 1.1.1 und TLS 1.3 aktiviert. Ohne TLS 1.3-Unterstützung löst die Methode NotImplementedError aus.

Hinzugefügt in Version 3.8.

SSLSocket.version()¶: Gibt die tatsächliche SSL-Protokollversion, die von der Verbindung ausgehandelt wurde, als Zeichenkette zurück, oder None, wenn keine sichere Verbindung hergestellt wurde. Derzeit mögliche Rückgabewerte sind "SSLv2", "SSLv3", "TLSv1", "TLSv1.1" und "TLSv1.2". Neuere OpenSSL-Versionen können weitere Rückgabewerte definieren.

Hinzugefügt in Version 3.5.

SSLSocket.pending()¶: Gibt die Anzahl der bereits entschlüsselten Bytes zurück, die zum Lesen verfügbar sind und auf der Verbindung ausstehen.

SSLSocket.context¶: Das SSLContext-Objekt, an das dieser SSL-Socket gebunden ist.

Hinzugefügt in Version 3.2.

SSLSocket.server_side¶: Ein boolescher Wert, der für serverseitige Sockets True und für clientseitige Sockets False ist.

Hinzugefügt in Version 3.2.

SSLSocket.server_hostname¶: Hostname des Servers: str-Typ oder None für serverseitige Sockets oder wenn der Hostname nicht im Konstruktor angegeben wurde.

Hinzugefügt in Version 3.2.

Geändert in Version 3.7: Das Attribut ist jetzt immer ASCII-Text. Wenn server_hostname ein internationalisierter Domain-Name (IDN) ist, speichert dieses Attribut nun die A-Label-Form ("xn--pythn-mua.org") anstelle der U-Label-Form ("pythön.org").

SSLSocket.session¶: Die SSLSession für diese SSL-Verbindung. Die Sitzung ist für Client- und Serversockets verfügbar, nachdem der TLS-Handshake durchgeführt wurde. Für Client-Sockets kann die Sitzung vor dem Aufruf von do_handshake() gesetzt werden, um eine Sitzung wiederzuverwenden.

Hinzugefügt in Version 3.6.

SSLSocket.session_reused¶: Hinzugefügt in Version 3.6.

SSL-Kontexte¶

Hinzugefügt in Version 3.2.

Ein SSL-Kontext speichert verschiedene Daten, die länger als einzelne SSL-Verbindungen bestehen, wie z.B. SSL-Konfigurationsoptionen, Zertifikate und private Schlüssel. Er verwaltet auch einen Cache von SSL-Sitzungen für serverseitige Sockets, um wiederholte Verbindungen von denselben Clients zu beschleunigen.

class ssl.SSLContext(protocol=None)¶

Erzeugt einen neuen SSL-Kontext. Sie können protocol übergeben, das eine der Konstanten PROTOCOL_* sein muss, die in diesem Modul definiert sind. Der Parameter gibt an, welche Version des SSL-Protokolls verwendet werden soll. Typischerweise wählt der Server eine bestimmte Protokollversion aus, und der Client muss sich an die Wahl des Servers anpassen. Die meisten Versionen sind nicht mit anderen Versionen interoperabel. Wenn nicht angegeben, ist der Standard PROTOCOL_TLS; dies bietet die höchste Kompatibilität mit anderen Versionen.

Hier ist eine Tabelle, die zeigt, welche Versionen eines Clients (an der Seite) mit welchen Versionen eines Servers (oben) verbunden werden können

Client / Server	SSLv2	SSLv3	TLS [3]	TLSv1	TLSv1.1	TLSv1.2
SSLv2	ja	nein	nein [1]	nein	nein	nein
SSLv3	nein	ja	nein [2]	nein	nein	nein
TLS (SSLv23) [3]	nein [1]	nein [2]	ja	ja	ja	ja
TLSv1	nein	nein	ja	ja	nein	nein
TLSv1.1	nein	nein	ja	nein	ja	nein
TLSv1.2	nein	nein	ja	nein	nein	ja

Fußnoten

Siehe auch

create_default_context() lässt das Modul ssl Sicherheitseinstellungen für einen bestimmten Zweck auswählen.

Geändert in Version 3.6: Der Kontext wird mit sicheren Standardwerten erstellt. Die Optionen OP_NO_COMPRESSION, OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE, OP_NO_SSLv2 und OP_NO_SSLv3 (außer für PROTOCOL_SSLv3) werden standardmäßig gesetzt. Die anfängliche Chiffrensuite-Liste enthält nur HIGH-Chiffren, keine NULL-Chiffren und keine MD5-Chiffren.

Veraltet seit Version 3.10: SSLContext ohne Protokollargument ist veraltet. Die Kontextklasse wird in Zukunft entweder PROTOCOL_TLS_CLIENT oder PROTOCOL_TLS_SERVER erfordern.

Geändert in Version 3.10: Die Standard-Chiffrensuiten enthalten nun nur sichere AES- und ChaCha20-Chiffren mit Forward Secrecy und Sicherheitsstufe 2. RSA- und DH-Schlüssel mit weniger als 2048 Bits und ECC-Schlüssel mit weniger als 224 Bits sind verboten. PROTOCOL_TLS, PROTOCOL_TLS_CLIENT und PROTOCOL_TLS_SERVER verwenden TLS 1.2 als minimale TLS-Version.

Hinweis

SSLContext unterstützt nur begrenzte Mutationen, sobald er von einer Verbindung verwendet wurde. Das Hinzufügen neuer Zertifikate zum internen Vertrauensspeicher ist erlaubt, aber das Ändern von Chiffren, Veriesiąinstellungen oder mTLS-Zertifikaten kann zu überraschendem Verhalten führen.

Hinweis

SSLContext ist dafür konzipiert, geteilt und von mehreren Verbindungen verwendet zu werden. Daher ist er threadsicher, solange er nicht neu konfiguriert wird, nachdem er von einer Verbindung verwendet wurde.

SSLContext-Objekte haben die folgenden Methoden und Attribute

SSLContext.cert_store_stats()¶

Gibt Statistiken über die Mengen der geladenen X.509-Zertifikate, die Anzahl der als CA-Zertifikate gekennzeichneten X.509-Zertifikate und Zertifikatssperrlisten als Dictionary zurück.

Beispiel für einen Kontext mit einem CA-Zertifikat und einem weiteren Zertifikat

>>> context.cert_store_stats()
{'crl': 0, 'x509_ca': 1, 'x509': 2}

Hinzugefügt in Version 3.4.

SSLContext.load_cert_chain(certfile, keyfile=None, password=None)¶

Laden Sie einen privaten Schlüssel und das zugehörige Zertifikat. Die Zeichenkette certfile muss der Pfad zu einer einzelnen Datei im PEM-Format sein, die das Zertifikat sowie eine beliebige Anzahl von CA-Zertifikaten enthält, die zur Feststellung der Echtheit des Zertifikats erforderlich sind. Die Zeichenkette keyfile muss, falls vorhanden, auf eine Datei mit dem privaten Schlüssel verweisen. Andernfalls wird der private Schlüssel ebenfalls aus certfile entnommen. Weitere Informationen darüber, wie das Zertifikat in der Datei certfile gespeichert ist, finden Sie in der Diskussion unter Zertifikate.

Das Argument password kann eine Funktion sein, die aufgerufen wird, um das Passwort zum Entschlüsseln des privaten Schlüssels zu erhalten. Sie wird nur aufgerufen, wenn der private Schlüssel verschlüsselt ist und ein Passwort benötigt wird. Sie wird ohne Argumente aufgerufen und sollte eine Zeichenkette, Bytes oder ein Bytearray zurückgeben. Wenn der Rückgabewert eine Zeichenkette ist, wird sie vor der Verwendung zur Entschlüsselung des Schlüssels als UTF-8 kodiert. Alternativ kann ein Zeichenketten-, Byte- oder Bytearraywert direkt als Argument password übergeben werden. Er wird ignoriert, wenn der private Schlüssel nicht verschlüsselt ist und kein Passwort benötigt wird.

Wenn das Argument password nicht angegeben ist und ein Passwort erforderlich ist, wird der integrierte Passwortabrufmechanismus von OpenSSL verwendet, um den Benutzer interaktiv nach einem Passwort zu fragen.

Wenn der private Schlüssel nicht mit dem Zertifikat übereinstimmt, wird ein SSLError ausgelöst.

Geändert in Version 3.3: Neues optionales Argument password.

SSLContext.load_default_certs(purpose=Purpose.SERVER_AUTH)¶

Laden Sie einen Satz von Standard-"Zertifizierungsstellen" (CA)-Zertifikaten aus Standard-Speicherorten. Unter Windows werden CA-Zertifikate aus den System-Stores CA und ROOT geladen. Auf allen Systemen wird SSLContext.set_default_verify_paths() aufgerufen. Zukünftig kann die Methode auch CA-Zertifikate aus anderen Speicherorten laden.

Das Flag purpose gibt an, welche Art von CA-Zertifikaten geladen werden. Die Standardeinstellung Purpose.SERVER_AUTH lädt Zertifikate, die für die TLS-Webserver-Authentifizierung (Client-seitige Sockets) gekennzeichnet und vertrauenswürdig sind. Purpose.CLIENT_AUTH lädt CA-Zertifikate für die Überprüfung von Client-Zertifikaten auf der Serverseite.

Hinzugefügt in Version 3.4.

SSLContext.load_verify_locations(cafile=None, capath=None, cadata=None)¶

Laden Sie einen Satz von "Zertifizierungsstellen" (CA)-Zertifikaten, die zur Validierung der Zertifikate anderer Peers verwendet werden, wenn verify_mode anders als CERT_NONE ist. Mindestens einer der Parameter cafile oder capath muss angegeben werden.

Diese Methode kann auch Zertifikatssperrlisten (CRLs) im PEM- oder DER-Format laden. Um CRLs nutzen zu können, muss SSLContext.verify_flags ordnungsgemäß konfiguriert sein.

Die Zeichenkette cafile ist, falls vorhanden, der Pfad zu einer Datei mit verketteten CA-Zertifikaten im PEM-Format. Wie die Zertifikate in dieser Datei angeordnet werden sollen, erfahren Sie in der Diskussion unter Zertifikate.

Die Zeichenkette capath ist, falls vorhanden, der Pfad zu einem Verzeichnis, das mehrere CA-Zertifikate im PEM-Format enthält und einem OpenSSL-spezifischen Layout folgt.

Das Objekt cadata ist, falls vorhanden, entweder eine ASCII-Zeichenkette mit einem oder mehreren PEM-kodierten Zertifikaten oder ein byteähnliches Objekt mit DER-kodierten Zertifikaten. Ähnlich wie bei capath werden zusätzliche Zeilen um PEM-kodierte Zertifikate herum ignoriert, aber mindestens ein Zertifikat muss vorhanden sein.

Geändert in Version 3.4: Neues optionales Argument cadata

SSLContext.get_ca_certs(binary_form=False)¶: Rufen Sie eine Liste der geladenen CA-Zertifikate ab. Wenn der Parameter binary_form False ist, ist jeder Listeneintrag ein Dictionary wie die Ausgabe von SSLSocket.getpeercert(). Andernfalls gibt die Methode eine Liste DER-kodierter Zertifikate zurück. Die zurückgegebene Liste enthält keine Zertifikate aus capath, es sei denn, ein Zertifikat wurde durch eine SSL-Verbindung angefordert und geladen.

Hinweis

Zertifikate in einem capath-Verzeichnis werden nicht geladen, es sei denn, sie wurden mindestens einmal verwendet.

Hinzugefügt in Version 3.4.

SSLContext.get_ciphers()¶

Rufen Sie eine Liste der aktivierten Cipher ab. Die Liste ist in der Reihenfolge der Cipher-Priorität angeordnet. Siehe SSLContext.set_ciphers().

Beispiel

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
>>> ctx.set_ciphers('ECDHE+AESGCM:!ECDSA')
>>> ctx.get_ciphers()
[{'aead': True,
  'alg_bits': 256,
  'auth': 'auth-rsa',
  'description': 'ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(256) Mac=AEAD',
  'digest': None,
  'id': 50380848,
  'kea': 'kx-ecdhe',
  'name': 'ECDHE-RSA-AES256-GCM-SHA384',
  'protocol': 'TLSv1.2',
  'strength_bits': 256,
  'symmetric': 'aes-256-gcm'},
 {'aead': True,
  'alg_bits': 128,
  'auth': 'auth-rsa',
  'description': 'ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(128) Mac=AEAD',
  'digest': None,
  'id': 50380847,
  'kea': 'kx-ecdhe',
  'name': 'ECDHE-RSA-AES128-GCM-SHA256',
  'protocol': 'TLSv1.2',
  'strength_bits': 128,
  'symmetric': 'aes-128-gcm'}]

Hinzugefügt in Version 3.6.

SSLContext.set_default_verify_paths()¶: Laden Sie einen Satz von Standard-"Zertifizierungsstellen" (CA)-Zertifikaten aus einem Dateisystempfad, der beim Erstellen der OpenSSL-Bibliothek definiert wurde. Leider gibt es keine einfache Möglichkeit festzustellen, ob diese Methode erfolgreich ist: Es wird kein Fehler zurückgegeben, wenn keine Zertifikate gefunden werden. Wenn die OpenSSL-Bibliothek als Teil des Betriebssystems bereitgestellt wird, ist sie jedoch wahrscheinlich richtig konfiguriert.

SSLContext.set_ciphers(ciphers, /)¶: Legen Sie die verfügbaren Cipher für Sockets fest, die mit diesem Kontext erstellt wurden. Dies sollte eine Zeichenkette im OpenSSL-Cipher-Listenformat sein. Wenn kein Cipher ausgewählt werden kann (weil Compile-Zeit-Optionen oder andere Konfigurationen die Verwendung aller angegebenen Cipher verbieten), wird ein SSLError ausgelöst.

Hinweis

Nach der Verbindung gibt die Methode SSLSocket.cipher() von SSL-Sockets den aktuell ausgewählten Cipher an.

TLS 1.3 Cipher Suites können nicht mit set_ciphers() deaktiviert werden.

SSLContext.set_alpn_protocols(alpn_protocols)¶

Geben Sie an, welche Protokolle der Socket während des SSL/TLS-Handshakes aushandeln soll. Dies sollte eine Liste von ASCII-Zeichenketten sein, z. B. ['http/1.1', 'spdy/2'], geordnet nach Präferenz. Die Auswahl eines Protokolls erfolgt während des Handshakes und wird gemäß RFC 7301 ausgeführt. Nach einem erfolgreichen Handshake gibt die Methode SSLSocket.selected_alpn_protocol() das vereinbarte Protokoll zurück.

Diese Methode löst NotImplementedError aus, wenn HAS_ALPN False ist.

Hinzugefügt in Version 3.5.

SSLContext.set_npn_protocols(npn_protocols)¶

Geben Sie an, welche Protokolle der Socket während des SSL/TLS-Handshakes aushandeln soll. Dies sollte eine Liste von Zeichenketten sein, z. B. ['http/1.1', 'spdy/2'], geordnet nach Präferenz. Die Auswahl eines Protokolls erfolgt während des Handshakes und wird gemäß der Application Layer Protocol Negotiation ausgeführt. Nach einem erfolgreichen Handshake gibt die Methode SSLSocket.selected_npn_protocol() das vereinbarte Protokoll zurück.

Diese Methode löst NotImplementedError aus, wenn HAS_NPN False ist.

Hinzugefügt in Version 3.3.

Veraltet seit Version 3.10: NPN wurde durch ALPN abgelöst

SSLContext.sni_callback¶

Registrieren Sie eine Callback-Funktion, die aufgerufen wird, nachdem die TLS Client Hello-Handshake-Nachricht vom SSL/TLS-Server empfangen wurde, wenn der TLS-Client eine Server Name Indication angibt. Der Mechanismus der Server Name Indication ist in RFC 6066 Abschnitt 3 - Server Name Indication beschrieben.

Pro SSLContext kann nur ein Callback gesetzt werden. Wenn sni_callback auf None gesetzt wird, ist der Callback deaktiviert. Wenn diese Funktion ein zweites Mal aufgerufen wird, wird der zuvor registrierte Callback deaktiviert.

Die Callback-Funktion wird mit drei Argumenten aufgerufen; das erste ist der ssl.SSLSocket, das zweite ist eine Zeichenkette, die den Servernamen repräsentiert, mit dem der Client kommunizieren möchte (oder None, wenn das TLS Client Hello keinen Servernamen enthält), und das dritte Argument ist der ursprüngliche SSLContext. Das Argument Servername ist Text. Für internationalisierte Domainnamen ist der Servername ein IDN A-Label ("xn--pythn-mua.org").

Ein typischer Anwendungsfall für diesen Callback ist die Änderung des Attributs SSLSocket.context des ssl.SSLSocket in ein neues Objekt vom Typ SSLContext, das eine Zertifikatkette repräsentiert, die mit dem Servernamen übereinstimmt.

Aufgrund der frühen Verhandlungsphase der TLS-Verbindung sind nur begrenzte Methoden und Attribute nutzbar, wie z. B. SSLSocket.selected_alpn_protocol() und SSLSocket.context. Die Methoden SSLSocket.getpeercert(), SSLSocket.get_verified_chain(), SSLSocket.get_unverified_chain() SSLSocket.cipher() und SSLSocket.compression() erfordern, dass die TLS-Verbindung über das TLS Client Hello hinaus fortgeschritten ist und geben daher keine aussagekräftigen Werte zurück, noch können sie sicher aufgerufen werden.

Die Funktion sni_callback muss None zurückgeben, um die TLS-Aushandlung fortzusetzen. Wenn ein TLS-Fehler erforderlich ist, kann eine Konstante ALERT_DESCRIPTION_INTERNAL_ERROR zurückgegeben werden. Andere Rückgabewerte führen zu einem fatalen TLS-Fehler mit ALERT_DESCRIPTION_INTERNAL_ERROR.

Wenn in der Funktion sni_callback eine Ausnahme ausgelöst wird, wird die TLS-Verbindung mit einer fatalen TLS-Alert-Nachricht ALERT_DESCRIPTION_HANDSHAKE_FAILURE beendet.

Diese Methode löst NotImplementedError aus, wenn die OpenSSL-Bibliothek bei der Erstellung OPENSSL_NO_TLSEXT definiert hatte.

Hinzugefügt in Version 3.7.

SSLContext.set_servername_callback(server_name_callback)¶

Dies ist eine Legacy-API, die aus Kompatibilitätsgründen beibehalten wird. Wenn möglich, sollten Sie stattdessen sni_callback verwenden. Der angegebene server_name_callback ähnelt sni_callback, mit dem Unterschied, dass der server_name_callback ein dekodiertes U-Label ("pythön.org") erhält, wenn der Server-Hostname ein IDN-kodierter internationalisierter Domainname ist.

Wenn ein Dekodierungsfehler beim Servernamen auftritt, wird die TLS-Verbindung mit einer fatalen TLS-Alert-Nachricht ALERT_DESCRIPTION_INTERNAL_ERROR an den Client beendet.

Hinzugefügt in Version 3.4.

SSLContext.load_dh_params(dhfile, /)¶

Laden Sie die Parameter zur Schlüsselerzeugung für den Diffie-Hellman (DH)-Schlüsselaustausch. Die Verwendung des DH-Schlüsselaustauschs verbessert die Forward Secrecy auf Kosten von Rechenressourcen (sowohl auf dem Server als auch auf dem Client). Der Parameter dhfile sollte der Pfad zu einer Datei sein, die DH-Parameter im PEM-Format enthält.

Diese Einstellung gilt nicht für Client-Sockets. Sie können auch die Option OP_SINGLE_DH_USE verwenden, um die Sicherheit weiter zu verbessern.

Hinzugefügt in Version 3.3.

SSLContext.set_ecdh_curve(curve_name, /)¶

Setzen Sie den Kurvennamen für den Elliptische Kurven-basierten Diffie-Hellman (ECDH)-Schlüsselaustausch. ECDH ist deutlich schneller als reguläres DH und dabei wohl genauso sicher. Der Parameter curve_name sollte eine Zeichenkette sein, die eine bekannte elliptische Kurve beschreibt, z. B. prime256v1 für eine weit verbreitete Kurve.

Diese Einstellung gilt nicht für Client-Sockets. Sie können auch die Option OP_SINGLE_ECDH_USE verwenden, um die Sicherheit weiter zu verbessern.

Diese Methode ist nicht verfügbar, wenn HAS_ECDH False ist.

Hinzugefügt in Version 3.3.

Siehe auch

SSL/TLS & Perfect Forward Secrecy: Vincent Bernat.

SSLContext.wrap_socket(sock, server_side=False, do_handshake_on_connect=True, suppress_ragged_eofs=True, server_hostname=None, session=None)¶

Umschließen Sie einen vorhandenen Python-Socket sock und geben Sie eine Instanz von SSLContext.sslsocket_class (standardmäßig SSLSocket) zurück. Der zurückgegebene SSL-Socket ist an den Kontext, seine Einstellungen und Zertifikate gebunden. sock muss ein SOCK_STREAM-Socket sein; andere Socket-Typen werden nicht unterstützt.

Der Parameter server_side ist ein boolescher Wert, der angibt, ob für diesen Socket ein serverseitiges oder clientseitiges Verhalten gewünscht ist.

Für clientseitige Sockets erfolgt die Konstruktion des Kontexts verzögert. Wenn der zugrunde liegende Socket noch nicht verbunden ist, wird die Konstruktion des Kontexts nach dem Aufruf von connect() für den Socket durchgeführt. Für serverseitige Sockets wird, wenn der Socket keinen entfernten Peer hat, angenommen, dass es sich um einen lauschenden Socket handelt, und das serverseitige SSL-Wrapping wird automatisch bei Client-Verbindungen durchgeführt, die über die Methode accept() akzeptiert werden. Die Methode kann SSLError auslösen.

Bei Client-Verbindungen gibt der optionale Parameter server_hostname den Hostnamen des Dienstes an, mit dem wir uns verbinden. Dies ermöglicht einem einzelnen Server, mehrere SSL-basierte Dienste mit unterschiedlichen Zertifikaten zu hosten, ähnlich wie bei HTTP-virtuellen Hosts. Die Angabe von server_hostname löst einen ValueError aus, wenn server_side true ist.

Der Parameter do_handshake_on_connect gibt an, ob der SSL-Handshake nach dem Aufruf von socket.connect() automatisch durchgeführt werden soll oder ob das Anwendungsprogramm ihn explizit durch Aufruf der Methode SSLSocket.do_handshake() aufruft. Der explizite Aufruf von SSLSocket.do_handshake() gibt dem Programm die Kontrolle über das blockierende Verhalten der Socket-I/O, die am Handshake beteiligt ist.

Der Parameter suppress_ragged_eofs gibt an, wie die Methode SSLSocket.recv() unerwartete EOFs vom anderen Ende der Verbindung signalisieren soll. Wenn er auf True (Standard) gesetzt ist, gibt er einen normalen EOF (ein leeres Bytes-Objekt) als Reaktion auf unerwartete EOF-Fehler aus dem zugrunde liegenden Socket zurück; wenn er auf False gesetzt ist, werden die Ausnahmen an den Aufrufer zurückgegeben.

session, siehe session.

Um einen SSLSocket in einen anderen SSLSocket zu wrappen, verwenden Sie SSLContext.wrap_bio().

Geändert in Version 3.5: Erlaubt immer die Übergabe eines server_hostname, auch wenn OpenSSL kein SNI hat.

Geändert in Version 3.6: Das Argument session wurde hinzugefügt.

Geändert in Version 3.7: Die Methode gibt eine Instanz von SSLContext.sslsocket_class anstelle eines hartcodierten SSLSocket zurück.

SSLContext.sslsocket_class¶: Der Rückgabetyp von SSLContext.wrap_socket(), standardmäßig SSLSocket. Das Attribut kann auf Instanzen von SSLContext zugewiesen werden, um eine benutzerdefinierte Unterklasse von SSLSocket zurückzugeben.

Hinzugefügt in Version 3.7.

SSLContext.wrap_bio(incoming, outgoing, server_side=False, server_hostname=None, session=None)¶

Wickeln Sie die BIO-Objekte incoming und outgoing und geben Sie eine Instanz von SSLContext.sslobject_class (standardmäßig SSLObject) zurück. Die SSL-Routinen lesen Eingabedaten aus dem eingehenden BIO und schreiben Daten in das ausgehende BIO.

Die Parameter server_side, server_hostname und session haben die gleiche Bedeutung wie in SSLContext.wrap_socket().

Geändert in Version 3.6: Das Argument session wurde hinzugefügt.

Geändert in Version 3.7: Die Methode gibt eine Instanz von SSLContext.sslobject_class anstelle eines hartcodierten SSLObject zurück.

SSLContext.sslobject_class¶: Der Rückgabetyp von SSLContext.wrap_bio(), standardmäßig SSLObject. Das Attribut kann auf Instanzen der Klasse überschrieben werden, um eine benutzerdefinierte Unterklasse von SSLObject zurückzugeben.

Hinzugefügt in Version 3.7.

SSLContext.session_stats()¶

Rufen Sie Statistiken über die von diesem Kontext erstellten oder verwalteten SSL-Sitzungen ab. Es wird ein Dictionary zurückgegeben, das die Namen jeder Informationskomponente ihren numerischen Werten zuordnet. Hier ist zum Beispiel die Gesamtzahl der Treffer und Fehlschläge im Sitzungscache seit der Erstellung des Kontexts

>>> stats = context.session_stats()
>>> stats['hits'], stats['misses']
(0, 0)

SSLContext.check_hostname¶

Ob, ob das Zertifikat des Peers im Hostnamen in SSLSocket.do_handshake() übereinstimmen soll. Der verify_mode des Kontexts muss auf CERT_OPTIONAL oder CERT_REQUIRED gesetzt werden, und Sie müssen server_hostname an wrap_socket() übergeben, um den Hostnamen abzugleichen. Das Aktivieren der Hostnamenprüfung setzt automatisch verify_mode von CERT_NONE auf CERT_REQUIRED. Es kann nicht auf CERT_NONE zurückgesetzt werden, solange die Hostnamenprüfung aktiviert ist. Das PROTOCOL_TLS_CLIENT-Protokoll aktiviert die Hostnamenprüfung standardmäßig. Bei anderen Protokollen muss die Hostnamenprüfung explizit aktiviert werden.

Beispiel

import socket, ssl

context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
context.verify_mode = ssl.CERT_REQUIRED
context.check_hostname = True
context.load_default_certs()

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = context.wrap_socket(s, server_hostname='www.verisign.com')
ssl_sock.connect(('www.verisign.com', 443))

Hinzugefügt in Version 3.4.

Geändert in Version 3.7: verify_mode wird nun automatisch auf CERT_REQUIRED geändert, wenn die Hostnamenprüfung aktiviert ist und verify_mode CERT_NONE ist. Zuvor wäre dieselbe Operation mit einem ValueError fehlgeschlagen.

SSLContext.keylog_filename¶: Schreibt TLS-Schlüssel in eine Keylog-Datei, wann immer Schlüsselmaterial generiert oder empfangen wird. Die Keylog-Datei ist nur für Debugging-Zwecke bestimmt. Das Dateiformat wird von NSS spezifiziert und von vielen Traffic-Analysatoren wie Wireshark verwendet. Die Logdatei wird im Nur-Anhängen-Modus geöffnet. Schreibvorgänge werden zwischen Threads synchronisiert, aber nicht zwischen Prozessen.

Hinzugefügt in Version 3.8.

SSLContext.maximum_version¶

Ein Mitglied der TLSVersion-Aufzählung, das die höchste unterstützte TLS-Version darstellt. Der Wert ist standardmäßig TLSVersion.MAXIMUM_SUPPORTED. Das Attribut ist schreibgeschützt für andere Protokolle als PROTOCOL_TLS, PROTOCOL_TLS_CLIENT und PROTOCOL_TLS_SERVER.

Die Attribute maximum_version, minimum_version und SSLContext.options wirken sich alle auf die unterstützten SSL- und TLS-Versionen des Kontexts aus. Die Implementierung verhindert keine ungültige Kombination. Zum Beispiel wird ein Kontext mit OP_NO_TLSv1_2 in options und maximum_version auf TLSVersion.TLSv1_2 gesetzt, keine TLS 1.2-Verbindung herstellen können.

Hinzugefügt in Version 3.7.

SSLContext.minimum_version¶: Wie SSLContext.maximum_version, außer dass es die niedrigste unterstützte Version oder TLSVersion.MINIMUM_SUPPORTED ist.

Hinzugefügt in Version 3.7.

SSLContext.num_tickets¶: Kontrolliert die Anzahl der TLS 1.3-Sitzungstickets eines PROTOCOL_TLS_SERVER-Kontexts. Die Einstellung hat keine Auswirkung auf TLS 1.0 bis 1.2-Verbindungen.

Hinzugefügt in Version 3.8.

SSLContext.options¶

Eine Ganzzahl, die die Menge der im Kontext aktivierten SSL-Optionen darstellt. Der Standardwert ist OP_ALL, aber Sie können andere Optionen wie OP_NO_SSLv2 durch ODER-Verknüpfung angeben.

Geändert in Version 3.6: SSLContext.options gibt Options-Flags zurück

>>> ssl.create_default_context().options
<Options.OP_ALL|OP_NO_SSLv3|OP_NO_SSLv2|OP_NO_COMPRESSION: 2197947391>

Veraltet seit Version 3.7: Alle Optionen OP_NO_SSL* und OP_NO_TLS* sind seit Python 3.7 veraltet. Verwenden Sie stattdessen SSLContext.minimum_version und SSLContext.maximum_version.

SSLContext.post_handshake_auth¶

Aktiviert die TLS 1.3-Clientauthentifizierung nach dem Handshake. Post-Handshake-Authentifizierung ist standardmäßig deaktiviert, und ein Server kann während des initialen Handshakes ein TLS-Clientzertifikat anfordern. Wenn aktiviert, kann ein Server jederzeit nach dem Handshake ein TLS-Clientzertifikat anfordern.

Wenn auf clientseitigen Sockets aktiviert, signalisiert der Client dem Server, dass er die Post-Handshake-Authentifizierung unterstützt.

Wenn auf serverseitigen Sockets aktiviert, muss SSLContext.verify_mode ebenfalls auf CERT_OPTIONAL oder CERT_REQUIRED gesetzt sein. Der tatsächliche Client-Zertifikataustausch wird bis zum Aufruf von SSLSocket.verify_client_post_handshake() und der Durchführung von I/O verzögert.

Hinzugefügt in Version 3.8.

SSLContext.protocol¶: Die beim Erstellen des Kontexts ausgewählte Protokollversion. Dieses Attribut ist schreibgeschützt.

SSLContext.hostname_checks_common_name¶: Ob check_hostname auf die Überprüfung des Common Name des Zertifikatsubjekts zurückfällt, wenn keine Subject Alternative Name-Erweiterung vorhanden ist (Standard: true).

Hinzugefügt in Version 3.7.

Geändert in Version 3.10: Das Flag hatte vor Version 1.1.1l von OpenSSL keine Auswirkung. Python 3.8.9, 3.9.3 und 3.10 enthalten Workarounds für frühere Versionen.

SSLContext.security_level¶: Eine Ganzzahl, die die Sicherheitsstufe für den Kontext darstellt. Dieses Attribut ist schreibgeschützt.

Hinzugefügt in Version 3.10.

SSLContext.verify_flags¶

Die Flags für Zertifikatsüberprüfungsoperationen. Sie können Flags wie VERIFY_CRL_CHECK_LEAF durch ODER-Verknüpfung setzen. Standardmäßig verlangt und überprüft OpenSSL keine Certificate Revocation Lists (CRLs).

Hinzugefügt in Version 3.4.

Geändert in Version 3.6: SSLContext.verify_flags gibt VerifyFlags-Flags zurück

>>> ssl.create_default_context().verify_flags
<VerifyFlags.VERIFY_X509_TRUSTED_FIRST: 32768>

SSLContext.verify_mode¶

Ob die Zertifikate anderer Peers überprüft werden sollen und wie zu verhalten ist, wenn die Überprüfung fehlschlägt. Dieses Attribut muss einer der folgenden Werte sein: CERT_NONE, CERT_OPTIONAL oder CERT_REQUIRED.

Geändert in Version 3.6: SSLContext.verify_mode gibt VerifyMode-Enumerationswerte zurück

>>> ssl.create_default_context().verify_mode
<VerifyMode.CERT_REQUIRED: 2>

SSLContext.set_psk_client_callback(callback)¶

Aktiviert TLS-PSK (Pre-Shared Key) Authentifizierung bei einer clientseitigen Verbindung.

Im Allgemeinen sollte die zertifikatsbasierte Authentifizierung dieser Methode vorgezogen werden.

Der Parameter callback ist ein aufrufbares Objekt mit der Signatur: def callback(hint: str | None) -> tuple[str | None, bytes]. Der Parameter hint ist ein optionaler Identitätshinweis, der vom Server gesendet wird. Der Rückgabewert ist ein Tupel im Format (client-identity, psk). Client-identity ist eine optionale Zeichenkette, die vom Server verwendet werden kann, um eine entsprechende PSK für den Client auszuwählen. Die Zeichenkette darf bei UTF-8-Kodierung maximal 256 Oktette lang sein. PSK ist ein bytes-ähnliches Objekt, das den Pre-Shared Key darstellt. Geben Sie eine PSK der Länge Null zurück, um die Verbindung abzulehnen.

Das Setzen von callback auf None entfernt jeden vorhandenen Callback.

Hinweis

Bei Verwendung von TLS 1.3

ist der Parameter hint immer None.
client-identity muss eine nicht leere Zeichenkette sein.

Beispielverwendung

context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE
context.maximum_version = ssl.TLSVersion.TLSv1_2
context.set_ciphers('PSK')

# A simple lambda:
psk = bytes.fromhex('c0ffee')
context.set_psk_client_callback(lambda hint: (None, psk))

# A table using the hint from the server:
psk_table = { 'ServerId_1': bytes.fromhex('c0ffee'),
              'ServerId_2': bytes.fromhex('facade')
}
def callback(hint):
    return 'ClientId_1', psk_table.get(hint, b'')
context.set_psk_client_callback(callback)

Diese Methode löst NotImplementedError aus, wenn HAS_PSK False ist.

Hinzugefügt in Version 3.13.

SSLContext.set_psk_server_callback(callback, identity_hint=None)¶

Aktiviert TLS-PSK (Pre-Shared Key) Authentifizierung bei einer serverseitigen Verbindung.

Im Allgemeinen sollte die zertifikatsbasierte Authentifizierung dieser Methode vorgezogen werden.

Der Parameter callback ist ein aufrufbares Objekt mit der Signatur: def callback(identity: str | None) -> bytes. Der Parameter identity ist eine optionale Identität, die vom Client gesendet wird und zur Auswahl einer entsprechenden PSK verwendet werden kann. Der Rückgabewert ist ein bytes-ähnliches Objekt, das den Pre-Shared Key darstellt. Geben Sie eine PSK der Länge Null zurück, um die Verbindung abzulehnen.

Das Setzen von callback auf None entfernt jeden vorhandenen Callback.

Der Parameter identity_hint ist eine optionale Identitätshinweis-Zeichenkette, die an den Client gesendet wird. Die Zeichenkette darf bei UTF-8-Kodierung maximal 256 Oktette lang sein.

Hinweis

Bei Verwendung von TLS 1.3 wird der Parameter identity_hint nicht an den Client gesendet.

Beispielverwendung

context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.maximum_version = ssl.TLSVersion.TLSv1_2
context.set_ciphers('PSK')

# A simple lambda:
psk = bytes.fromhex('c0ffee')
context.set_psk_server_callback(lambda identity: psk)

# A table using the identity of the client:
psk_table = { 'ClientId_1': bytes.fromhex('c0ffee'),
              'ClientId_2': bytes.fromhex('facade')
}
def callback(identity):
    return psk_table.get(identity, b'')
context.set_psk_server_callback(callback, 'ServerId_1')

Diese Methode löst NotImplementedError aus, wenn HAS_PSK False ist.

Hinzugefügt in Version 3.13.

Zertifikate¶

Zertifikate sind im Allgemeinen Teil eines öffentlichen/privaten Schlüsselsystems. In diesem System wird jedem Teilnehmer (der eine Maschine, eine Person oder eine Organisation sein kann) ein eindeutiger zweiteiliger Verschlüsselungsschlüssel zugewiesen. Ein Teil des Schlüssels ist öffentlich und wird als öffentlicher Schlüssel bezeichnet; der andere Teil wird geheim gehalten und als privater Schlüssel bezeichnet. Die beiden Teile sind so miteinander verbunden, dass, wenn Sie eine Nachricht mit einem der Teile verschlüsseln, Sie sie mit dem anderen Teil entschlüsseln können, und zwar **nur** mit dem anderen Teil.

Ein Zertifikat enthält Informationen über zwei Teilnehmer. Es enthält den Namen eines Subjekts und den öffentlichen Schlüssel des Subjekts. Es enthält auch eine Aussage eines zweiten Teilnehmers, des Ausstellers, dass das Subjekt derjenige ist, der es vorgibt zu sein, und dass dies tatsächlich der öffentliche Schlüssel des Subjekts ist. Die Aussage des Ausstellers ist mit dem privaten Schlüssel des Ausstellers signiert, den nur der Aussteller kennt. Jeder kann jedoch die Aussage des Ausstellers überprüfen, indem er den öffentlichen Schlüssel des Ausstellers findet, die Aussage damit entschlüsselt und sie mit den anderen Informationen im Zertifikat vergleicht. Das Zertifikat enthält auch Informationen über den Zeitraum, über den es gültig ist. Dies wird durch zwei Felder ausgedrückt, die "notBefore" und "notAfter" genannt werden.

In der Python-Verwendung von Zertifikaten kann ein Client oder Server ein Zertifikat verwenden, um seine Identität nachzuweisen. Die andere Seite einer Netzwerkverbindung kann auch aufgefordert werden, ein Zertifikat vorzulegen, und dieses Zertifikat kann zur Zufriedenheit des Clients oder Servers, der eine solche Überprüfung verlangt, validiert werden. Die Verbindungsanfrage kann so eingestellt werden, dass eine Ausnahme ausgelöst wird, wenn die Validierung fehlschlägt. Die Validierung wird automatisch vom zugrunde liegenden OpenSSL-Framework durchgeführt; die Anwendung muss sich nicht um deren Mechanik kümmern. Aber die Anwendung muss normalerweise Sätze von Zertifikaten bereitstellen, um diesen Prozess zu ermöglichen.

Python verwendet Dateien zur Speicherung von Zertifikaten. Sie sollten im "PEM"-Format vorliegen (siehe RFC 1422), was einer Base-64-kodierten Form entspricht, die mit einer Kopfzeile und einer Fußzeile umschlossen ist.

-----BEGIN CERTIFICATE-----
... (certificate in base64 PEM encoding) ...
-----END CERTIFICATE-----

Zertifikatsketten¶

Die Python-Dateien, die Zertifikate enthalten, können eine Sequenz von Zertifikaten enthalten, die manchmal als Zertifikatskette bezeichnet wird. Diese Kette sollte mit dem spezifischen Zertifikat für den Teilnehmer beginnen, der der Client oder Server "ist", dann dem Zertifikat des Ausstellers dieses Zertifikats und dann dem Zertifikat des Ausstellers dieses Zertifikats und so weiter die Kette hinauf, bis Sie zu einem Zertifikat gelangen, das selbstsigniert ist, d. h. ein Zertifikat, das denselben Betreff und Aussteller hat, manchmal auch als Stammzertifikat bezeichnet. Die Zertifikate sollten einfach in der Zertifikatsdatei verkettet werden. Angenommen, wir hätten eine dreifache Zertifikatskette, vom Serverzertifikat zum Zertifikat der Zertifizierungsstelle, die unser Serverzertifikat signiert hat, zum Stammzertifikat der Behörde, die das Zertifikat der Zertifizierungsstelle ausgestellt hat.

-----BEGIN CERTIFICATE-----
... (certificate for your server)...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (the certificate for the CA)...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (the root certificate for the CA's issuer)...
-----END CERTIFICATE-----

CA-Zertifikate¶

Wenn Sie die Überprüfung des Zertifikats der anderen Seite der Verbindung verlangen möchten, müssen Sie eine "CA-Zertifikate"-Datei bereitstellen, die mit den Zertifikatsketten für jeden Aussteller gefüllt ist, dem Sie vertrauen möchten. Auch diese Datei enthält nur diese verketteten Ketten. Für die Validierung verwendet Python die erste Kette, die es in der Datei findet und die übereinstimmt. Die Zertifikatsdatei der Plattform kann durch Aufrufen von SSLContext.load_default_certs() verwendet werden, dies geschieht automatisch mit create_default_context().

Kombinierter Schlüssel und Zertifikat¶

Oft ist der private Schlüssel in derselben Datei wie das Zertifikat gespeichert; in diesem Fall muss nur der Parameter certfile an SSLContext.load_cert_chain() übergeben werden. Wenn der private Schlüssel zusammen mit dem Zertifikat gespeichert ist, sollte er vor dem ersten Zertifikat in der Zertifikatskette stehen.

-----BEGIN RSA PRIVATE KEY-----
... (private key in base64 encoding) ...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
... (certificate in base64 PEM encoding) ...
-----END CERTIFICATE-----

Selbstsignierte Zertifikate¶

Wenn Sie einen Server erstellen, der SSL-verschlüsselte Verbindungsdienste anbietet, benötigen Sie ein Zertifikat für diesen Dienst. Es gibt viele Möglichkeiten, geeignete Zertifikate zu erwerben, z. B. indem Sie eines von einer Zertifizierungsstelle kaufen. Eine weitere gängige Praxis ist die Generierung eines selbstsignierten Zertifikats. Der einfachste Weg, dies zu tun, ist mit dem OpenSSL-Paket, indem Sie etwas wie das Folgende verwenden.

% openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
Generating a 1024 bit RSA private key
.......++++++
.............................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:MyState
Locality Name (eg, city) []:Some City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Organization, Inc.
Organizational Unit Name (eg, section) []:My Group
Common Name (eg, YOUR name) []:myserver.mygroup.myorganization.com
Email Address []:ops@myserver.mygroup.myorganization.com
%

Der Nachteil eines selbstsignierten Zertifikats ist, dass es sein eigenes Stammzertifikat ist und niemand sonst es in seinem Cache bekannter (und vertrauenswürdiger) Stammzertifikate haben wird.

Beispiele¶

SSL-Unterstützung testen¶

Um die Anwesenheit von SSL-Unterstützung in einer Python-Installation zu testen, sollte der Benutzercode die folgende Idiomatik verwenden.

try:
    import ssl
except ImportError:
    pass
else:
    ...  # do something that requires SSL support

Clientseitiger Betrieb¶

Dieses Beispiel erstellt einen SSL-Kontext mit den empfohlenen Sicherheitseinstellungen für Client-Sockets, einschließlich der automatischen Zertifikatsüberprüfung.

>>> context = ssl.create_default_context()

Wenn Sie die Sicherheitseinstellungen lieber selbst abstimmen möchten, können Sie einen Kontext von Grund auf neu erstellen (aber seien Sie vorsichtig, dass Sie die Einstellungen möglicherweise nicht richtig vornehmen).

>>> context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
>>> context.load_verify_locations("/etc/ssl/certs/ca-bundle.crt")

(Dieses Snippet geht davon aus, dass Ihr Betriebssystem ein Bündel aller CA-Zertifikate unter /etc/ssl/certs/ca-bundle.crt ablegt; wenn nicht, erhalten Sie einen Fehler und müssen den Speicherort anpassen)

Das Protokoll PROTOCOL_TLS_CLIENT konfiguriert den Kontext für Zertifikatsvalidierung und Hostnamenüberprüfung. verify_mode wird auf CERT_REQUIRED und check_hostname auf True gesetzt. Alle anderen Protokolle erstellen SSL-Kontexte mit unsicheren Standardeinstellungen.

Wenn Sie den Kontext zum Verbinden mit einem Server verwenden, validieren CERT_REQUIRED und check_hostname das Serverzertifikat: es stellt sicher, dass das Serverzertifikat mit einem der CA-Zertifikate signiert wurde, prüft die Signatur auf Korrektheit und validiert andere Eigenschaften wie Gültigkeit und Identität des Hostnamens.

>>> conn = context.wrap_socket(socket.socket(socket.AF_INET),
...                            server_hostname="www.python.org")
>>> conn.connect(("www.python.org", 443))

Sie können dann das Zertifikat abrufen.

>>> cert = conn.getpeercert()

Die visuelle Inspektion zeigt, dass das Zertifikat den gewünschten Dienst identifiziert (d. h. den HTTPS-Host www.python.org).

>>> pprint.pprint(cert)
{'OCSP': ('http://ocsp.digicert.com',),
 'caIssuers': ('http://cacerts.digicert.com/DigiCertSHA2ExtendedValidationServerCA.crt',),
 'crlDistributionPoints': ('http://crl3.digicert.com/sha2-ev-server-g1.crl',
                           'http://crl4.digicert.com/sha2-ev-server-g1.crl'),
 'issuer': ((('countryName', 'US'),),
            (('organizationName', 'DigiCert Inc'),),
            (('organizationalUnitName', 'www.digicert.com'),),
            (('commonName', 'DigiCert SHA2 Extended Validation Server CA'),)),
 'notAfter': 'Sep  9 12:00:00 2016 GMT',
 'notBefore': 'Sep  5 00:00:00 2014 GMT',
 'serialNumber': '01BB6F00122B177F36CAB49CEA8B6B26',
 'subject': ((('businessCategory', 'Private Organization'),),
             (('1.3.6.1.4.1.311.60.2.1.3', 'US'),),
             (('1.3.6.1.4.1.311.60.2.1.2', 'Delaware'),),
             (('serialNumber', '3359300'),),
             (('streetAddress', '16 Allen Rd'),),
             (('postalCode', '03894-4801'),),
             (('countryName', 'US'),),
             (('stateOrProvinceName', 'NH'),),
             (('localityName', 'Wolfeboro'),),
             (('organizationName', 'Python Software Foundation'),),
             (('commonName', 'www.python.org'),)),
 'subjectAltName': (('DNS', 'www.python.org'),
                    ('DNS', 'python.org'),
                    ('DNS', 'pypi.org'),
                    ('DNS', 'docs.python.org'),
                    ('DNS', 'testpypi.org'),
                    ('DNS', 'bugs.python.org'),
                    ('DNS', 'wiki.python.org'),
                    ('DNS', 'hg.python.org'),
                    ('DNS', 'mail.python.org'),
                    ('DNS', 'packaging.python.org'),
                    ('DNS', 'pythonhosted.org'),
                    ('DNS', 'www.pythonhosted.org'),
                    ('DNS', 'test.pythonhosted.org'),
                    ('DNS', 'us.pycon.org'),
                    ('DNS', 'id.python.org')),
 'version': 3}

Nun ist der SSL-Kanal eingerichtet und das Zertifikat verifiziert, Sie können mit dem Server kommunizieren.

>>> conn.sendall(b"HEAD / HTTP/1.0\r\nHost: linuxfr.org\r\n\r\n")
>>> pprint.pprint(conn.recv(1024).split(b"\r\n"))
[b'HTTP/1.1 200 OK',
 b'Date: Sat, 18 Oct 2014 18:27:20 GMT',
 b'Server: nginx',
 b'Content-Type: text/html; charset=utf-8',
 b'X-Frame-Options: SAMEORIGIN',
 b'Content-Length: 45679',
 b'Accept-Ranges: bytes',
 b'Via: 1.1 varnish',
 b'Age: 2188',
 b'X-Served-By: cache-lcy1134-LCY',
 b'X-Cache: HIT',
 b'X-Cache-Hits: 11',
 b'Vary: Cookie',
 b'Strict-Transport-Security: max-age=63072000; includeSubDomains',
 b'Connection: close',
 b'',
 b'']

Siehe die Diskussion der Sicherheitsüberlegungen unten.

Serverseitiger Betrieb¶

Für den Serverbetrieb benötigen Sie normalerweise ein Serverzertifikat und einen privaten Schlüssel, beide in einer Datei. Sie erstellen zuerst einen Kontext, der den Schlüssel und das Zertifikat enthält, damit Clients Ihre Authentizität überprüfen können. Dann öffnen Sie einen Socket, binden ihn an einen Port, rufen listen() darauf auf und beginnen, auf Client-Verbindungen zu warten.

import socket, ssl

context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context.load_cert_chain(certfile="mycertfile", keyfile="mykeyfile")

bindsocket = socket.socket()
bindsocket.bind(('myaddr.example.com', 10023))
bindsocket.listen(5)

Wenn sich ein Client verbindet, rufen Sie accept() auf dem Socket auf, um den neuen Socket vom anderen Ende zu erhalten, und verwenden die Methode SSLContext.wrap_socket() des Kontexts, um einen serverseitigen SSL-Socket für die Verbindung zu erstellen.

while True:
    newsocket, fromaddr = bindsocket.accept()
    connstream = context.wrap_socket(newsocket, server_side=True)
    try:
        deal_with_client(connstream)
    finally:
        connstream.shutdown(socket.SHUT_RDWR)
        connstream.close()

Dann lesen Sie Daten aus dem connstream und tun etwas damit, bis Sie mit dem Client fertig sind (oder der Client mit Ihnen fertig ist).

def deal_with_client(connstream):
    data = connstream.recv(1024)
    # empty data means the client is finished with us
    while data:
        if not do_something(connstream, data):
            # we'll assume do_something returns False
            # when we're finished with client
            break
        data = connstream.recv(1024)
    # finished with client

Und gehen Sie zurück, um auf neue Client-Verbindungen zu lauschen (natürlich würde ein echter Server wahrscheinlich jede Client-Verbindung in einem separaten Thread behandeln oder die Sockets in den Nicht-Blockierungsmodus versetzen und eine Ereignisschleife verwenden).

Hinweise zu Nicht-Blockierenden Sockets¶

SSL-Sockets verhalten sich im Nicht-Blockierungsmodus etwas anders als reguläre Sockets. Bei der Arbeit mit Nicht-Blockierenden Sockets gibt es daher mehrere Dinge zu beachten.

Die meisten Methoden von SSLSocket lösen entweder SSLWantWriteError oder SSLWantReadError anstelle von BlockingIOError aus, wenn eine I/O-Operation blockieren würde. SSLWantReadError wird ausgelöst, wenn ein Lesevorgang am zugrunde liegenden Socket erforderlich ist, und SSLWantWriteError für einen Schreibvorgang am zugrunde liegenden Socket. Beachten Sie, dass Schreibversuche auf einen SSL-Socket möglicherweise zuerst das Lesen vom zugrunde liegenden Socket erfordern, und Leseversuche vom SSL-Socket möglicherweise ein vorheriges Schreiben an den zugrunde liegenden Socket erfordern.

Geändert in Version 3.5: In früheren Python-Versionen gab die Methode SSLSocket.send() null zurück, anstatt SSLWantWriteError oder SSLWantReadError auszulösen.
Das Aufrufen von select() teilt Ihnen mit, dass der Socket auf Betriebssystemebene gelesen (oder geschrieben) werden kann, impliziert aber nicht, dass genügend Daten auf der oberen SSL-Schicht vorhanden sind. Es könnte beispielsweise nur ein Teil eines SSL-Frames angekommen sein. Daher müssen Sie bereit sein, Fehler bei SSLSocket.recv() und SSLSocket.send() zu behandeln und nach einem weiteren Aufruf von select() erneut zu versuchen.
Umgekehrt kann ein SSL-Socket, da die SSL-Schicht ihre eigene Rahmung hat, noch Daten zum Lesen verfügbar haben, ohne dass select() davon Kenntnis hat. Daher sollten Sie zuerst SSLSocket.recv() aufrufen, um alle potenziell verfügbaren Daten zu entleeren, und dann nur bei einem Aufruf von select() blockieren, wenn dies immer noch notwendig ist.

(natürlich gelten ähnliche Bestimmungen bei der Verwendung anderer Primitiven wie poll() oder der im Modul selectors)

Der SSL-Handshake selbst ist nicht blockierend: die Methode SSLSocket.do_handshake() muss wiederholt aufgerufen werden, bis sie erfolgreich zurückkehrt. Hier ist eine Übersicht, die select() verwendet, um auf die Bereitschaft des Sockets zu warten.

while True:
    try:
        sock.do_handshake()
        break
    except ssl.SSLWantReadError:
        select.select([sock], [], [])
    except ssl.SSLWantWriteError:
        select.select([], [sock], [])

Siehe auch

Das Modul asyncio unterstützt Nicht-Blockierende SSL-Sockets und bietet eine höherrangige Streams API. Es pollt auf Ereignisse über das Modul selectors und behandelt Ausnahmen vom Typ SSLWantWriteError, SSLWantReadError und BlockingIOError. Es führt auch den SSL-Handshake asynchron aus.

Unterstützung für Memory BIOs¶

Hinzugefügt in Version 3.5.

Seit der Einführung des SSL-Moduls in Python 2.6 bietet die Klasse SSLSocket zwei verwandte, aber unterschiedliche Funktionsbereiche.

SSL-Protokollbehandlung
Netzwerk-IO

Die Netzwerk-IO-API ist identisch mit der von socket.socket, von der SSLSocket ebenfalls erbt. Dies ermöglicht die Verwendung eines SSL-Sockets als Drop-in-Ersatz für einen regulären Socket, wodurch es sehr einfach ist, einer bestehenden Anwendung SSL-Unterstützung hinzuzufügen.

Die Kombination von SSL-Protokollbehandlung und Netzwerk-IO funktioniert im Allgemeinen gut, aber es gibt einige Fälle, in denen dies nicht der Fall ist. Ein Beispiel sind asynchrone IO-Frameworks, die ein anderes IO-Multiplexing-Modell als das "select/poll auf einem Dateideskriptor" (bereitschaftsbasiert) Modell verwenden möchten, das von socket.socket und den internen OpenSSL-Socket-IO-Routinen angenommen wird. Dies ist hauptsächlich auf Plattformen wie Windows relevant, wo dieses Modell nicht effizient ist. Zu diesem Zweck wird eine reduzierte Variante von SSLSocket namens SSLObject bereitgestellt.

class ssl.SSLObject¶

Eine Variante mit reduziertem Umfang von SSLSocket, die eine SSL-Protokollinstanz darstellt, die keine Netzwerk-IO-Methoden enthält. Diese Klasse wird typischerweise von Framework-Autoren verwendet, die asynchrone IO für SSL über Speicherpuffer implementieren möchten.

Diese Klasse implementiert eine Schnittstelle über einem Low-Level-SSL-Objekt, wie es von OpenSSL implementiert wird. Dieses Objekt erfasst den Zustand einer SSL-Verbindung, bietet aber keine eigene Netzwerk-IO. IO muss über separate "BIO"-Objekte durchgeführt werden, die die IO-Abstraktionsschicht von OpenSSL darstellen.

Diese Klasse hat keinen öffentlichen Konstruktor. Eine Instanz von SSLObject muss mit der Methode wrap_bio() erstellt werden. Diese Methode erstellt die Instanz von SSLObject und bindet sie an ein Paar von BIOs. Das *eingehende* BIO wird verwendet, um Daten von Python an die SSL-Protokollinstanz zu übergeben, während das *ausgehende* BIO verwendet wird, um Daten in die entgegengesetzte Richtung zu übergeben.

Die folgenden Methoden sind verfügbar

Im Vergleich zu SSLSocket fehlen diesem Objekt folgende Funktionen

Jede Form von Netzwerk-IO; recv() und send() lesen und schreiben nur in die zugrunde liegenden MemoryBIO-Puffer.
Es gibt keine do_handshake_on_connect-Mechanismen. Sie müssen immer manuell do_handshake() aufrufen, um den Handshake zu starten.
Es gibt keine Behandlung von suppress_ragged_eofs. Alle End-of-File-Bedingungen, die gegen das Protokoll verstoßen, werden über die Ausnahme SSLEOFError gemeldet.
Der Aufruf der Methode unwrap() gibt nichts zurück, im Gegensatz zu einem SSL-Socket, bei dem er den zugrunde liegenden Socket zurückgibt.
Der an SSLContext.set_servername_callback() übergebene Callback server_name_callback erhält als ersten Parameter eine Instanz von SSLObject anstelle einer Instanz von SSLSocket.

Einige Hinweise zur Verwendung von SSLObject

Alle I/O-Operationen auf einem SSLObject sind nicht-blockierend. Das bedeutet, dass beispielsweise read() eine SSLWantReadError auslöst, wenn mehr Daten benötigt werden, als im eingehenden BIO verfügbar sind.

Geändert in Version 3.7: SSLObject-Instanzen müssen mit wrap_bio() erstellt werden. In früheren Versionen war es möglich, Instanzen direkt zu erstellen. Dies wurde nie dokumentiert oder offiziell unterstützt.

Ein SSLObject kommuniziert mit der Außenwelt über Speicherpuffer. Die Klasse MemoryBIO stellt einen Speicherpuffer zur Verfügung, der für diesen Zweck verwendet werden kann. Er wickelt ein OpenSSL-Speicher-BIO (Basic IO)-Objekt ein

class ssl.MemoryBIO¶

Ein Speicherpuffer, der verwendet werden kann, um Daten zwischen Python und einer SSL-Protokollinstanz zu übergeben.

pending¶: Gibt die Anzahl der Bytes zurück, die sich derzeit im Speicherpuffer befinden.

eof¶: Ein boolescher Wert, der angibt, ob sich das Speicher-BIO derzeit an der End-of-File-Position befindet.

read(n=-1, /)¶: Liest bis zu n Bytes aus dem Speicherpuffer. Wenn n nicht angegeben oder negativ ist, werden alle Bytes zurückgegeben.

write(buf, /)¶

Schreibt die Bytes aus buf in das Speicher-BIO. Das Argument buf muss ein Objekt sein, das das Pufferprotokoll unterstützt.

Der Rückgabewert ist die Anzahl der geschriebenen Bytes, die immer der Länge von buf entspricht.

write_eof()¶: Schreibt eine EOF-Markierung in das Speicher-BIO. Nach dem Aufruf dieser Methode ist es illegal, write() aufzurufen. Das Attribut eof wird wahr, nachdem alle Daten, die sich derzeit im Puffer befinden, gelesen wurden.

SSL-Sitzung¶

Hinzugefügt in Version 3.6.

class ssl.SSLSession¶

Sitzungsobjekt, das von session verwendet wird.

id¶

time¶

timeout¶

ticket_lifetime_hint¶

has_ticket¶

Sicherheitsüberlegungen¶

Beste Standardwerte¶

Für die **Client-Nutzung** wird dringend empfohlen, wenn Sie keine speziellen Anforderungen an Ihre Sicherheitspolitik haben, die Funktion create_default_context() zu verwenden, um Ihren SSL-Kontext zu erstellen. Sie lädt die vertrauenswürdigen CA-Zertifikate des Systems, aktiviert die Zertifikatsvalidierung und die Hostnamenprüfung und versucht, angemessen sichere Protokoll- und Cipher-Einstellungen auszuwählen.

Beispielsweise, wie Sie die Klasse smtplib.SMTP verwenden würden, um eine vertrauenswürdige, sichere Verbindung zu einem SMTP-Server herzustellen

>>> import ssl, smtplib
>>> smtp = smtplib.SMTP("mail.python.org", port=587)
>>> context = ssl.create_default_context()
>>> smtp.starttls(context=context)
(220, b'2.0.0 Ready to start TLS')

Wenn für die Verbindung ein Client-Zertifikat benötigt wird, kann es mit SSLContext.load_cert_chain() hinzugefügt werden.

Wenn Sie hingegen den SSL-Kontext erstellen, indem Sie den Konstruktor SSLContext selbst aufrufen, sind standardmäßig keine Zertifikatsvalidierung oder Hostnamenprüfung aktiviert. Wenn Sie dies tun, lesen Sie bitte die folgenden Absätze, um ein gutes Sicherheitsniveau zu erreichen.

Manuelle Einstellungen¶

Zertifikate überprüfen¶

Beim direkten Aufruf des Konstruktors SSLContext ist CERT_NONE der Standard. Da die Gegenseite nicht authentifiziert wird, kann dies unsicher sein, insbesondere im Client-Modus, wo Sie meistens die Authentizität des Servers, mit dem Sie sprechen, sicherstellen möchten. Daher wird im Client-Modus dringend empfohlen, CERT_REQUIRED zu verwenden. Dies allein reicht jedoch nicht aus; Sie müssen auch überprüfen, ob das Serverzertifikat, das durch Aufrufen von SSLSocket.getpeercert() abgerufen werden kann, dem gewünschten Dienst entspricht. Für viele Protokolle und Anwendungen kann der Dienst durch den Hostnamen identifiziert werden. Diese gängige Prüfung wird automatisch durchgeführt, wenn SSLContext.check_hostname aktiviert ist.

Geändert in Version 3.7: Die Hostnamenabgleichung wird jetzt von OpenSSL durchgeführt. Python verwendet nicht mehr match_hostname().

Im Servermodus müssen Sie, wenn Sie Ihre Clients über die SSL-Schicht authentifizieren möchten (anstatt einen höherstufigen Authentifizierungsmechanismus zu verwenden), ebenfalls CERT_REQUIRED angeben und analog das Client-Zertifikat überprüfen.

Protokollversionen¶

SSL-Versionen 2 und 3 gelten als unsicher und sind daher gefährlich in der Anwendung. Wenn Sie maximale Kompatibilität zwischen Clients und Servern wünschen, wird empfohlen, PROTOCOL_TLS_CLIENT oder PROTOCOL_TLS_SERVER als Protokollversion zu verwenden. SSLv2 und SSLv3 sind standardmäßig deaktiviert.

>>> client_context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
>>> client_context.minimum_version = ssl.TLSVersion.TLSv1_3
>>> client_context.maximum_version = ssl.TLSVersion.TLSv1_3

Der oben erstellte SSL-Kontext erlaubt nur Verbindungen zu einem Server mit TLSv1.3 und höher (sofern von Ihrem System unterstützt). PROTOCOL_TLS_CLIENT impliziert standardmäßig die Zertifikatsvalidierung und Hostnamenprüfung. Sie müssen Zertifikate in den Kontext laden.

Cipher-Auswahl¶

Wenn Sie erweiterte Sicherheitsanforderungen haben, ist eine Feinabstimmung der Cipher, die bei der Aushandlung einer SSL-Sitzung aktiviert sind, über die Methode SSLContext.set_ciphers() möglich. Ab Python 3.2.3 deaktiviert das ssl-Modul bestimmte schwache Cipher standardmäßig, aber Sie möchten die Cipher-Auswahl möglicherweise weiter einschränken. Lesen Sie unbedingt die Dokumentation von OpenSSL zum Format der Cipher-Listen. Wenn Sie überprüfen möchten, welche Cipher von einer gegebenen Cipher-Liste aktiviert sind, verwenden Sie SSLContext.get_ciphers() oder den Befehl openssl ciphers auf Ihrem System.

Mehrprozessanwendung¶

Wenn Sie dieses Modul als Teil einer Mehrprozessanwendung verwenden (z. B. mit den Modulen multiprocessing oder concurrent.futures), beachten Sie, dass der interne Zufallszahlengenerator von OpenSSL mit geforkten Prozessen nicht richtig umgeht. Anwendungen müssen den PRNG-Zustand des Elternprozesses ändern, wenn sie SSL-Funktionen mit os.fork() verwenden. Jeder erfolgreiche Aufruf von RAND_add() oder RAND_bytes() ist ausreichend.

TLS 1.3¶

Hinzugefügt in Version 3.7.

Das TLS 1.3-Protokoll verhält sich etwas anders als frühere Versionen von TLS/SSL. Einige neue TLS 1.3-Funktionen sind noch nicht verfügbar.

TLS 1.3 verwendet einen getrennten Satz von Cipher-Suiten. Alle AES-GCM und ChaCha20 Cipher-Suiten sind standardmäßig aktiviert. Die Methode SSLContext.set_ciphers() kann derzeit keine TLS 1.3-Cipher aktivieren oder deaktivieren, aber SSLContext.get_ciphers() gibt sie zurück.
Sitzungstickets werden nicht mehr als Teil des anfänglichen Handshakes gesendet und anders behandelt. SSLSocket.session und SSLSession sind nicht mit TLS 1.3 kompatibel.
Clientseitige Zertifikate werden während des anfänglichen Handshakes nicht mehr verifiziert. Ein Server kann jederzeit ein Zertifikat anfordern. Clients verarbeiten Zertifikatanfragen, während sie Anwendungsdaten an den Server senden oder von ihm empfangen.
TLS 1.3-Funktionen wie Early Data, verzögerte TLS-Client-Zertifikatanfrage, Konfiguration von Signatur-Algorithmen und Rekeying werden noch nicht unterstützt.

Siehe auch

Klasse socket.socket: Dokumentation der zugrunde liegenden Klasse socket
SSL/TLS starke Verschlüsselung: Eine Einführung: Einführung aus der Dokumentation des Apache HTTP Servers
RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management: Steve Kent
RFC 4086: Randomness Requirements for Security: Donald E., Jeffrey I. Schiller
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile: D. Cooper
RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2: T. Dierks et. al.
RFC 6066: Transport Layer Security (TLS) Extensions: D. Eastlake
IANA TLS: Transport Layer Security (TLS) Parameters: IANA
RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): IETF
Mozilla's Server Side TLS Recommendations: Mozilla

`ssl` — TLS/SSL-Wrapper für Socket-Objekte¶

Funktionen, Konstanten und Ausnahmen¶

Socket-Erstellung¶

Kontext-Erstellung¶

Ausnahmen¶

Zufallsgenerierung¶

Zertifikatsbehandlung¶

Konstanten¶

SSL Sockets¶

SSL-Kontexte¶

Zertifikate¶

Zertifikatsketten¶

CA-Zertifikate¶

Kombinierter Schlüssel und Zertifikat¶

Selbstsignierte Zertifikate¶

Beispiele¶

SSL-Unterstützung testen¶

Clientseitiger Betrieb¶

Serverseitiger Betrieb¶

Hinweise zu Nicht-Blockierenden Sockets¶

Unterstützung für Memory BIOs¶

SSL-Sitzung¶

Sicherheitsüberlegungen¶

Beste Standardwerte¶

Manuelle Einstellungen¶

Zertifikate überprüfen¶

Protokollversionen¶

Cipher-Auswahl¶

Mehrprozessanwendung¶

TLS 1.3¶

Inhaltsverzeichnis

Vorheriges Thema

Nächstes Thema

Diese Seite

ssl — TLS/SSL-Wrapper für Socket-Objekte¶

Funktionen, Konstanten und Ausnahmen¶

Socket-Erstellung¶

Kontext-Erstellung¶

Ausnahmen¶

Zufallsgenerierung¶

Zertifikatsbehandlung¶

Konstanten¶

SSL Sockets¶

SSL-Kontexte¶

Zertifikate¶

Zertifikatsketten¶

CA-Zertifikate¶

Kombinierter Schlüssel und Zertifikat¶

Selbstsignierte Zertifikate¶

Beispiele¶

SSL-Unterstützung testen¶

Clientseitiger Betrieb¶

Serverseitiger Betrieb¶

Hinweise zu Nicht-Blockierenden Sockets¶

Unterstützung für Memory BIOs¶

SSL-Sitzung¶

Sicherheitsüberlegungen¶

Beste Standardwerte¶

Manuelle Einstellungen¶

Zertifikate überprüfen¶

Protokollversionen¶

Cipher-Auswahl¶

Mehrprozessanwendung¶

TLS 1.3¶

`ssl` — TLS/SSL-Wrapper für Socket-Objekte¶