Obsolete Connection Settings

[bvk]

Mijn vraag

Ik probeer voor mijn domein/server alle incourante cipher suites te verwijderen en dacht dit ook gedaan te hebben. Ik krijg desondanks nog steeds deze melding:



Relevante software en hardware die ik gebruik

IIS Crypto 2.0 op Server 2012 R2

Wat ik al gevonden of geprobeerd heb

Ik heb geprobeerd om deze Cipher (AES_256_CBC with HMAC-SHA1) te zoeken en te verwijderen en alles met alleen maar eindigend op SHA te verwijderen, geen succes. Ook het opnieuw instellen volgens "Best practises" geeft geen soelaas. Huidige set:



Waarbij ik de onderste drie dus al eerder uitgezet had zonder dat dit iets uitmaakte. Ik krijg nu een A op SSL Labs en dat is op zich al prima, maar een A+ is natuurlijk beter en daarnaast ben ik gewoon benieuwd welke Cipher suite(s) er nu nog in de weg zit(ten). Ik kan het niet vinden....

Kan iemand mij vertellen welke ik nu kan/moet verwijderen voor een optimaal resultaat?

[Thralas]

Pas je op dat je niet in de val van de 'verkeerde' optimalisaties trapt?

Niets mis met enigzins idealistisch en progressief securitybeleid, maar zij die zich het meeste zorgen maken om SSL/TLS ciphersuites hebben er meestal het minste kaas van gegeten. Updaten, updaten, updaten en auditing is praktisch nuttiger, het 'risico' van verouderde ciphersuites is al snel verwaarloosbaar.

Ik snap dat je enigzins wanhopig wat probeert, maar de situatie in je screenshot is wel erg maf; je hebt de AES-CBC ciphersuites laten staan, maar een setje fonkelnieuwe GCM uitgezet (!?!?!)

That said, Chrome is erg progressief. Enkel AES-GCM en ChaCha20/Poly1305 based ciphersuites worden als secure gezien.

Ofwel, je moet de zaken even zo herordenen zodat hij GCM prefereert boven CBC. De Mozilla wiki had ergens een overzicht met de meest gunstige ciphersuite order.

Ik vermoed dat je een eind komt als je binnen de set ECDHE_RSA suites ervoor zorgt dat GCM wordt gekozen voor CBC. In je screenshot zie ik echter geen ECDHE_RSA_WITH_AES_XXX_GCM, zijn die verstopt?

[bvk]

Thralas schreef op donderdag 5 januari 2017 @ 19:56:
Pas je op dat je niet in de val van de 'verkeerde' optimalisaties trapt?

Niets mis met enigzins idealistisch en progressief securitybeleid, maar zij die zich het meeste zorgen maken om SSL/TLS ciphersuites hebben er meestal het minste kaas van gegeten. Updaten, updaten, updaten en auditing is praktisch nuttiger, het 'risico' van verouderde ciphersuites is al snel verwaarloosbaar.

Ik snap dat je enigzins wanhopig wat probeert, maar de situatie in je screenshot is wel erg maf; je hebt de AES-CBC ciphersuites laten staan, maar een setje fonkelnieuwe GCM uitgezet (!?!?!)

That said, Chrome is erg progressief. Enkel AES-GCM en ChaCha20/Poly1305 based ciphersuites worden als secure gezien.

Ofwel, je moet de zaken even zo herordenen zodat hij GCM prefereert boven CBC. De Mozilla wiki had ergens een overzicht met de meest gunstige ciphersuite order.

Ik vermoed dat je een eind komt als je binnen de set ECDHE_RSA suites ervoor zorgt dat GCM wordt gekozen voor CBC. In je screenshot zie ik echter geen ECDHE_RSA_WITH_AES_XXX_GCM, zijn die verstopt?

Ik probeer inderdaad om niet in valkuilen te trappen en er zelf zoveel mogelijk van te begrijpen, maar is dit redelijk complexe materie. Voor mij dan tot op heden op dit gebied...

Maar ik heb weer leesvoer en zaken om uit te proberen, dank En misschien moet ik ook even naar een andere tool kijken of sowieso een lijst weten te vinden van de suites die aan te raden zijn.

Want waarom zie ik de genoemde "obsolete" cipher suite niet in de lijst, welke zou dat moeten zijn?

Edit: het screenshot geeft dus de huidige "best practises" aan, deze lijst is momenteel actief minus de drie onderste.

[ Voor 3% gewijzigd door bvk op 05-01-2017 20:31 ]

[Thralas]

De genoemde ciphersuite is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384.

Is de lijst niet verder te scrollen?

[ Voor 22% gewijzigd door Thralas op 05-01-2017 20:41 ]

[bvk]

Thralas schreef op donderdag 5 januari 2017 @ 20:41:
De genoemde ciphersuite is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384.

Is de lijst niet verder te scrollen?

Die uitzetten heeft helaas niets geholpen, Chrome blijft hetzelfde aangeven ondanks CTRL-F5...

Hier het huidige en volledige beeld waarbij ik ook even jouw adviezen heb opgevolgd:



SSL Labs report

Vooralsnog maakt het dus geen verschil, ik ga weer verder met lezen en zoeken...

[Xudonax]

Is het niet gewoon doordat je een certificaat gebruikt welke SHA1 gebruikt? Dat is volgens mij de enige reden dat ik deze melding gezien heb, als je je certificaat opnieuw laat ondertekenen door de issuer zou het waarschijnlijk opgelost zijn. Meestal kost dit niets.

[Thralas]

Xudonax schreef op donderdag 5 januari 2017 @ 21:54:
Is het niet gewoon doordat je een certificaat gebruikt welke SHA1 gebruikt? Dat is volgens mij de enige reden dat ik deze melding gezien heb, als je je certificaat opnieuw laat ondertekenen door de issuer zou het waarschijnlijk opgelost zijn. Meestal kost dit niets.

Nee. Dat is een ander mogelijk probleem, maar niet de veroorzaker van deze specifieke melding.

bvk schreef op donderdag 5 januari 2017 @ 21:50:
Hier het huidige en volledige beeld waarbij ik ook even jouw adviezen heb opgevolgd:

Niet helemaal goed gelezen. Je hebt ECDHE_ECDSA ciphersuites bovenaan gezet, terwijl ik het over ECDHE_RSA.

Je hebt niets aan de ECDHE_ECSA suites, tenzij je certificaat ook met ECDSA gesigned is. Anders pakt hij enkel RSA ciphersuites.

Ik zie echter geen ECDHE_RSA + GCM ciphersuite in de volledige lijst, Lijkt me een kwestie van een oud OS (W2008 R2) icm. wat een bleeding edge browser (Chrome) het liefste ziet.

Je zou die DHE_RSA_WITH_AES_xxx_GCM suites bovenaan kunnen zetten, ik denk dat het dan wel werkt. Reden dat het standaard uitstaat is omdat EC veel sneller is als je *veel* requests per seconde afhandelt.

Of, je certifcaat vervangen voor iets dat met EC gesigned is. LetsEncrypt biedt ze in ieder geval aan, mogelijk niet in de standaardconfiguratie. Dan kun je immers ECDHE_ECDSA gebruiken en zou je configuratie zoals je hem nu hebt moeten werken.

Vergeet dan niet dan oude systemen mogelijk geen EC based certs ondersteunen. Windows XP bijvoorbeeld, en oude smartphones vast ook niet.

[bvk]

Dank voor jullie reacties en uitleg!

Het betreft een splinternieuwe Dell R230 server met daarop een volledig bijgewerkte Windows 2012 R2 installatie. Het certificaat is een Comodo EV (voor 2 domeinen) waarvan ik ook niet verwacht dat die problemen zou moeten geven, worden die niet standaard met de laatste techniek uitgegeven?

Ik zal het nog eens gaan proberen met de DHE_RSA_WITH_AES_xxx_GCM bovenaan, wordt vervolgd!

Vergeet dan niet dan oude systemen mogelijk geen EC based certs ondersteunen. Windows XP bijvoorbeeld, en oude smartphones vast ook niet.

Dat snap ik en XP of Android 2.2 gebruikers wil ik dan ook weren, maar tegelijkertijd ook weer geen Vista of 4.0 gebruikers uitsluiten...

[Mythling]

Is een IIS herstart niet nodig na deze instellingen?

[PolarBear]

Mythling schreef op vrijdag 6 januari 2017 @ 13:58:
Is een IIS herstart niet nodig na deze instellingen?

Sterker nog, volgens mij zelfs een reboot.

[bvk]

PolarBear schreef op vrijdag 6 januari 2017 @ 14:13:
[...]

Sterker nog, volgens mij zelfs een reboot.

Klopt helemaal, de server moet opnieuw opgestart worden. Daarom gaat het toepassen en testen van nieuwe settings ook niet zo makkelijk, je wil een server liever niet overdag rebooten. En daarnaast heeft de Dell R230 een probleem met het geheugen bij een warme reboot. Bekend bij Dell en er wordt aan een BIOS update gewerkt waarvan ik hoop dat die snel komt...

Snap er niets meer van.... Nu krijg ik een B op SSL Labs met onderstaande settings

[ Voor 14% gewijzigd door bvk op 06-01-2017 20:34 ]

[Compizfox]

De melding die Chrome geeft (obsolete cipher) heeft te maken met het feit dat je SHA-1 als MAC ondersteunt. Op zich is dat niet zo'n enorm probleem (zover ik weet), ook SSL Labs doet er niet moeilijk over.

Je kunt de melding weghalen door alle ciphersuites met SHA-1 als MAC uit te zetten. Echter, dan loop je tegen een probleem aan omdat IIS blijkbaar alleen AES-GCM ondersteunt in combinatie met ECDSA*. Aan de andere kant ondersteunen Firefox en Chrome alleen SHA256/SHA384 in combinatie met AES-GCM...

Dat clasht dus met elkaar en heeft tot gevolg dat je website het dan alleen in IE11 doet.

*: IIS ondersteunt ook AES-GCM in combinatie met DHE-RSA (in plaats van ECDHE) maar dan loop je tegen een ander probleem aan: IIS ondersteunt maar 1024 bits DH-parameters. Dat is een groter probleem dan het ondersteunen van SHA-1 (krijg je een B voor op SSL Labs).

Moraal van het verhaal: ver wegblijven van IIS als het om security gaat

[bvk]

Compizfox schreef op vrijdag 6 januari 2017 @ 22:19:
De melding die Chrome geeft (obsolete cipher) heeft te maken met het feit dat je SHA-1 als MAC ondersteunt. Op zich is dat niet zo'n enorm probleem (zover ik weet), ook SSL Labs doet er niet moeilijk over.

Je kunt de melding weghalen door alle ciphersuites met SHA-1 als MAC uit te zetten. Echter, dan loop je tegen een probleem aan omdat IIS blijkbaar alleen AES-GCM ondersteunt in combinatie met ECDSA*. Aan de andere kant ondersteunen Firefox en Chrome alleen SHA256/SHA384 in combinatie met AES-GCM...

Dat clasht dus met elkaar en heeft tot gevolg dat je website het dan alleen in IE11 doet.

*: IIS ondersteunt ook AES-GCM in combinatie met DHE-RSA (in plaats van ECDHE) maar dan loop je tegen een ander probleem aan: IIS ondersteunt maar 1024 bits DH-parameters. Dat is een groter probleem dan het ondersteunen van SHA-1 (krijg je een B voor op SSL Labs).

Moraal van het verhaal: ver wegblijven van IIS als het om security gaat

Helder, dank voor de uitleg welke het nu goed duidelijk maakt wat er speelt

Ik heb het nu maar weer teruggezet naar de oude configuratie met weer een "A" en neem de Chrome melding maar voor lief, niks aan te doen blijkbaar...