Freigeben über

Konfigurieren von TLS 1.3

  • Artikel

Gilt für: SQL Server 2022 (16.x) und höhere Versionen

In diesem Artikel wird Folgendes erläutert:

  1. Wie Sie eine Instanz von SQL Server 2022 (16.x) für die Verwendung von Transport Layer Security (TLS) 1.3 und TLS 1.2 konfigurieren
  2. Wie Sie überprüfen, ob die Protokolle einsatzfähig sind
  3. Wie Sie ältere, unsichere Protokolle deaktivieren, einschließlich TLS 1.0 und 1.1

Anforderungen

Die TLS 1.3-Unterstützung in SQL Server 2022 (16.x) erfordert Folgendes:

  • Windows Server 2022
  • SQL Server 2022 (16.x) mit kumulativem Update 1 oder höher
  • Die SQL Server-Instanz verwendet TCP/IP als Netzwerkprotokoll
  • Ein gültiges X.509-Serverzertifikat, das zusammen mit seinem privaten Schlüssel installiert ist

Wichtig

In diesem Dokument wird davon ausgegangen, dass Ihre Anforderungen kurzfristig sowohl TLS 1.3 als auch TLS 1.2 und nur TLS 1.3 langfristig umfassen.

SQL Server und TLS

SQL Server führt selbst keine TLS-Vorgänge aus. Diese Arbeit wird von Windows mit Hilfe von Schannel SSP ausgeführt. Schannel ist ein Security Support Provider (SSP), der Microsofts Implementierung von Internet-Standard-Sicherheitsprotokollen wie TLS enthält und verfügbar macht. Schannel ist für Windows, was OpenSSL für Linux ist.

Das Konfigurieren von TLS für SQL Server erfordert die Konfiguration von TLS für Windows.

Mit SQL Server 2022 (16.x) auf Windows Server 2022 unterstützt SQL Server TLS 1.0, 1.1, 1.2 und 1.3. Um das zu überprüfen, verwenden Sie bitte .NET-Code, der in GitHub unter TlsTest verfügbar ist. Die Ausgabe dieses Tools sieht wie folgt aus:

Trying Ssl2
Authentication failed, see inner exception.
Exception: The client and server cannot communicate, because they do not possess a common algorithm.
Trying Ssl3
Authentication failed, see inner exception.
Exception: The client and server cannot communicate, because they do not possess a common algorithm.
Trying Tls
Tls using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Trying Tls11
Tls11 using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Trying Tls12
Tls12 using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Trying Tls13
Tls13 using TLS_AES_256_GCM_SHA384

Konfigurieren von Windows für die ausschließliche Verwendung von TLS 1.2 und TLS 1.3

Windows verfügt über eine Reihe von Registrierungsschlüsseln unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, die TLS-Protokollversionen sowie Verschlüsselungssammlungen steuern. Für dieses Szenario sind nur die Protokollversionen von Bedeutung, die Server betreffen, da die SQL Server-Instanz als Server fungiert.

Das folgende PowerShell-Skript aktualisiert die Registrierung, um TLS 1.0 und TLS 1.1 zu aktivieren oder zu deaktivieren, wenn es von Servern genutzt wird:

Warnung

Bevor Sie fortfahren, sichern Sie bitte die Registrierung. So können Sie die Registrierung später bei Bedarf wiederherstellen.

# Learn more at https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings?tabs=diffie-hellman
Set-StrictMode -Version Latest

$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\'
$protocols = [ordered]@{
    "SSL 2.0" = $false
    "SSL 3.0" = $false
    "TLS 1.0" = $false
    "TLS 1.1" = $false
    "TLS 1.2" = $true
    "TLS 1.3" = $true
}

foreach ($version in $protocols.Keys) {

    $enabledValue = $protocols[$version]
    $path = $base + $version + '\Server'

    New-Item $path -Force | Out-Null
    New-ItemProperty -Path $path `
                     -Name 'Enabled' `
                     -Value $enabledValue `
                     -PropertyType 'DWord' `
                     -Force | Out-Null
                     
    Write-Host "$version is $enabledValue."
}

Dieser Code ist auf GitHub verfügbar.

Nachdem Sie dieses Skript ausgeführt haben, starten Sie den SQL Serverprozess neu, damit die neuen TLS-Einstellungen wirksam werden. Wenn Sie nun den Code ausführen, der am Anfang des Artikels erwähnt wurde, erhalten Sie Folgendes zurück:

Trying Ssl2
Authentication failed, see inner exception.
Exception: The client and server cannot communicate, because they do not possess a common algorithm.
Trying Ssl3
Authentication failed, see inner exception.
Exception: The client and server cannot communicate, because they do not possess a common algorithm.
Trying Tls
Received an unexpected EOF    or 0 bytes from the transport stream.
Exception:
Trying Tls11
Received an unexpected EOF or 0 bytes from the transport stream.
Exception:
Trying Tls12
Tls12 using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Trying Tls13
Tls13 using TLS_AES_256_GCM_SHA384

Beachten Sie, dass SSL 2.0, SSL 3.0, TLS 1.0 und TLS 1.1 alle nicht verbunden werden können. Bei TLS 1.2 und TLS 1.3 kommt die Verbindung hingegen zustande.

Nach dem Registrierungsupdate lassen Windows und diese Instanz von SQL Server nur noch TLS 1.2- und TLS 1.3-Verbindungen zu. Später, wenn mehr Clients TLS 1.3 unterstützen, können Sie auch TLS 1.2 deaktivieren.

Konfigurieren der SQL Server-Instanz, um strenge Verschlüsselung zu erzwingen

Der letzte Schritt besteht darin, festzulegen, dass die Instanz Force Strict Encryption verwenden muss. Bei Force Strict Encryption verwendet die SQL-Instanz eine unterstützte Version des Tabular Data Stream (TDS 8.0 oder höher).

Verwenden Sie den SQL Server-Konfigurations-Manager, um diese Einstellung festzulegen.

  1. Erweitern Sie SQL Server-Netzwerkkonfiguration.

  2. Klicken Sie mit der rechten Maustaste auf Protokolle für <instance name> und dann auf Eigenschaften

    Ein Name der Standardinstanz lautet MSSQLSERVER.

  3. Setzen Sie auf der Registerkarte Flags „Strenge Verschlüsselung erzwingen“ auf „Ja“.

    Screenshot des Benutzeroberflächensteuerelements für SQL Server-Konfigurations-Manager, Dialogfeld „Protokolle konfigurieren“.

Überprüfen der Sicherheit

In diesem Abschnitt wird die Verwendung von Wireshark, OpenSSL und Nmap zum Überprüfen der Verschlüsselung gezeigt.

WireShark

Sie können Netzwerk-Sniffer verwenden, um die TLS-Protokollversion und die vereinbarte Verschlüsselungssuite zu bestimmen. Möglicherweise finden Sie einige Daten verwirrend. Sehen Sie sich das nachstehende Bildschirmfoto von Wireshark an. Es zeigt, dass das Paket eine TLS-v1.3-Datensatzebene ist, die Protokollversion jedoch TLS 1.2 und die Handshake-Protokollversion ebenfalls TLS 1.2. Das alles ist Teil der TLS 1.2-Spezifikation, ist zu erwarten und richtig. Die vereinbarte Protokollversion befindet sich im Abschnitt „Erweiterungen“, und wie Sie sehen können, sind die supported_versions TLS 1.3.

Screenshot zu den Abschnitten „TLS-Erweiterung“.

OpenSSL

Sie können die vereinbarten TLS-Informationen auch über openssl ermitteln.

Verwenden Sie den folgenden -Befehl:

openssl s_client 127.0.0.1:1433

Der Befehl gibt Ergebnisse ähnlich den folgenden zurück:

Post-Handshake New Session Ticket arrived:
SSL-Session:
   Protocol   : TLSv1.3
   Cipher     : TLS_AES_256_GCM_SHA384
   Session-ID : 516D56D99088BCDE1 <snip> 098EDB1A
   Session-ID-ctx:
   Resumption PSD: B2B9CB92B59aa1 <snip> BD824CBA
   PSK identity: None

Nmap

Die aktuelle Version von Nmap, Version 7.94, scheint TLS 1.3 nicht zu erkennen, wenn Folgendes verwendet wird:

nmap -sV --script ssl-enum-ciphers -p 1433 127.0.0.1.

Zugehöriger Inhalt