Wie hier bereits angedeutet scheint sich im Bereich Windows und TLS1.3 langsam(?) was zu tun?!
Ein Blick auf die in Windows 10 1903 unterstützten TLS Versionen und Cipher macht leider noch nicht viel Hoffnung. Ebenfalls findet sich bei Microsoft nicht wirklich viel zum Thema außer z.B. dieser Blogeintrag oder der ein und andere Forenbeitrag, wann es (endlich) implentiert wird.
Zufällig bin ich in den Microsoft Docs über SecurityProtocolType gestoßen, welcher ab der Dot Net Version 4.8 folgenden Eintrag erhält:
Tls13 – 12288 – Specifies the TLS 1.3 security protocol. The TLS protocol is defined in IETF RFC 8446.
https://docs.microsoft.com/en-us/dotnet/api/system.net.securityprotocoltype?view=netframework-4.8
Nach einer Installation vom .Net Framework 4.8 auf einem Windows Server 2016 bzw. auch auf einem Windows 10 1909 vermeldet die PowerShell nach Eingabe folgender Codezile tatsächlich „Tls13“.
[enum]::GetValues('Net.SecurityProtocolType')
# Output
SystemDefault
Ssl3
Tls
Tls11
Tls12
Tls13
Das Setzen des „TLS 1.3 Registry Keys“ in „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols“ brachte weder auf einem Server (2016 / 2019) noch Client OS in aktueller Version eine Abhilfe.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
Leider scheitern sämtliche Versuche die PowerShell (oder auch das Tool SSLWrapperDemo (Das Zip File enthält die kompilierte EXE. (Wer nicht selber kompilieren möchte.))) per Invoke-WebRequest mit einem TLS1.3-fähigen Webserver zu verbinden. Vermutlich weil mir die passenden Cipher / Cipher Suites noch nicht geläufig sind..
# Ausgeben der derzeigiten Protokolle
[Net.ServicePointManager]::SecurityProtocol
# Output
Tls, Tls11, Tls12
# Nur TLS1.3 erlauben und google.com aufrufen
[Net.ServicePointManager]::SecurityProtocol = 'Tls13'
try{
Invoke-WebRequest -Uri https://www.google.com
} catch{
$_.Exception.Message
$_.Exception.Status
}
# Output :(
Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
SecureChannelFailure
Den bislang ersten Lichtblick gab es dann mit einer Windows 10 Insider Build (2004 19035.1). Nachdem die o.g. Registry Keys gesetzt wurden, war es immerhin möglich mit der SSLWrapperDemo.exe eine TLS 1.3 gesicherte Verbindung unter Windows zu unserem Netscaler bzw. auch zu Google herzustellen – Yay!:
Update: Heute, am 19.07.2020, habe ich mich eher zufällig in die „Internetoptionen“ (inetcpl.cpl) verirrt und dort doch glatt eine kleine Neuerung gefunden: TLS1.3 verwenden (experimentell). Vorweg: Das Abhaken von TLS1.0 bi TLS1.2 ermöglicht leider noch keinen Aufruf von Google oder unseres Citrix ADCs :(.
Hier noch eine kurze Information zum neuen Microsoft Edge auf Chromium Basis. Dieser unterstützt, wie eigentlich alle Chromium-basierten Browser TLS in der Version 1.3.
Update II: Am 20.08.2020 hat Microsoft diesen Blog Beitrag veröffentlicht und dort erklärt, dass ab der Windows 10 Insider Build 20170 TLS 1.3 standardmäßig aktiviert wird. Da ich zuletzt die beiden Hyper-V Hosts in meinem Homelab auf die Windows Server vNext LTSC 2004 Build 20201 aktualisiert habe, konnte ich einen Test im Internet Explorer machen, welcher erfolgreich eine TLS 1.3 Verbindung zu https://www.google.de aufbaute.
Da die VM nicht umsonst „JANs-IIS01“ heißt, habe ich auch gleich testweise einen IIS installiert und ein SSL Binding hinzugefügt. Ohne weitere Anpassungen begrüßte mich dann ebenfalls (serverseitiges) TLS1.3:
Es bleibt dabei: To be continued… (Aber wir nähern uns dem Ende :))
P.S.: „Viel“ Aufwand für wenig etwas Ergebnis. 🙂
Schreibe einen Kommentar