Da ich gerade dabei bin meinen Webserver auf nur-HTTPS umzustellen nutze ich natürlich auch den Server-Test von SSL-Labs zur Prüfung der Server-Config.
Dabei ist mir aufgefallen dass wenn man Cipher-Suites mit SHA1 deaktiviert Firefox die Verbindung komplett verweigert - da scheinbar nur Verbindungen mit HMAC-SHA1 zugelassen werden. Schon recht interessant da SHA1 bekanntlich als unsicher gilt. Chrome und der IE11 haben keine Probleme - auch nicht wenn ausschließlich SHA384 angeboten wird.
Deaktiviere ich nun SHA1 so dass nur SHA256 und SHA384 angeboten werden gibt SSL-Labs die Meldung dass es Kompatibilitätsprobleme mit den Referenz-Browsern gibt - klar wenn sich Firefox nur auf SHA1 einlässt.
Ist jemanden ein Grund hierfür bekannt?
Ich mein - es bringt doch nichts wenn ich den Schlüsselaustausch und das Pre-Master hoch absichere wenn die Signatur trotzdem angreifbar ist.
Was mich auch verwundert - auch obwohl SHA256 und SHA384 zur Verfügung stehen wählt Chrome z.B. lieber SHA1 wenn verfügbar - wenn allerdings nur die Wahl zwischen SHA256 und SHA384 bleibt dann plötzlich gleich auf SHA384.
Machen die Browser-Entwickler hier einfach so viel falsch oder werden sie wie z.B. Oracle bei Java dazu gezwungen? Was mich dabei aber mehr verwundert: Warum z.B. darf Google seinen Chrome und Microsoft seinen Edge und IE mit AES256 ausliefern obwohl Oracle für AES256 ein Export-Verbot hat und Standardmäßig nur AES128 anbietet?
ich bin mir nicht ganz sicher, ob ich dein Problem verstehe. Ich biete auf meinem Server keine Cipher Suites ‘mit SHA1’ an (du meinst so etwas wie SHA1+DES ?), und Firefox kommt durch. Du musst ihm natürlich dazu etwas anderes anbieten. Wie sieht dein SSLCipherSuite String denn aus, vielleicht kann man da helfen? Wenn du das hier nicht öffentlich posten möchtest, kann ich dir auch meinen String mal per PN schicken, läuft auf Apache und bekommt bei Qualys 90% Strength ohne Warnung.
Ich orientiere mich da immer an den Paper von https://bettercrypto.org/. Soweit ich weiß hängt es auch von der Reihenfolge im CipherString ab, was jetzt ausgewählt wird.
@inv_zim : Ich denke er meint SHA1 als MAC/Signatur
Nehme ich jetzt die CipherSuites bei denen nur SHA (halt für SHA1) steht raus so dass nur noch SHA256/384 übrigbleiben meldet sich der Fuchs mit dem Fehler er hätte keinen passen Cipher gefunden. Wenn die SHA1 Cipher aktiv sind meldet der FF in den Verbindungsdetails auch nur SHA1 als MAC. Es scheint so als ob kein SHA2 im FF implementiert/aktiviert ist.
Weder der IE11 noch Chrome machen solche Probleme - die laufen auch mit SHA256 oder gar auch nur mit SHA384 während sich Firefox denkt: “Nö! Das ist mir einfach zu sicher. Da kann ja keiner die Signatur fälschen!”
Chrome verhält sich in der Art und Weise sehr merkwürdig dass er, so fern denn aktiv, lieber einen SHA1 Cipher nutzt obwohl auch die SHA2 Cipher verfügbar sind. Nur wenn man ihm SHA1 wegnimmt wird dann plötzlich direkt auf SHA384 gesetzt - SHA256 ist ihm scheinbar egal. So nach dem Motto “Wenn knackbar - dann den, sonst so kompliziert wie möglich!”.
Was der IE11 verwendet lässt sich nicht ermitteln da er diese Infos nicht rausrückt. Der meldet dann lediglich “TLS 1.2, AES mit 256 Bit Verschlüsselung (Hoch); DH mit 4096 Bit Austausch” (lässt sich mir Wireshark anhand der SSL-Pakete sicherlich analysieren).
Jetzt halt die interessante Frage: haut mit meinem FF irgendwas nicht hin, hab ich irgendeine Einstellung übersehen - oder macht Mozilla das bewusst?
Was weiter sehr witzig kommt: sowohl Microsoft als auch Google sind genau wie Oracle und ehemals Sun US-Unternehmen und müssen sich daher an diese US-Crypto-Export-Verbote halten - jedoch liefern M$ und Google mal eben AES256-fähige Browser und ganze Betriebssysteme aus während sich Oracle an AES128 hält. Frage: Ist Oracle als großer Datenbankhersteller einfach nicht groß genug um sich über diese Beschränkungen hinwegzusetzen oder ist da in der zuständigen Abteilung nur jemand zu faul statt den eingeschränkten policy-Files mal die unlimited-Version als default zu setzen?
Und wenn ich auf https://cc.dcsec.uni-hannover.de/ geht, dann bevorzugt mein Chrome schon auch SHA256 als MAC. Mein Firefox hat zwar weniger Ciphers mit SHA256 drinnen, aber nutzt es eben so. Grob gesagt, der ChiperString ist Mist
Der CipherString ist auch nur copy’n’paste ausm Netz - bin für Vorschläge offen.
Aber danke für den Link, denn der zeigt dass hier scheinbar was mit den Browsern so überhaupt nicht passen will.
Hier mal die Specs:
OS: Win7 Ulti x64 SP1 (patch-level irgendwann Anfang Feb 2016 ~ hab mir jetzt nur für diesen Test nicht die Mühe gemacht alles auf den wirklich heutigen Tag zu bringen)
IE 11: 11.0.28 x64
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
RSA-AES256-GCM-SHA384
RSA-AES128-GCM-SHA256
DH-RSA-MISTY1-SHA
DH-DSS-MISTY1-SHA
RSA-AES256-SHA
RSA-AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
DHE-DSS-AES256-SHA256
DH-ANON-MISTY1-SHA
DHE-DSS-AES256-SHA
DHE-DSS-AES128-SHA
RSA-3DES-EDE-SHA
DHE-DSS-3DES-EDE-SHA
RSA-RC4128-SHA
RSA-RC4128-MD5
This connection uses TLSv1.2 with ECDHE-RSA-AES256-SHA384 and a 256 Bit key for encryption.
Chrome 48: 48.0.2564.116 m x64
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA
RSA-AES128-GCM-SHA256
RSA-AES256-SHA
RSA-AES128-SHA
RSA-3DES-EDE-SHA
This connection uses TLSv1.2 with ECDHE-RSA-AES128-GCM-SHA256 and a 128 Bit key for encryption.
Firefox 44: 44.0.2 x64
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
RSA-AES128-SHA
RSA-AES256-SHA
RSA-3DES-EDE-SHA
This connection uses TLSv1.2 with ECDHE-RSA-AES128-GCM-SHA256 and a 128 Bit key for encryption.
Ist eigentlich schon ganz schön schwach was sich diese beiden möchtegern-IE-Konkurrenten hier so in Punkto Sicherheit meinen leisten zu dürfen. Und da sag doch mal wieder einer der IE sei ja so unsicher … hmm - PWNT !
Und bevor jetzt wer auf die Idee kommt mir sagen zu wollen es sei ein Config-Fehler meinerseits - den muss ich leider enttäuschen und gleich mal den Wind aus den Segeln nehmen: es handelt sich hierbei um “stock-setups” an denen config-mäßig nichts manuell bearbeitet wurde.
Die einzige Anmerkung die ich noch habe ist dass ich Kaspersky Internet Security 16 nutze - und ja, auch mit voll installiertem Root-CA - doch die werden hier nicht verwendet - Kaspersky als Fehlerquelle lässt sich hier also ausschließen (und ja: ich hab es testweise deaktiviert).
Was auch sehr interessant ist: obwohl Chrome laut Liste kein SHA384 Cipher anbietet wird dieser, wenn SHA1 deaktiviert, trotzdem genutzt - irgendwas passt da auch nicht ganz zusammen.
Die anderen zwei mit ECDSA-exchange werden also nicht berücksichtigt oder nicht unterstützt.
Und obowohl wie oben gepostet mein Chrome angeblich keinen SHA384-Cipher hat und laut server-test auch nicht kompatibel ist wird eine Verbindung sauber hergestellt - eben so mit meinem IE11 - nur der FF packt es irgendwie nicht und meldet mal wieder den Fehler: kein Cipher gefunden.
Tja, dann bleibt es halt dabei - wenn ein Browser meint “nö, kann ich nich, stell mich selbst aber trotzdem immer wieder als “der Eine” hin” - dann sagt mein Server ganz einfach “nope”.
Hab meinen Cipher-String jetzt auf folgendes gekürzt:
Und bekomm damit bei ssllabs.com ein A+ mit 100/100/90/100. Den 3. Wert KeyExchange würde ich auch auf 100 bekommen wenn ich die ECDHE-Cipher rauswerfe - dann bekomm ich aber ein A- weil kein ForwardSecrecy mehr läuft. Also hier und da trade-offs.
Damit ergibt der Server-Test von SSLLabs.com nun ein A+ mit allen vier Werten von 100%.
Chrome nutzt laut info die ECDHE-Curve (laut ssllabs "ECDH secp384r1 (eq. 7680 bits RSA) "), der IE weiterhin den DHE mit 4096 Bit. Firefox weigert sich weiterhin da ihm halt kein AES128-Cipher zur Verfügung steht bei dem er laut der oben geposteten Liste zumindest noch SHA256 nutzen würde (was ich ihm ja auch nicht mehr gebe).
Auch mein mobile chrome auf meinem Z5 schafft die Verbindung.
Da also drei von vier Browsern die Verbindung herstellen können - und nach einem “externen Test” die “Qualität” auch als “A+ 4x100%” gewertet wird schiebe ich das Problem mal auf den Firefox. Denn selbst Java schafft es, nach Installation der unlimited policy eine Verbindung herzustellen.
Damit hat sich für mich das Thema erledigt und Firefox ist als “Problem” klar identifiziert.
Hmm, Handy auf Android 6 - nun verweigert auch der mobile-Chrome die Verbindung, genau wie Desktop.
W T F ? Warum werden die Cipher-Suites mit SHA256/384 und AES256 rausgenommen / als unsicher behandelt - wohl aber AES128+SHA1 ?=! Was bitte läuft da denn schief?
Hab mal so n bissl Google gefragt und auch eine mögliche Erklärung gefunden: Google empfindet AES128-GCM als sicherer als AES256-CBC. Hat wohl irgendwas mit den dahintersteckenden MAC-Algorithmen zu tun dass wohl in GCM auf SHA2 verzichtet werden kann. Gut, kein Plan was da nun wirklich abgeht - aber nur weil der eine Blockmodus bei kürzerer Blocklänge scheinbar höhere Sicherheit bietet als ein anderer Modus mit längerer Blocklänge - aber merkwürdig ist es schon.
Soweit ich mir das ergooglet habe hat GCM sowohl den Vorteil als Stream-Cipher zu arbeiten (zumindest funz das in Java mit AES/GCM/NoPadding ganz gut mit nem CipherIn/OutputStream) als auch AEAD. Warum man dann aber trotzdem auf 128 begrenzt und dann auch in Kombination nur SHA1 als HMAC anbietet statt das volle Potential mit 256 Bit AES-Schlüssel und SHA2 als HMAC liegt wohl an Dingen wie dieser neuen tollen Idee der Amis nur noch schwache Crypto “die sich leicht knacken oder umgehen lässt” per Gesetzt für legal zu befinden. Auch toll - geh ich halt nicht wegen der Pr0ns selbst in den Knast sondern weil ich sie mit starker Crypto vor Zugriff schütze. Die haben da drüben echt nicht mehr alle Latten am Zaun.
Was dann aber wieder die Frage zulässt: Warum darf es M$ bzw Warum bietet der IE die Cipher an? Da der IE ja fest in Windows verankert ist gehe ich von aus dass auch die genutzten Crypto-Funktionen “public” über die Win-API abgebildet und so durch andere Programme genutzt werden können. Und nur um den letzten minimalen Rest an Performance rauszukitzeln auf Sicherheit zu verzichten geht auch irgendwie entgegen einem der großen Werbepunkte von Chrome und FF das dieses sicherer wären. Und bei heutigen Systemleistungen und Geschwindigkeiten und mitlerweile sogar InstructionSet Erweiterungen dürfte sich für den Otto-normal-User kein merklicher Unterschied ergeben. Wäre IMO zumindest der falsche Ansatz.
Zwar falscher Browser aber gleiches Thema:
Nachdem mein Chrome auf meinem Android6 Smartphone zwischenzeitlich die Verbindung wegen AES256+SHA256/348 komplett verweigerte (vorher wurde immer gewarnt da ich eine alte und unsichere Suite nutze) wird nun anstandslos mit HSTS-preload eine AES256-GCM-SHA384 Verbindung aufgebaut und auch als “modern und sicher” bewertet.
Wow - diese Browserhersteller - witzig wie sich der Status meines Servers so ändern kann obwohl ich an der Config selbst seit dem letzten Post nichts mehr geändert habe.
