Alternativen

Mangels klarer Upstream-Anleitung und Empfehlungen werden kommerzielle Redistributoren weiterhin ihre eigenen Designentscheidungen im Interesse ihrer Kunden treffen. Die wichtigsten verfügbaren Ansätze sind

• Weiterhin auf neuen Python 2.7.x Releases basieren und keine zusätzliche Unterstützung über die in PEP 476 definierten Mechanismen hinaus für die Migration von nicht überprüften zu überprüften Hostnamen in Standardbibliotheks-HTTPS-Clients bieten
• Die Verfügbarkeit der Änderungen bei der Standardhandhabung von HTTPS-Verbindungen an die Aktualisierung von Python 2 auf Python 3 koppeln
• Für Linux-Distributionsanbieter die Verfügbarkeit der Änderungen bei der Standardhandhabung von HTTPS-Verbindungen an die Aktualisierung auf eine neue Betriebssystemversion koppeln
• Implementieren einer oder beider in diesem PEP beschriebenen Backport-Vorschläge, unabhängig vom formalen Status des PEP

Feature-Erkennung

Das Marker-Attribut im ssl-Modul im Zusammenhang mit diesem Feature ist die Funktion ssl._https_verify_certificates selbst.

Spezifikation

Die Funktion ssl._https_verify_certificates funktioniert wie folgt:

def _https_verify_certificates(enable=True):
    """Verify server HTTPS certificates by default?"""
    global _create_default_https_context
    if enable:
        _create_default_https_context = create_default_context
    else:
        _create_default_https_context = _create_unverified_context

Wenn sie ohne Argumente aufgerufen wird oder wenn enable auf einen wahren Wert gesetzt ist, überprüfen die Client-Module der Standardbibliothek anschließend standardmäßig HTTPS-Zertifikate, andernfalls überspringen sie die Überprüfung.

Wenn sie mit enable auf einen falschen Wert gesetzt aufgerufen wird, überspringen die Client-Module der Standardbibliothek anschließend standardmäßig die Überprüfung von HTTPS-Zertifikaten.

Sicherheitsüberlegungen

Die Einbeziehung dieses Features ermöglicht es sicherheitskritischen Anwendungen, den folgenden vorwärtskompatiblen Ausschnitt in ihren Code aufzunehmen:

if hasattr(ssl, "_https_verify_certificates"):
    ssl._https_verify_certificates()

Einige Entwickler können sich auch entscheiden, die Zertifikatprüfung mittels ssl._https_verify_certificates(enable=False) zu deaktivieren. Dies führt keine größeren neuen Sicherheitsprobleme ein, da das Monkeypatching der betroffenen internen APIs bereits möglich war.

Feature-Erkennung

Das Marker-Attribut im ssl-Modul im Zusammenhang mit diesem Feature ist

• das Attribut ssl._https_verify_envvar, das den Namen der Umgebungsvariable angibt, die das Standardverhalten beeinflusst.

Dies macht nicht nur die Erkennung der Anwesenheit (oder Abwesenheit) der Fähigkeit einfach, sondern ermöglicht auch die programmatische Ermittlung des relevanten Umgebungsnominalnamens.

Spezifikation

Anstatt immer standardmäßig ssl.create_default_context zu verwenden, wird das ssl-Modul wie folgt geändert:

• liest die Umgebungsvariable PYTHONHTTPSVERIFY, wenn das Modul zum ersten Mal in einen Python-Prozess importiert wird.
• setzt die Funktion ssl._create_default_https_context auf einen Alias für ssl._create_unverified_context, wenn diese Umgebungsvariable vorhanden und auf '0' gesetzt ist.
• andernfalls setzt die Funktion ssl._create_default_https_context auf einen Alias für ssl.create_default_context wie üblich.

Beispielhafte Implementierung

_https_verify_envvar = 'PYTHONHTTPSVERIFY'

def _get_https_context_factory():
    if not sys.flags.ignore_environment:
        config_setting = os.environ.get(_https_verify_envvar)
        if config_setting == '0':
            return _create_unverified_context
    return create_default_context

_create_default_https_context = _get_https_context_factory()

Sicherheitsüberlegungen

Im Vergleich zum Verhalten in Python 3.4.3+ und Python 2.7.9->2.7.11 führt dieser Ansatz einen neuen Downgrade-Angriff auf die standardmäßigen Sicherheitseinstellungen ein, der potenziell einem hinreichend entschlossenen Angreifer ermöglicht, Python auf das Standardverhalten von CPython 2.7.8 und früheren Versionen zurückzusetzen.

Diese leichte Erhöhung der verfügbaren Angriffsfläche ist ein Hauptgrund dafür, dass

• sicherheitskritische Anwendungen weiterhin ihren eigenen SSL-Kontext definieren sollten.
• die in diesem PEP beschriebenen Migrationstools nicht in Python 3 integriert werden.

Es ist jedoch auch erwähnenswert, dass die Durchführung eines solchen Angriffs die Fähigkeit erfordert, die Ausführungsumgebung eines Python-Prozesses vor dem Import des ssl-Moduls zu modifizieren. In Kombination mit der Möglichkeit, auf beliebige Teile des Dateisystems zu schreiben (z. B. auf /tmp), könnte ein Angreifer mit solchem Zugriff bereits das Verhalten der zugrunde liegenden OpenSSL-Implementierung, des dynamischen Linkers und anderer potenziell sicherheitskritischer Komponenten modifizieren.

Interaktion mit Python-virtuellen Umgebungen

Die Standardeinstellung wird direkt aus der Prozessumgebung gelesen und funktioniert daher unabhängig davon, ob der Interpreter in einer aktivierten Python-virtuellen Umgebung ausgeführt wird oder nicht.

Feature-Erkennung

Es gibt kein spezifisches Attribut, das anzeigt, dass diese Situation zutrifft. Stattdessen wird sie durch das Vorhandensein der Attribute ssl._https_verify_certificates und ssl._https_verify_envvar in einer Python-Version angezeigt, die nominell älter als Python 2.7.12 ist.

Spezifikation

Die Implementierung dieses Backports beinhaltet das Backporting der Änderungen in PEP 466, 476 und diesem PEP, mit der folgenden Änderung an der Handhabung der Umgebungsvariable PYTHONHTTPSVERIFY im ssl-Modul:

• liest die Umgebungsvariable PYTHONHTTPSVERIFY, wenn das Modul zum ersten Mal in einen Python-Prozess importiert wird.
• setzt die Funktion ssl._create_default_https_context auf einen Alias für ssl.create_default_context, wenn diese Umgebungsvariable vorhanden und auf einen Wert ungleich '0' gesetzt ist.
• andernfalls setzt die Funktion ssl._create_default_https_context auf einen Alias für ssl._create_unverified_context.

Beispielhafte Implementierung

_https_verify_envvar = 'PYTHONHTTPSVERIFY'

def _get_https_context_factory():
    if not sys.flags.ignore_environment:
        config_setting = os.environ.get(_https_verify_envvar)
        if config_setting != '0':
            return create_default_context
    return _create_unverified_context

_create_default_https_context = _get_https_context_factory()

def _disable_https_default_verification():
    """Skip verification of HTTPS certificates by default"""
    global _create_default_https_context
    _create_default_https_context = _create_unverified_context

Sicherheitsüberlegungen

Diese Änderung wäre ein striktes Sicherheitsupgrade für jede Python-Version, die standardmäßig das Überspringen der Zertifikatsvalidierung in Standardbibliotheks-HTTPS-Clients verwendet. Die zu berücksichtigenden technischen Kompromisse beziehen sich hauptsächlich auf das Ausmaß des ebenfalls erforderlichen Backports von PEP 466 und nicht auf sicherheitsrelevante Aspekte.

Interaktion mit Python-virtuellen Umgebungen

Die Standardeinstellung wird direkt aus der Prozessumgebung gelesen und funktioniert daher unabhängig davon, ob der Interpreter in einer aktivierten Python-virtuellen Umgebung ausgeführt wird oder nicht.

Feature-Erkennung

Das Marker-Attribut im ssl-Modul im Zusammenhang mit diesem Feature ist

_cert_verification_config = '<path to configuration file>'

Dies macht nicht nur die Erkennung der Anwesenheit (oder Abwesenheit) der Fähigkeit einfach, sondern ermöglicht auch die programmatische Ermittlung des relevanten Konfigurationsdateinamens.

Empfohlene Änderungen an der Python-Standardbibliothek

Der empfohlene Ansatz für das Backporting der PEP 476-Änderungen auf eine frühere Point-Release-Version ist die Implementierung der folgenden Änderungen im Vergleich zum Standard- PEP 476-Verhalten, das in Python 2.7.9+ implementiert ist:

• modifiziert das ssl-Modul so, dass es eine systemweite Konfigurationsdatei liest, wenn das Modul zum ersten Mal in einen Python-Prozess importiert wird.
• definiert ein plattformseitiges Standardverhalten (entweder Überprüfung oder keine Überprüfung von HTTPS-Zertifikaten), das verwendet wird, wenn diese Konfigurationsdatei nicht vorhanden ist.
• unterstützt die Auswahl zwischen den folgenden drei Betriebsmodi:
  • stellt sicher, dass die HTTPS-Zertifikatsüberprüfung aktiviert ist.
  • stellt sicher, dass die HTTPS-Zertifikatsüberprüfung deaktiviert ist.
  • delegiert die Entscheidung an den Redistributor, der diese Python-Version bereitstellt.
• setzt die Funktion ssl._create_default_https_context auf einen Alias entweder für ssl.create_default_context oder für ssl._create_unverified_context basierend auf der gegebenen Konfigurationseinstellung.

Empfohlener Dateispeicherort

Da die PEP-Autoren keine Anbieter von Langzeitunterstützungsversionen für Windows-, Mac OS X- oder *BSD-Systeme kennen, ist dieser Ansatz derzeit nur spezifisch für Linux-System-Python-Installationen definiert.

Der empfohlene Konfigurationsdateiname auf Linux-Systemen ist /etc/python/cert-verification.cfg.

Die Dateiendung .cfg wird zur Konsistenz mit pyvenv.cfg empfohlen, das vom venv-Modul in Pythons Standardbibliothek verwendet wird.

Empfohlenes Dateiformat

Die Konfigurationsdatei sollte ein ConfigParser-INI-Format mit einer einzigen Sektion namens [https] verwenden, die eine erforderliche Einstellung verify enthält.

Der vorgeschlagene Sektionsname stammt vom „https“-URL-Schema, das an betroffene Client-APIs übergeben wird.

Zulässige Werte für verify sind:

• enable: stellt sicher, dass die HTTPS-Zertifikatsüberprüfung standardmäßig aktiviert ist.
• disable: stellt sicher, dass die HTTPS-Zertifikatsüberprüfung standardmäßig deaktiviert ist.
• platform_default: delegiert die Entscheidung an den Redistributor, der diese spezifische Python-Version bereitstellt.

Wenn die Sektion [https] oder die Einstellung verify fehlt, oder wenn die Einstellung verify auf einen unbekannten Wert gesetzt ist, sollte dies so behandelt werden, als wäre die Konfigurationsdatei nicht vorhanden.

Beispielhafte Implementierung

_cert_verification_config = '/etc/python/cert-verification.cfg'

def _get_https_context_factory():
    # Check for a system-wide override of the default behaviour
    context_factories = {
        'enable': create_default_context,
        'disable': _create_unverified_context,
        'platform_default': _create_unverified_context, # For now :)
    }
    import ConfigParser
    config = ConfigParser.RawConfigParser()
    config.read(_cert_verification_config)
    try:
        verify_mode = config.get('https', 'verify')
    except (ConfigParser.NoSectionError, ConfigParser.NoOptionError):
        verify_mode = 'platform_default'
    default_factory = context_factories.get('platform_default')
    return context_factories.get(verify_mode, default_factory)

_create_default_https_context = _get_https_context_factory()

Sicherheitsüberlegungen

Die spezifischen Empfehlungen für diesen Backporting-Fall sind so konzipiert, dass sie auch für privilegierte, sicherheitskritische Prozesse funktionieren, selbst wenn diese in der folgenden gesperrten Konfiguration ausgeführt werden:

• Ausführung von einem gesperrten, administratorgesteuerten Verzeichnis anstelle eines normalen Benutzerverzeichnisses (verhindert Angriffe zur Privilegieneskalation basierend auf sys.path[0]).
• Ausführung mit dem Schalter -E (verhindert Angriffe zur Privilegieneskalation basierend auf Umgebungsvariablen PYTHON*).
• Ausführung mit dem Schalter -s (verhindert Angriffe zur Privilegieneskalation basierend auf benutzerdefinierten Verzeichnissen).
• Ausführung mit dem Schalter -S (verhindert Angriffe zur Privilegieneskalation basierend auf sitecustomize).

Die Absicht ist, dass der *einzige* Grund, warum die HTTPS-Überprüfung bei Verwendung dieses Ansatzes installationsweit ausgeschaltet werden sollte, darin besteht, dass

• ein Endbenutzer eine vom Redistributor bereitgestellte Version von CPython ausführt, anstatt Upstream CPython direkt auszuführen.
• dieser Redistributor entschieden hat, einen glatteren Migrationspfad zur standardmäßigen HTTPS-Zertifikatsüberprüfung bereitzustellen als das, was vom Upstream-Projekt angeboten wird.
• entweder der Redistributor oder der lokale Infrastrukturadministrator festgestellt hat, dass es angebracht ist, das Standardverhalten vor 2.7.9 beizubehalten (zumindest vorerst).

Die Verwendung einer administratorkontrollierten Konfigurationsdatei anstelle einer Umgebungsvariablen hat den wesentlichen Vorteil, einen glatteren Migrationspfad zu bieten, selbst für Anwendungen, die mit dem Schalter -E ausgeführt werden.

Interaktion mit Python-virtuellen Umgebungen

Diese Einstellung ist nach der Interpreterinstallation abgegrenzt und betrifft alle Python-Prozesse, die diesen Interpreter verwenden, unabhängig davon, ob der Interpreter in einer aktivierten Python-virtuellen Umgebung ausgeführt wird oder nicht.

Ursprünge dieser Empfehlung

Diese Empfehlung basiert auf dem Backporting-Ansatz, der für Red Hat Enterprise Linux 7.2 übernommen wurde, wie in der ursprünglichen Julidraft dieses PEP veröffentlicht und detailliert in diesem KnowledgeBase-Artikel beschrieben. Red Hats Patches zur Implementierung dieses Backports für Python 2.7.5 sind im CentOS Git-Repository zu finden.

Beispielhafte Implementierung

_https_verify_envvar = 'PYTHONHTTPSVERIFY'
_cert_verification_config = '/etc/python/cert-verification.cfg'

def _get_https_context_factory():
    # Check for an environmental override of the default behaviour
    if not sys.flags.ignore_environment:
        config_setting = os.environ.get(_https_verify_envvar)
        if config_setting is not None:
            if config_setting == '0':
                return _create_unverified_context
            return create_default_context

    # Check for a system-wide override of the default behaviour
    context_factories = {
        'enable': create_default_context,
        'disable': _create_unverified_context,
        'platform_default': _create_unverified_context, # For now :)
    }
    import ConfigParser
    config = ConfigParser.RawConfigParser()
    config.read(_cert_verification_config)
    try:
        verify_mode = config.get('https', 'verify')
    except (ConfigParser.NoSectionError, ConfigParser.NoOptionError):
        verify_mode = 'platform_default'
    default_factory = context_factories.get('platform_default')
    return context_factories.get(verify_mode, default_factory)

_create_default_https_context = _get_https_context_factory()