Servus.
Ich nutze den CVE Reporter schon geraume Zeit, allerdings bekomme ich seit Jahresbeginn etwa, immer folgenden Fehler. Es läuft auf einem Windows Server 2016.
Downloading CVE Feed Download failed: An exception was caught: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden.. Failed URI: https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-recent.json.zip
Das Skript läuft, wenn ich es auf meinem Rechner (Windows 11) ausführe, ohne Probleme. Daher denke ich dass über irgendein Windows Update irgendwas speziell beim Windows Server OS reinkam dass diese Verbindung nun verhindert.
Ich habe selbstverständlich sehr intensiv Google benutzt und schon alle möglichen Lösungsvorschläge ausprobiert, aber nicht einer hat funktioniert (z.B. wie die TLS Versionen setzen etc.) und inzwischen bin ich mehr als ratlos.
Hoffe das ihr eine Idee habt.
Gruss Oli
Hast du Martins Hinweis bzgl. der extrem eingeschränkten angebotenen ciphers gelesen? Hat dein ExchangeServer TLS 1.2 aktiv (kannst du mit dem Healt Check Skript prüfen). Und nutzt er die die beiden von nist.gov angeboten?
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Bye
Norbert
Es konnte kein geschützter SSL/TLS-Kanal erstellt werden..
Könnte natürlich auch Proxy oder AV Software mit SSL Inspection usw. sein.
Ja. Da kam ich heute vormittag dazu.
Hab das über IISCrypto nochmal gesetzt. Allerdings haben alle dort drin enthaltenen Cipher Suites mit dem Beginn "TLS_ECDHE_RSA_WITH_AES_" hintendran noch ein "_Pxxx" (xxx für ne dreistellige Zahl).
Übrigens läuft das Skript nicht auf einem Exchange Server, sondern auf einem unserer Diensteserver. Exchange ist ja für das Skript nicht notwendig.
Ich habe es aber zusätzlich nochmal auf dem Exchange ausgeführt nach den ÄNderungen, aber es gibt den gleichen Fehler. Laut Firewall wird nichts geblockt und AV blockt dahingehend auch nichts.
Hab vergessen noch dazuzuschreiben dass ich die beiden angegeben Cipher Suites noch in der Registry unter folgenden Keys nachgetragen habe. Auch hier nach einem Neustart ein Erfolg. Immer noch der gleiche Fehler.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
Normalerweise muss man da aber nix nachtragen, weil Windows 2016 die eben per Default nutzt. Wenn du die also nicht explizit abgeschaltet hast. So oder so wirst du wohl rausfinden müssen, warum dein Exchange eben nicht per TLS so agiert wie dein Windows 11. Ich würd mir an deiner Stelle dazu mal einen neuen 2016 hinstellen und damit probieren. ;)
Falls dein Exchange von extern erreichbar ist, kannst du mittels https://www.ssllabs.com/ rausfinden, welche der aktuell unterstützt (ist zwar die Serverseite, aber ich vermute mal, dass du nicht Client/Server unterschiedlich konfiguriert haben wirst. Ansonsten kannst du natürlich auch nmap nutzen.
Bye
Norbert
@norbertfe Servus.
Nochmal kurz: Es geht nicht um einen Exchange. Das CVE Skript läuft auf einem seperaten Server (Win Server 2016) mit Standard Settings bei den Cipher Suites. Wie bereits geschrieben gab es diese angegeben Cipher Suites, allerdings immer mit einem _Pxxx am Ende (xxx ist ein platzhalter für ne dreitsellige nummer) davon gabs 5 verschiedene.
Das Skript ging von einem Tag auf den anderen nicht mehr. Habe es leider zu spät bemerkt sodass ich auch nicht mehr weiss an welchem Tag das war und welches Update da evtl. vorher instaliert wurde.
Es geht nicht um einen Exchange.
OK, dann wirst du eben einen neuen Win 2016 nehmen und den mal ungepatcht testen. ;)
Also ich habe nun einen neuen Win 2016 aufgesetzt, diesen in die Domäne eingebunden und die IP auf DHCP gelassen damit er eine aus dem Clientnetzwerk bekommt. Mehr nicht, kein Virenscanner drauf und auch keine Patches installiert.
Auch da schlägt das fehl. Jetzt bin ich noch ratloser. Wie gesagt funktionierte das um den Jahreswechsel noch einwandfrei. Das letzte mal lief er am 04.01. Wenn ich ihn auf einem Windows Client ausprobiere gehts ohne probleme
Da mein Testsyxstem ungepatcht ist kann es auch nicht an einem Update liegen. Auf unserer Fortigate sieht die Verbindung zu denen normal aus. Wird laut dem Log nichts geblockt.
Ich habe aber ein kleinen Unterschied in den Firewall Logs bemerkt. Im angehängten Screenshot ist der obere Logeintrag der von meinem Win 11 Client. der untere von dem Win 2016 Testserver. In der spalte Application Name steht bei mir HTTPS.BRWOSER und beim Server SSL obwohl ich auf beiden Geräte das Skript auf dem exakt gleichen Weg ausführe.
Des Weiteren kann ich die Datei die über Powershell heruntergeladen werden soll über den Browser auf dem Server ohne Probleme herunterladen.
Noch eine weitere Info:
Ich denke dass es irgendwas mit dem Windows Server Betriebssystem zu tun haben muss.
Habe das Skript nun in 2 verschiedenen eigenständigen Domänen (eine mit ner FortiGate, die andere mit einer Sophos UTM Firewall) ausgeführt. Zum einen auf Windows Server 2012 R2 und Windows Server 2016 Betriebssystemen. Es geht auf keinem einzigen.
Der Download der Datei, die im Skript über Invoke-WebRequest heruntergeladen wird, kann über den Browser auf dem Server ohne Probleme heruntergeladen werden. Nur in der Powershell gehts nicht.
Würde ich behaupten.
[Net.ServicePointManager]::SecurityProtocol bringt als Ergebnis Tls, Tls11, Tls12, Tls13
Ich hatte auch mal ausprobiert im Skript verschiedene TLS Versionen zu erzwingen mit z.B. [Net.ServicePointManager]::SecurityProtocol = "Tls12"
Hatte auch keinen Effekt. Und wie schon gesagt gings ja Anfang des Jahres noch und da lief das soweit ich mich erinnere auch schon über TLS1.2.
Aktivierte Cipher Suites:
Get-TlsCipherSuite | Format-Table Name
Name
----
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA256
Irgendjemand noch eine Idee? Hat Jemand mal bei sich ausprobiert ob das SKript da geht (im Idealfall ein Win 2016 Server)? Bitte nicht antworten wenn es auf einem Client OS funktioniert hat. Da geht es ja.