Ich hoste eine ASP.NET-Website mit Wildcard-SSL-Zertifikat auf IIS/Windows 2008R2. Chrome funktioniert zwar problemlos mit meiner Website und zeigt bei der https-Verbindung ein grünes Schloss an, aber in den https-Details wird „veraltete Kryptografie“ erwähnt:
Ich gehe davon aus, dass dies an SHA1 liegt, was im selben Fenster auch von Chrome erwähnt wird.
Laut dem SSL-Zertifikatsprüfer von Digicert sollte jedoch SHA256 verwendet werden:
Jetzt bin ich mir nicht sicher, was los ist und wie ich dieses Problem beheben kann. Es scheint, dassdieser Blog-Beitragbeschreibt einen Workaround für dieses Problem, aber der Workaround scheint so obskur (1. Schritt: OpenSSL installieren?), dass ich mir nicht vorstellen kann, dass dies die offizielle Vorgehensweise unter Windows 2008 R2 ist.
Wie muss ich vorgehen, um die SSL-Zertifikatwarnung loszuwerden?
Bearbeiten:Nach dem Auftragen derSkriptAuf Empfehlung von Grant wurde mein SSLabs von C auf A verbessert und Chrome verwendet TLS 1.2 statt 1.0. Die Warnung „veraltete Kryptografie“ ist jedoch immer noch vorhanden.
Antwort1
Das Problem wird nicht durch SHA verursacht, sondern durch TLS 1.0.
Der SSL Labs-Berichtfür Ihre Domain erzählt die ganze Geschichte. Ihr Server unterstützt nur TLS 1.0, nicht 1.1 oder 1.2. Darüber hinaus unterstützt er immer noch veraltete Chiffren wie RC4 und unterstützt keine perfekte Vorwärtsgeheimhaltung.
Eine Optimierung des IIS zur Verbesserung der Sicherheit ist durchaus möglich, manuell jedoch mühsam. Dieses wunderbare Drehbuch, geschrieben von Alexander Hass, legt eine Reihe von Registrierungseinstellungen fest, um alte, unsichere Verschlüsselungsmethoden für IIS7.5 und IIS8 zu deaktivieren.
Starten Sie den Server nach dem Ausführen des Skripts neu. Sie sollten dann auf SSLLabs die Bewertung A erhalten und in Chrome keine Warnungen mehr angezeigt bekommen.
Antwort2
Ich teste dies auf einem neuen 2012 R2 Server, bei der Anwendung derAlexander Hass Drehbuch(AH-Script), ich bekomme immer noch die veraltete Kryptographie:
Mein Chrome 43 unterstützt die folgenden Verschlüsselungssammlungen:
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[CC14] TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
[CC13] TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[CC15] TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[0035] TLS_RSA_AES_256_SHA
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Der verwendete Wert ist also: [C013], ziemlich weit unten. Es scheint, dass Chrome SHA256 und GCM gegenüber CBC bevorzugt.
Ich habe das AH-Skript genommen und [009E] (3. von oben) zur Liste der Verschlüsselungssammlungen hinzugefügt. Nach dem Neustart erhalte ich jetzt:
Ich habe versucht, die beiden oberen [C08B] und [C02F] zum Laufen zu bringen, aber es hat nicht geklappt.
Indem ich das Skript korrigierte und ausführte, erhielt ich ein modern cryptography.
Ich habe eine der vorhandenen Chiffren entfernt, da die Länge dieser Zeichenfolge begrenzt ist. Der Anfang meiner Zeichenfolge sieht jetzt folgendermaßen aus:
$cipherSuitesOrder = @(
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256',
'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256',
Bearbeiten:Ich habe dies gerade auf sslLabs.com getestet und die Verwendung TLS_DHE_RSA_WITH_AES_128_GCM_SHA256gibt mir einen B, niedriger als den von , den Aich vorher hatte.
Dieser Server unterstützt schwache Diffie-Hellman (DH)-Schlüsselaustauschparameter. Note auf B begrenzt.
Vielleicht möchten Sie es also nicht verwenden. Warum Chrome es so hoch bewertet, weiß ich nicht?
Antwort3
Die Meldung „veraltete Kryptographie“ in Chrome liegt daran, dass der Server schwache Diffie-Hellman (DH)-Schlüsselaustausche unterstützt. Genauer gesagt ist dies dokumentiert in derHTTP/2-Spezifikation auf der Cipher Suite Black List.
Wenn Sie diePowerShell-Skript von Alexander Hass(aus der aktuellen akzeptierten Antwort), dannEs enthält diese Chiffren, dieauf der schwarzen Liste:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Wenn Sie sich dieAzure App Service verwendet die folgende Verschlüsselungssammlungsreihenfolge:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
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
Dies führt zu einer A-Bewertung in Qualys SSL Labs (Juli 2016) und unterstützt Forward Secrecy für die meisten gängigen Browser.
Ich habe das Chrome-Problem gefunden, weil auf meinem lokalen IIS Express unter Windows 10 die Fehlermeldung ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYin Chrome 51 mit den auf meinem System konfigurierten, auf die schwarze Liste gesetzten Verschlüsselungssammlungen zurückgegeben wurde.