Hoe belangrijk zo'n SSL score van ssllabs.com eigenlijk?

[Pikoe]

Ik zat een paar weken geleden puur uit interesse gewoon eens wat sites in te voeren op https://www.ssllabs.com/ssltest/analyze.html

Daarbij kwam ik verschillende sites tegen die een F scoren.
Ik heb de verantwoordelijken maar een mailtje gestuurd, maar krijg natuurlijk geen reactie. Maar hoe belangrijk zijn die scores nou eigenlijk. Wil een F zeggen dat een gebruiker via MitM attacks volledig afgeluisterd kan worden?

Voorbeelden van sites met een F (met screencap van de score als link):
webmail eerste en tweede kamer in nederland
webmail van de publieke omroep
intranet van het europarlement

edit: topic typo "Hoe belangrijk *is* zo'n SSL score van ssllabs.com eigenlijk?"

[ Voor 5% gewijzigd door Pikoe op 16-12-2014 18:20 ]

[MarElo]

Ik zou eens op www.security.nl gaan kijken voor dit soort vragen.
Lees eerst dit https://www.security.nl/p...%2C+SNS%2C+Triodos%2C+ASN maar even helemaal door

[Jester-NL]

SSLlabs is gereedschap. Spul dat je op twee momenten gebruikt:
* Als je je SSL inregelt en wilt testen.
* Als je wilt weten hoe ver je de SSL-implementatie van een site mag vertrouwen.

In de voorbeelden die je hier geeft, zie ik vooral wat spelen ;-) anders had je namelijk de links met de volledige rapporten wel gegeven, in plaats van alleen de (populistische) scores.
En ik ben net niet nieuwsgierig genoeg om zelf nog een keer te typen en wachten

[Pikoe]

Ik kan ze niet hotlinken, dan moeten de resultaten helemaal opnieuw laden, vandaar dat ik het zo deed.

Maar hier zijn ze, vroeg me vooral af wat ze betekenden. (en of die F nou echt zo erg is als dat ze voor doen komen, je zou namelijk dat een F betekend dat het geheel niet veilig is)
https://www.ssllabs.com/s...rlement.nl&hideResults=on
https://www.ssllabs.com/s...rlement.nl&hideResults=on
https://www.ssllabs.com/s...eomroep.nl&hideResults=on
https://www.ssllabs.com/s....europa.eu&hideResults=on

edit: oh, het blijkt dat ze wel even gecached blijven.

[ Voor 14% gewijzigd door Pikoe op 17-12-2014 00:32 ]

[lordgandalf]

De reports hebben het allemaal over een SHA1 cypher waarvan ondertussen duidelijk is dat het niet zo secure is als het leek. Nu is de vraag hoe erg is dat ? eerste en tweede kamer websites lijkt me dit niet erg zolang er geen login op staat. De webmail is een ander verhaal net als de intranet site lijkt mij

[Equator]

SHA1 is geen cypher maar een hashing algoritme. SHA1 is niet gekraakt maar wel onveilig omdat het mogelijk is om met hedendaagse technieken een SHA1 hash na te maken. Dat houdt in dat je certificaten zou kunnen namaken en een MitM attack uit zou kunnen voeren. Allemaal erg theoretisch, maar om de mogelijkheid uit te sluiten is het aan te raden geen SHA1 meer te gebruiken.

Ik zou het nergens meer gebruiken en geef dit ook als advies. Het grote nadeel is dat een overheidswebsite geen mensen wil uitsluiten die nog met verouderde niet gepatchte systemen werken die geen SHA2 ondersteunen.

[serkoon]

Je kunt niet een bestaande SHA1 hash 'namaken', dat wil zeggen: een collission zoeken voor een gegeven hash. Wel is aangetoond dat er een minder dan gewenst aantal pogingen nodig is om zelf twee verschillende blokken data te maken die dezelfde hash opleveren. Vanaf dat gegeven tot een gefalsificeerd certificaat is nog steeds een erg grote stap. Een al bestaand certificaat met een SHA1 hash is dus ook helemaal niet na te maken en het gebruik van SHA1 in een certificaat is dus ook eigenlijk geen risico.

MD5 is nog verder aangevallen en daarmee is het, in bijzondere omstandigheden en met brute-force, gelukt om een onschuldig certificaat te laten genereren met dezelfde hash als een zelf-gemaakt gefalsificeerd certificaat. Zodoende kon de signature van het onschuldige certificaat op het gefalsificeerde certificaat geplakt worden zodat deze van een geldige signature voorzien werd.

[Jester-NL]

Het lijkt erop dat voor eerstekamer.parlement.nl en tweedekamer.parlement.nl twee losse (GoDaddy DV) certificaten zijn aangeschaft... ergens in december 2012, waar vervolgens, na installatie, niet meer naar is omgekeken.

Ik heb niet het idee dat er hier bewust is gekozen voor SHA1, maar veel meer dat er een nogal passieve houding is in onderhoud. Ook weet ik niet of GoDaddy (of de reseller) haar klant op de hoogte heeft gebracht van de ontwikkelingen die er aanzitten te komen op het gebied van SHA1 -> SHA2. En zelfs dan... de certificaten lopen tot 2015, en zullen vervolgens vervangen moeten worden, waarbij automatisch SHA2 wordt uitgeven.
Ook de andere server-instellingen zijn (mijns inziens) veel meer toe te schrijven aan gebrekkig/vergeten/achterstallig onderhoud dan een bewuste keuze om die enkele medewerker die (nog steeds) met een WinXP-laptop met IE6 wil verbinden. Zeker gezien deze site pas sinds begin 2013 actief lijkt , en er dus eigenlijk geen reden is om aan te nemen dat de gebruikte serversoftware niet met SHA2 overweg kan.

Maar uiteindelijk ben ik het vooral eens met Equator en serkoon... onderhoud is aan te raden, updaten ook, maar de sites zijn met deze resultaten niet automagisch compromised...

(overigens... de kwetsbaarheid van SHA1 is op dit moment eigenlijk alleen met een militair budget goed te exploiten))

[ Voor 9% gewijzigd door Jester-NL op 17-12-2014 16:55 . Reden: Kleine toevoegingen ]

[Thralas]

SSL/TLS behelst een ontzettend complexe verzameling van standaarden en implementaties gebaseerd op een uitgebreid scala cryptografische protocollen. Deze protocollen zijn op hun beurt weer opgebouwd uit cryptografische primitieven, waarbij er een hoop keuzevrijheid is.

Zonder goede kennis van SSL/TLS (standaarden, implementaties) en de achterliggende cryptografie met alle bijbehorende (bekende) kwetsbaarheden kun je vrijwel geen fatsoenlijke inschatting maken van het resultaat van de aangehaalde SSL-test (dat is dan ook de insteek van TS).

De SSL-analyzer van Qualys is een handig, maar tegelijkertijd ook gevaarlijk middel. Wat er vaak gebeurt is dat men een aantal resultaten met bekende termen cherrypickt en op basis daarvan wat conclusies trekt, terwijl een eenduidig antwoord vaak niet te geven is door een gebrek aan context.

Zo ook in dit topic, iemand pikt er een bekend primitief uit (SHA1), en een post later is dat algoritme ten onrechte bestempeld als preimageable. Misschien vloeit dat weer voort uit een veelgemaakte fout omtrent de onjuiste interpretatie van het concept 'gebroken algoritmes' - overigens feilloos toegelicht in de context van x.509 certificate forgery door serkoon

Om toch nog even in te gaan op de voorbeelden van TS, ja, die F is in deze gevallen vrij kwalijk. Alle voorbeelden falen op support voor insecure renegotiation (CVE-2009-3555), wat icm. een MITM attack leidt tot een inbreuk op de integriteit van SSL/TLS-sessies.

Pikoe schreef op dinsdag 16 december 2014 @ 18:18:
Wil een F zeggen dat een gebruiker via MitM attacks volledig afgeluisterd kan worden?

Nee. Zo simpel is het niet. Dat hangt helemaal af van de kwetsbaarheid en context. In geval van CVE-2009-3555 bij een HTTP-server kan iemand met een MITM-positie je request beperkt aanpassen (maar niet zomaar inzien!), afhankelijk van de applicatie zou je eventueel request contents (beperkt) kunnen lekken.

Voor bepaalde versies van OpenSSL valt het kaartenhuisje (CVE-2014-0224) wel geheel ineen bij een MITM, dus in die gevallen klopt je statement wel (en dat is naar ik aanneem ook een 'F' waard).

Wat de kwetsbaarheid ook is, vaak heb je zowel uitgebreide technische kennis als een MITM-positie en een specifiek target nodig, dus in veel gevallen die als PANIEK!1!111! worden gepresenteerd valt het allemaal wel mee (lees: iemand die een willekeurige website betrapt op een 'slechte' score bij Qualys).

De politieke voorbeelden in dit geval zijn dan wel redelijk scherp gekozen (zeker gezien de recente berichtgeving), maar dat neemt niet weg dat het maar de vraag is hoeveel je met een A+-score opschiet in die gevallen

Als laatste: de publicatie ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) van het NCSC biedt een erg mooi overzicht van de 'state of the art' qua toelaatbaarheid van TLS-configuraties. Mits niemand het gebruikt om SSL/TLS-configuraties op basis van een enkele 'onvoldoende' als 'totaal onveilig' te bestempelen, that is..