image

'Chrome-gebruiker mist tsunami van ingetrokken certificaten'

zaterdag 19 april 2014, 10:10 door Redactie, 12 reacties

Vanwege de Heartbleed-bug in OpenSSL zijn de afgelopen week al meer dan 200.000 SSL-certificaten ingetrokken, maar deze tsunami van ongeldige certificaten gaat grotendeels voorbij aan Chrome-gebruikers die door Google in het donker worden gehouden. Dat beweert internetbedrijf Netcraft.

Door de Heartbleed-bug is het mogelijk om de privésleutel van een SSL-certificaat te stelen. Een aanvaller zou hierdoor in bepaalde gevallen in staat kunnen zijn om het versleutelde verkeer tussen bezoekers en de website, waar een SSL-certificaat voor zorgt, te kunnen onderscheppen. Uit voorzorg besloten daarom tal van partijen hun SSL-certificaten opnieuw uit te geven of in z'n geheel te vervangen.

CloudFlare

Content delivery network (CDN) CloudFlare besloot bijvoorbeeld deze week alleen al 134.000 certificaten in te trekken die nu niet meer geldig zijn. Internetbrowsers kunnen ingetrokken SSL-certificaten herkennen dankzij het Online Certificate Status Protocol (OCSP). Als OCSP niet werkt kunnen browsers terugvallen op de certificate revocation list (CRL), een lijst met ingetrokken SSL-certificaten.

Google Chrome voert volgens Netcraft zowel geen OCSP-controle uit en downloadt ook geen CRL-lijsten. Chrome gebruikt een eigen mechanisme genaamd CRLSets, een verzamelde lijst van ingetrokken certificaten die door Google wordt samengesteld. De 134.000 door CloudFlare ingetrokken certificaten staan echter nog niet op deze lijst, waardoor gebruikers ook geen waarschuwing krijgen als ze een potentieel gecompromitteerd certificaat krijgen voorgeschoteld, aldus Paul Mutton van Netcraft.

Hij benadrukt dat Chrome-gebruikers de browser zo kunnen instellen dat er wel op ingetrokken certificaten wordt gecontroleerd. Dit kan door via het geavanceerde instellingenmenu een vinkje voor 'Controleren op intrekking van servercertificaten' (Check for server certificate revocation) te zetten.

Reacties (12)
19-04-2014, 10:36 door [Account Verwijderd] - Bijgewerkt: 19-04-2014, 12:37
[Verwijderd]
19-04-2014, 11:10 door [Account Verwijderd]
[Verwijderd]
19-04-2014, 11:54 door Anoniem
Hallo.

Niet alleen aangevinkt, ook wat rnd gekeken.

Optie certificaten beheren
Zie ik onder tabblad "servers" een rijtje niet vertrouwd staan ( met een rood vierkant eromheen )
tabblad "certificeringsinstanties" ook een paar niet vertrouwd , met een rijtje DigNotar, 8 maal, rood)

de andere twee tabbladen leeg

Vind ik het altijd fijn te horen dat anderen dat ook zo hebben staan ;-)
19-04-2014, 12:06 door Briolet
Google Chrome voert volgens Netcraft zowel geen OCSP-controle uit en downloadt ook geen CRL-lijsten.

Ik dacht dat op de mac ook beide testen per default uit stonden en ik beide met de hand in "Sleutelhangertoegang" ––> "Voorkeuren" ––> "Certificaten" aangezet heb. Maar misschien heb ik dat ook gewoon slecht onthouden, of staan de defaults nu met Mavericks toch al anders. Wie?
19-04-2014, 12:17 door [Account Verwijderd] - Bijgewerkt: 19-04-2014, 12:30
[Verwijderd]
19-04-2014, 12:57 door Anoniem
Misschien komt het omdat 99% van de toko's die een certificaat hebben geen revokation server hebben?
Zelfs gewoon Nederlandse banken, kranten etc hebben geen online revokation server voor hun " https certificaten "...
Normaal gesproken zou een offline revokation server betekenen dat er geen controle kan plaatsvinden en dus dat er geen verbinding gemaakt mag worden... en dat werkt dan weer niet als 99% offline is.
19-04-2014, 13:15 door Anoniem
Ik gebruik hier chrome, maar bij mij stond dit vinkje al aan. Kan me niet herrinneren dat ik dit zelf ook heb aangezet.
19-04-2014, 14:42 door Briolet - Bijgewerkt: 19-04-2014, 15:04
Door Anoniem: Misschien komt het omdat 99% van de toko's die een certificaat hebben geen revokation server hebben?

Waar haal jij dat percentage vandaan? Ik heb net 6 certificaten beken (GMail, Yahoo-mail, Ziggo, KNP, Github, DigiD). Alle 6 hebben een url naar een server in hun certificaat. Okay, het is wel een erg kleine steekproef, maar voor mij genoeg om te veronderstellen dat het merendeel van de grote jongens dit wel goed voor elkaar hebben.
Ook in de custom certificaten van kleinere sites in mijn sleutelhanger bevat zo'n 80% een revokation url.

Hoe zit het overigens met de security.nl verbinding. Daar is de laatste paar dagen iets veranderd. Je had altijd een https verbinding. Een paar dagen geleden heb ik nog via het slotje naar het certificaat gekeken en zag dat ook zij op 8 april een nieuw certificaat zijn gaan gebruiken.
Vandaag is de verbinding gewoon http. Ook als ik in het dialoog mijn wachtwoord invul is het http. Pas als ik OK klik, schakelt hij even naar https gedurende het verzenden en direct daarna weer terug naar http. Op zich veilig, maar je blijft in onzekerheid of het verzenden wel veilig gebeurd. Heel vervelend. Ook kun je nu niet op een gemakkelijke manier even het certificaat controleren.

EDIT: Dat moet iets tijdelijks geweest zijn, want nu is de verbinding weer constant https.
19-04-2014, 16:29 door Anoniem
Door Anoniem: Misschien komt het omdat 99% van de toko's die een certificaat hebben geen revokation server hebben?
Zelfs gewoon Nederlandse banken, kranten etc hebben geen online revokation server voor hun " https certificaten "...
Normaal gesproken zou een offline revokation server betekenen dat er geen controle kan plaatsvinden en dus dat er geen verbinding gemaakt mag worden... en dat werkt dan weer niet als 99% offline is.

Briolet heeft net al de tijd genomen enkele populaire sites te controleren.
Je refereert echter expliciet aan o.a. banken, dus heb je een plezier gedaan deze voor je te checken:
Rabobank:
- CRL: http://EVIntl-crl.verisign.com/EVIntl2006.crl
- OCSP: http://EVIntl-ocsp.verisign.com

ABNAmro:
- CRL: zie Rabobank
- OCSP: zie Rabobank

ING:
- CRL: zie Rabobank (door zelfde CA uitgegeven)
- OCSP: zie Rabobank

Knab:
- CRL: http://crl.globalsign.com/gs/gsdomainvalg2.crl
- OCSP: http://ocsp2.globalsign.com/gsdomainvalg2

Lees: het lijkt erop dat je aan het raaskallen bent, of dat je 0 kennis hebt over certificaten.
In beide gevallen: post dan aub niets
19-04-2014, 17:26 door [Account Verwijderd] - Bijgewerkt: 19-04-2014, 17:28
[Verwijderd]
19-04-2014, 20:48 door Anoniem
Door Peter V.:
Door Briolet:
Hoe zit het overigens met de security.nl verbinding. Daar is de laatste paar dagen iets veranderd. Je had altijd een https verbinding. Een paar dagen geleden heb ik nog via het slotje naar het certificaat gekeken en zag dat ook zij op 8 april een nieuw certificaat zijn gaan gebruiken.
Vandaag is de verbinding gewoon http. Ook als ik in het dialoog mijn wachtwoord invul is het http. Pas als ik OK klik, schakelt hij even naar https gedurende het verzenden en direct daarna weer terug naar http. Op zich veilig, maar je blijft in onzekerheid of het verzenden wel veilig gebeurd. Heel vervelend. Ook kun je nu niet op een gemakkelijke manier even het certificaat controleren.

EDIT: Dat moet iets tijdelijks geweest zijn, want nu is de verbinding weer constant https.

Hoi Briolet! Hier de tekst die ik heb gevonden van gebruiker Spiff:

Door Redactie:
Update Security.NL:
De server van Security.NL maakte gebruik van OpenSSL 1.0.1 welke kwetsbaar was voor de "heartbleed" bug. Bij het uitkomen van de kwetsbaarheid zijn de servers direct in maintenance mode gezet en is het patch proces in gang gezet. We hebben geen sporen kunnen vinden van een succesvolle heartbleed aanval tegen de Security.NL server. Desalniettemin is het altijd een goed idee om je wachtwoorden aan te passen na het uitkomen van een dusdanige kwetsbaarheid.
In dit kader hebben we ook direct nieuwe SSL certificaten en keys geinstalleerd.

Tja, geen sporen gevonden tegen een succesvoille Heartbleed, dat was toch ook een kenmerk van de kwetsbaarheid dat het juist geen enkel spoor achterlaat.
21-04-2014, 00:02 door Anoniem
Omtrent de optie :
"HTTPS/SSL > Manage certificates > Check for server certificate revocation"

Deze keuzemogelijkheid geldt voor diverse Chromium browser varianten :

- Google Chrome 34.0.1847.116
Meer opties inside Google Chrome, type of paste in de urlbar:
chrome://chrome-urls/
Meer browser opties:
chrome://flags

en onder meer

- Chromium 34.0.1847.116
Meer opties inside Chromium, type of paste in de urlbar:
chrome://chrome-urls/
Meer browser opties:
chrome://flags

- Epic 34.0.1771.0
Meer opties inside Epic, type of paste in de urlbar:
chrome://chrome-urls/
Meer browser opties:
chrome://flags

- Yandex 33.0.1750.13412 / 33.0.1750.154
Meer opties inside Yandex, type of paste in de urlbar:
browser://chrome-urls/
Meer browser opties:
browser://flags/

Deels bekend,.

- Aviator 28.0.1500.71 (en de nieuwere 31.0.1650.57 ?)
In de oude versie staat deze optie standaard al aangevinkt.
Bij de nieuwe versie is dat niet zonder installatie direct te zien. Voorkeuren openen in offline run from install image mode, laat deze browser nu Crashen (bij de oude versie niet).

Verder, Aviator verbiedt "flags" ( aviator://flags) inzage, "This webpage is not available"
Ondanks vermelding in de lijst
aviator://aviator-urls/
Verstopt? Open source turned into closed source?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.