Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Uitleg DigiNotar problematiek
Onder andere aan reacties in http://tweakers.net/nieuws/76556/browsers-gaan-foutmeldingen-geven-bij-alle-ssl-certificaten-diginotar.html zie ik dat er veel onduidelijkheden bestaan over hoe certificaten nu precies werken en waarom er soms wel, en soms geen, foutmeldingen optreden bij ingetrokken (revoked) certificaten.
Om zeker te weten dat jouw webbrowser verbinding maakt met de bedoelde website (en niet een vervalsing) wordt gebruik gemaakt van public key certificaten. Dat werkt als volgt:
1. Public Key Sleutelpaar
Voordat een website online gebracht wordt, genereert de eigenaar van die website met speciale tools een cryptografisch sleutelpaar, een public key en een private key. De wiskundige lol hieraan is dat alles wat je met de ene sleutel versleutelt, alleen met de andere kan worden gedecodeerd; dit geldt in principe beide kanten op. De private key mag nooit uit handen gegeven worden, de public key wel. In principe is zo'n sleutelpaar voldoende voor het opzetten van veilige versleutelde verbindingen tussen een webbrowser en een webserver, met één essentieel probleem: iedereen kan zo'n sleutelpaar genereen, dus ook een aanvaller met een vervalste website.
2. CA garandeert eigenaar van public key
Het is dus essentieel dat jouw webbrowser kan vaststellen dat een bepaalde public key daadwerkelijk bij een specifieke website hoort (aangegeven met de hostname in de URL, dus bijv. toegang.eindhoven.nl). Om die reden bestaan CA's oftewel Certificate authorities zoals DigiNotar. De eigenaar van de website (hostname) vraagt, na het genereren van het sleutelpaar, aan de CA een garantie te geven dat de public key daadwerkelijk bij de hostname hoort. Dat doet de CA door de public key samen met de hostname (en nog wat andere gegevens waaronder de verloopdatum) in een digitaal certificaat te stoppen en dat certificaat digitaal te ondertekenen. Met andere woorden, de CA verifieert en garandeert dat de aanbieder van zo'n public key de rechtmatige eigenaar van de betreffende website is.
3. Checks die jouw webbrowser uitvoert
De eigenaar van de website gaat naar huis met z'n public key certificaat en installeert dat op z'n webserver. Als jij nu middels https naar zijn website surft, stuurt die website jou het certificaat om aan te tonen dat je op de echte website zit. Echter, als jouw webbrowser dat certificaat ontvangt mag deze nog niet tevreden zijn, om ten minste de volgende redenen:
- Jij hebt nu ook dat certificaat in jouw bezit en zou daarmee zelf ook zo'n website kunnen namaken! En wie zegt dat je niet zelf al op een namaak website zit? Zie punt 4.
- Je ziet een digitale handtekening van een CA in het certificaat, maar wat zegt dat? Zie punt 5.
- Het certificaat zou ingetrokken (revoked) kunnen zijn! Zie punt 6.
4. Heeft de "andere kant" de bijbehorende private key?
Het eerste aspect wordt opgelost doordat jouw webbrowser een groot random (willekeurig) getal genereert, versleutelt met de public key uit het certificaat en dat naar de webserver stuurt. De webserver kan deze alleen uitpakken als deze over de bijbehorende private key beschikt. Mits de private key niet door aanvallers is gekopieerd weet je zeker dat de public key in het certificaat hoort bij de private key op de webserver waar je verbinding mee hebt.
5. Primaire certificaat controle en hiërarchie
Laten we als voorbeeld nemen: https://toegang.eindhoven.nl. Als ik die site bezoek worden er meteen twee certificaten naar mijn webbrowser gestuurd door toegang.eindhoven.nl, waarbij het eerste certificaat onder meer de volgende gegevens bevat:
Subject = *.eindhoven.nl
Issuer = DigiNotar Services CA
Het tweede (en meegstuurde) certificaat, een zogenaamd intermediate certificaat, is datgene waar het Eindhoven certificaat naar verwijst. Deze bevat onder meer:
Subject = DigiNotar Services CA
Issuer = DigiNotar Root CA
Dat tweede certificaat heeft ter validatie dus een derde certificaat, namelijk voor "DigiNotar Root CA" nodig, en dat is een zogenaamd root certificate dat tot voor kort Firefox installaties werd meegeleverd - maar in de laatste versies is verbannen. Er is dus sprake van een hiërarchische structuur van certificaten, als volgt:
N.b. intermediate en root certificaten zijn geen "public key" certificaten, maar zijn bedoeld om de auhtenticiteit van digitale handtekeningen in onderliggende certificaten te controleren. Verder lijken ze sterk op elkaar.
6. Controle op intrekken/revocation
Wat nu als een website beheerder ontdekt dat z'n site is gekraakt en de private key mogelijk is gekopiëerd? Daarvoor bestaat het intrekken/revocation mechanisme, dat -helaas- slecht werkt; zie bijv. http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html. Feitelijk zouden webbrowsers, voor elk certificaat dat ze raadplegen, bij de uitgever moeten navragen of het betreffende certificaat niet is ingetrokken, en de gebruiker op z'n minst waarschuwen als dat niet lukt of als blijkt dat het certificaat is ingetrokken.
Helaas gebeurt dit, om meerdere redenen, vaak niet of niet goed. En dat is de (stompzinnige) reden dat van sommige webbrowsers updates verschijnen (met minimale blacklists) als "belangrijke" certificaten zijn ingetrokken. Dit vind ik een enorm zwaktebod.
Er zijn twee verschillende manieren voor het checken op ingetrokken certificaten:
- Downloaden van de laatste Certificate Revocation List (CRL) van een CA (uitgever)
- Alleen voor het betreffende certificaat middels het "Online Certificate Status Protocol" (OCSP) de status van dat certificaat navragen.
Welke check waar (URL) kan worden uitgevoerd staat in het betreffende certificaat. Dat vind ik een enorme design error (de URL in het parent certificaat zou gebruikt moeten worden). Het is wachten op slimme CA-hackers die in buitgemaakte certificaten hun eigen server als CRL/OCSP handler opgeven (dan werkt revocation echt helemaal niet meer).
Hieronder ga ik zometeen nog in op wat er aan de hand is met sites waarvan de root CA niet door DigiNotar is uitgegeven.
Om zeker te weten dat jouw webbrowser verbinding maakt met de bedoelde website (en niet een vervalsing) wordt gebruik gemaakt van public key certificaten. Dat werkt als volgt:
1. Public Key Sleutelpaar
Voordat een website online gebracht wordt, genereert de eigenaar van die website met speciale tools een cryptografisch sleutelpaar, een public key en een private key. De wiskundige lol hieraan is dat alles wat je met de ene sleutel versleutelt, alleen met de andere kan worden gedecodeerd; dit geldt in principe beide kanten op. De private key mag nooit uit handen gegeven worden, de public key wel. In principe is zo'n sleutelpaar voldoende voor het opzetten van veilige versleutelde verbindingen tussen een webbrowser en een webserver, met één essentieel probleem: iedereen kan zo'n sleutelpaar genereen, dus ook een aanvaller met een vervalste website.
2. CA garandeert eigenaar van public key
Het is dus essentieel dat jouw webbrowser kan vaststellen dat een bepaalde public key daadwerkelijk bij een specifieke website hoort (aangegeven met de hostname in de URL, dus bijv. toegang.eindhoven.nl). Om die reden bestaan CA's oftewel Certificate authorities zoals DigiNotar. De eigenaar van de website (hostname) vraagt, na het genereren van het sleutelpaar, aan de CA een garantie te geven dat de public key daadwerkelijk bij de hostname hoort. Dat doet de CA door de public key samen met de hostname (en nog wat andere gegevens waaronder de verloopdatum) in een digitaal certificaat te stoppen en dat certificaat digitaal te ondertekenen. Met andere woorden, de CA verifieert en garandeert dat de aanbieder van zo'n public key de rechtmatige eigenaar van de betreffende website is.
3. Checks die jouw webbrowser uitvoert
De eigenaar van de website gaat naar huis met z'n public key certificaat en installeert dat op z'n webserver. Als jij nu middels https naar zijn website surft, stuurt die website jou het certificaat om aan te tonen dat je op de echte website zit. Echter, als jouw webbrowser dat certificaat ontvangt mag deze nog niet tevreden zijn, om ten minste de volgende redenen:
- Jij hebt nu ook dat certificaat in jouw bezit en zou daarmee zelf ook zo'n website kunnen namaken! En wie zegt dat je niet zelf al op een namaak website zit? Zie punt 4.
- Je ziet een digitale handtekening van een CA in het certificaat, maar wat zegt dat? Zie punt 5.
- Het certificaat zou ingetrokken (revoked) kunnen zijn! Zie punt 6.
4. Heeft de "andere kant" de bijbehorende private key?
Het eerste aspect wordt opgelost doordat jouw webbrowser een groot random (willekeurig) getal genereert, versleutelt met de public key uit het certificaat en dat naar de webserver stuurt. De webserver kan deze alleen uitpakken als deze over de bijbehorende private key beschikt. Mits de private key niet door aanvallers is gekopieerd weet je zeker dat de public key in het certificaat hoort bij de private key op de webserver waar je verbinding mee hebt.
5. Primaire certificaat controle en hiërarchie
Laten we als voorbeeld nemen: https://toegang.eindhoven.nl. Als ik die site bezoek worden er meteen twee certificaten naar mijn webbrowser gestuurd door toegang.eindhoven.nl, waarbij het eerste certificaat onder meer de volgende gegevens bevat:
Subject = *.eindhoven.nl
Issuer = DigiNotar Services CA
Het tweede (en meegstuurde) certificaat, een zogenaamd intermediate certificaat, is datgene waar het Eindhoven certificaat naar verwijst. Deze bevat onder meer:
Subject = DigiNotar Services CA
Issuer = DigiNotar Root CA
Dat tweede certificaat heeft ter validatie dus een derde certificaat, namelijk voor "DigiNotar Root CA" nodig, en dat is een zogenaamd root certificate dat tot voor kort Firefox installaties werd meegeleverd - maar in de laatste versies is verbannen. Er is dus sprake van een hiërarchische structuur van certificaten, als volgt:
(A) DigiNotar Root CA
(B) DigiNotar Services CA
(C) *.eindhoven.nl
Alleen als de webbrowser het genoemde root certificate "aan boord" heeft kan deze de echtheid en correctheid van het "DigiNotar Services CA" intermediate certificaat controleren. Als dat bevesigd is kan pas het *.eindhoven.nl certificaat worden gecontroleerd.(B) DigiNotar Services CA
(C) *.eindhoven.nl
N.b. intermediate en root certificaten zijn geen "public key" certificaten, maar zijn bedoeld om de auhtenticiteit van digitale handtekeningen in onderliggende certificaten te controleren. Verder lijken ze sterk op elkaar.
6. Controle op intrekken/revocation
Wat nu als een website beheerder ontdekt dat z'n site is gekraakt en de private key mogelijk is gekopiëerd? Daarvoor bestaat het intrekken/revocation mechanisme, dat -helaas- slecht werkt; zie bijv. http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html. Feitelijk zouden webbrowsers, voor elk certificaat dat ze raadplegen, bij de uitgever moeten navragen of het betreffende certificaat niet is ingetrokken, en de gebruiker op z'n minst waarschuwen als dat niet lukt of als blijkt dat het certificaat is ingetrokken.
Helaas gebeurt dit, om meerdere redenen, vaak niet of niet goed. En dat is de (stompzinnige) reden dat van sommige webbrowsers updates verschijnen (met minimale blacklists) als "belangrijke" certificaten zijn ingetrokken. Dit vind ik een enorm zwaktebod.
Er zijn twee verschillende manieren voor het checken op ingetrokken certificaten:
- Downloaden van de laatste Certificate Revocation List (CRL) van een CA (uitgever)
- Alleen voor het betreffende certificaat middels het "Online Certificate Status Protocol" (OCSP) de status van dat certificaat navragen.
Welke check waar (URL) kan worden uitgevoerd staat in het betreffende certificaat. Dat vind ik een enorme design error (de URL in het parent certificaat zou gebruikt moeten worden). Het is wachten op slimme CA-hackers die in buitgemaakte certificaten hun eigen server als CRL/OCSP handler opgeven (dan werkt revocation echt helemaal niet meer).
Hieronder ga ik zometeen nog in op wat er aan de hand is met sites waarvan de root CA niet door DigiNotar is uitgegeven.
Reacties (26)
04-09-2011, 15:49 door
Bitwiper
https://www.digid.nl/ is een slechte website, want als ik daar met MSIE8 naar toe ga, krijg ik een waarschuwing dat delen van de website via http (dus niet versleuteld en met geen enkele garantie over de oorsprong) worden aangeboden. Slechte zaak (amateuristisch).
Om die reden maak ik in onderstaand voorbeeld gebruik van https://as.digid.nl/, dat is de site waar je (met een aangepaste URL) op terechtkomt als je bijv. je belastingaangifte indient, en die lijkt "clean" https te zijn.
Als ik https://as.digid.nl/ open is er sprake van de volgende certificaten hiërarchie (vreemd genoeg krijg ik ze allemaal toegezonden, (A) is zinloos want die zit standaard al in alle relevante webbrowsers):
Op dit moment weer ik nog niet bij welk certificaat het serienummer 0x013163B7 behoort (als iemand dit weet hoor ik het graag).
Verder vind ik heel vreemd dat in http://crl.pkioverheid.nl/DomOvLatestCRL.crl onder meer het volgende staat (je kunt deze zelf downloaden en als je Windows gebruikt, erop dubbelklikken om de inhoud te zien):
N.b. ik krijg alleen een foutmelding als ik met Firefox naar https://as.digid.nl ga omdat de klok van de OCSP server van DigiNotar bijna 1 uur achterloopt (zie https://secure.security.nl/artikel/38344/1/DigiNotar_OCSP_responses_fout%3F.htm).
Om die reden maak ik in onderstaand voorbeeld gebruik van https://as.digid.nl/, dat is de site waar je (met een aangepaste URL) op terechtkomt als je bijv. je belastingaangifte indient, en die lijkt "clean" https te zijn.
Als ik https://as.digid.nl/ open is er sprake van de volgende certificaten hiërarchie (vreemd genoeg krijg ik ze allemaal toegezonden, (A) is zinloos want die zit standaard al in alle relevante webbrowsers):
(A) Staat der Nederlanden Root CA
- Issuer: Staat der Nederlanden Root CA (dit is een "self-signed" certificate)
- OCSP: geen
- CRL: geen
(B) Staat der Nederlanden Overheid CA
- Issuer: Staat der Nederlanden Root CA
- OCSP: geen
- CRL: http://crl.pkioverheid.nl/LatestCRL.crl (momenteel lege lijst,
d.w.z. geen ingetrokken certificaten)
(C) DigiNotar PKIoverheid CA Overheid en Bedrijven
- Issuer: Staat der Nederlanden Overheid CA
- Serienummer: 0x013169B0
- OCSP: geen
- CRL: http://crl.pkioverheid.nl/DomOvLatestCRL.crl (bevat 1
ingetrokken certificaat met serienummer = 0x013163B7)
(D) as.digid.nl
- Issuer: DigiNotar PKIoverheid CA Overheid en Bedrijven
- OCSP: http://validation.diginotar.nl
- CRL: http://service.diginotar.nl/crl/PKIOverheidenBedrijven/latestCRL.crl
Duidelijk is dat er sprake is van een intermediate certificate van DigiNotar dat, vreemd genoeg, niet is integrokken! Daarom krijg ik, als ik met MSIE8 naar https://as.digid.nl/ ga krijg ik, geen foutmelding.- Issuer: Staat der Nederlanden Root CA (dit is een "self-signed" certificate)
- OCSP: geen
- CRL: geen
(B) Staat der Nederlanden Overheid CA
- Issuer: Staat der Nederlanden Root CA
- OCSP: geen
- CRL: http://crl.pkioverheid.nl/LatestCRL.crl (momenteel lege lijst,
d.w.z. geen ingetrokken certificaten)
(C) DigiNotar PKIoverheid CA Overheid en Bedrijven
- Issuer: Staat der Nederlanden Overheid CA
- Serienummer: 0x013169B0
- OCSP: geen
- CRL: http://crl.pkioverheid.nl/DomOvLatestCRL.crl (bevat 1
ingetrokken certificaat met serienummer = 0x013163B7)
(D) as.digid.nl
- Issuer: DigiNotar PKIoverheid CA Overheid en Bedrijven
- OCSP: http://validation.diginotar.nl
- CRL: http://service.diginotar.nl/crl/PKIOverheidenBedrijven/latestCRL.crl
Op dit moment weer ik nog niet bij welk certificaat het serienummer 0x013163B7 behoort (als iemand dit weet hoor ik het graag).
Verder vind ik heel vreemd dat in http://crl.pkioverheid.nl/DomOvLatestCRL.crl onder meer het volgende staat (je kunt deze zelf downloaden en als je Windows gebruikt, erop dubbelklikken om de inhoud te zien):
Effective Date: August 24, 2011 11:41:05
Next Update: November 22, 2011 11:46:05
Revocation list:
Serial number: 01 31 63 b7
- Revocation date: July 29, 2009 11:06:08
- CRL Reason Code: Superseded (4)
Waarom de volgende update pas ophalen op 22 november (als ik het goed begrijpt werkt dit zo)? Als morgen besloten wordt dat het bovenstaande DigiNotar intermediate certificate ook niet meer betrouwbaar is, dan gaan webbrowsers die CRL echt niet voor 22 nov ophalen als ze hem ergens tussen 24 aug. en vandaag al hebben opgehaald! En waarom geen OCSP check mogelijkheid? Bizar.Next Update: November 22, 2011 11:46:05
Revocation list:
Serial number: 01 31 63 b7
- Revocation date: July 29, 2009 11:06:08
- CRL Reason Code: Superseded (4)
N.b. ik krijg alleen een foutmelding als ik met Firefox naar https://as.digid.nl ga omdat de klok van de OCSP server van DigiNotar bijna 1 uur achterloopt (zie https://secure.security.nl/artikel/38344/1/DigiNotar_OCSP_responses_fout%3F.htm).
04-09-2011, 16:15 door
Bitwiper
DigiNotar heeft ook intermediate certificaten uitgegeven die door een andere partij dan de Staat der Nederlanden (en DigiNotar's eigen root CA) worden gevalideerd.
Bijvoorbeeld bij https://webmail.zoetermeer.nl is de root CA van Entrust (Zoetermeer is een voorbeeld, er zijn vast veel meer sites zo). Er is sprake van de volgende hiërarchie:
Bijvoorbeeld bij https://webmail.zoetermeer.nl is de root CA van Entrust (Zoetermeer is een voorbeeld, er zijn vast veel meer sites zo). Er is sprake van de volgende hiërarchie:
(A) Entrust.net Secure Server Certification Authority
- Issuer: Entrust.net Secure Server Certification Authority (self-signed)
- OCSP: geen
- CRL: http://www.entrust.net/CRL/net1.crl
(B) DigiNotar Services 1024 CA
- Serienummer: 0x469C2CB0
- Issuer: Entrust.net Secure Server Certification Authority
- OCSP: http://ocsp.entrust.net
- CRL: http://crl.entrust.net/server1.crl
(C) webmail.zoetermeer.nl
- Issuer: DigiNotar Services 1024 CA
- OCSP: geen!
- CRL: geen!
Als ik http://crl.entrust.net/server1.crl download dan zie ik onder meer:- Issuer: Entrust.net Secure Server Certification Authority (self-signed)
- OCSP: geen
- CRL: http://www.entrust.net/CRL/net1.crl
(B) DigiNotar Services 1024 CA
- Serienummer: 0x469C2CB0
- Issuer: Entrust.net Secure Server Certification Authority
- OCSP: http://ocsp.entrust.net
- CRL: http://crl.entrust.net/server1.crl
(C) webmail.zoetermeer.nl
- Issuer: DigiNotar Services 1024 CA
- OCSP: geen!
- CRL: geen!
Effective Date: September 03, 2011 23:36:52
Next Update: September 10, 2011 23:36:52
Revocation list:
[...]
Serial number: 46 9c 2c b0
- Revocation date: August 30, 2011 22:03:12
- CRL Reason Code: Superseded (4)
[...]
Met andere woorden, als ik https://webmail.zoetermeer.nl open krijg ik een heldere foutmelding omdat Entrust het DigiNotar intermediate certificaat heeft ingetrokken.Next Update: September 10, 2011 23:36:52
Revocation list:
[...]
Serial number: 46 9c 2c b0
- Revocation date: August 30, 2011 22:03:12
- CRL Reason Code: Superseded (4)
[...]
04-09-2011, 18:34 door
anoniem lafbekje
Complete lijst met aangemaakte certificaten:
CN=*.10million.org
CN=*.JanamFadayeRahbar.com
CN=*.RamzShekaneBozorg.com
CN=*.SahebeDonyayeDigital.com
CN=*.android.com
CN=*.aol.com
CN=*.azadegi.com
CN=*.balatarin.com
CN=*.comodo.com
CN=*.digicert.com
CN=*.globalsign.com
CN=*.google.com
CN=*.microsoft.com
CN=*.mossad.gov.il
CN=*.mozilla.org
CN=*.skype.com
CN=*.startssl.com
CN=*.thawte.com
CN=*.torproject.org
CN=*.walla.co.il
CN=*.windowsupdate.com
CN=*.wordpress.com
CN=Comodo Root CA
CN=CyberTrust Root CA
CN=DigiCert Root CA
CN=Equifax Root CA
CN=GlobalSign Root CA
CN=Thawte Root CA
CN=VeriSign Root CA
CN=addons.mozilla.org
CN=azadegi.com
CN=friends.walla.co.il
CN=login.live.com
CN=login.yahoo.com
CN=my.screenname.aol.com
CN=secure.logmein.com
CN=twitter.com
CN=wordpress.com
CN=www.10million.org
CN=www.Equifax.com
CN=www.balatarin.com
CN=www.cia.gov
CN=www.cybertrust.com
CN=www.facebook.com
CN=www.globalsign.com
CN=www.google.com
CN=www.hamdami.com
CN=www.mossad.gov.il
CN=www.sis.gov.uk
CN=www.update.microsoft.com
CN=*.JanamFadayeRahbar.com is een interessante want die naam kun je koppelen aan de hack van een andere CA namelijk Comodo eerder dit jaar. "Janam Fadaye Rahbar" = "I will sacrifice my soul for my leader"
CN=*.10million.org
CN=*.JanamFadayeRahbar.com
CN=*.RamzShekaneBozorg.com
CN=*.SahebeDonyayeDigital.com
CN=*.android.com
CN=*.aol.com
CN=*.azadegi.com
CN=*.balatarin.com
CN=*.comodo.com
CN=*.digicert.com
CN=*.globalsign.com
CN=*.google.com
CN=*.microsoft.com
CN=*.mossad.gov.il
CN=*.mozilla.org
CN=*.skype.com
CN=*.startssl.com
CN=*.thawte.com
CN=*.torproject.org
CN=*.walla.co.il
CN=*.windowsupdate.com
CN=*.wordpress.com
CN=Comodo Root CA
CN=CyberTrust Root CA
CN=DigiCert Root CA
CN=Equifax Root CA
CN=GlobalSign Root CA
CN=Thawte Root CA
CN=VeriSign Root CA
CN=addons.mozilla.org
CN=azadegi.com
CN=friends.walla.co.il
CN=login.live.com
CN=login.yahoo.com
CN=my.screenname.aol.com
CN=secure.logmein.com
CN=twitter.com
CN=wordpress.com
CN=www.10million.org
CN=www.Equifax.com
CN=www.balatarin.com
CN=www.cia.gov
CN=www.cybertrust.com
CN=www.facebook.com
CN=www.globalsign.com
CN=www.google.com
CN=www.hamdami.com
CN=www.mossad.gov.il
CN=www.sis.gov.uk
CN=www.update.microsoft.com
CN=*.JanamFadayeRahbar.com is een interessante want die naam kun je koppelen aan de hack van een andere CA namelijk Comodo eerder dit jaar. "Janam Fadaye Rahbar" = "I will sacrifice my soul for my leader"
04-09-2011, 18:50 door
[Account Verwijderd]
[Verwijderd]
04-09-2011, 19:04 door
Bitwiper
Enkele conclusies:
(1) Veel overheidswebsites (waaronder as.digid.nl) hebben nog geen probleem doordat het DigiNotar intermediate certificate met serienummer 0x013169B0 nog steeds vertrouwd wordt door uiteindelijk de "Staat der Nederlanden Root CA". Het zou mij niet verbazen als er een fout gemaakt is en het verkeerde certificaat is ingetrokken.
(2) Websites met DigiNotar certificaten die foutmeldingen opleveren hebben het uiteindelijke vertrouwen nodig van ofwel het DigiNotar root certificaat (dat uit steeds meer browsers verwijderd wordt) ofwel hebben het vertrouwen nodig van root certificaten van derde partijen zoals Entrust, die ondertussen het vertrouwen in DigiNotar hebben opgezegd.
(3) Revocation werkt niet. Dit ondermijnt SSL/TLS op zeer ernstige wijze. Zowel browserfabrikanten als CA's zijn schuldig. Bijv. dat de Staat der Nederlanden geen OCSP ondersteunt en er vanuit gaat dat elke 3 maanden een CRL ophalen wel genoeg zal zijn vind ik een blunder. Ten slotte wijst het feit dat URL's voor revocation checks in het certificaat zelf zitten erop dat de ontwerpers geen rekening hebben gehouden met gecompromitteerde CA's.
(4) Als noodmaatregel zie ik instanties self-signed certificaten inzetten (notabene zonder OCSP en CRL erin). Zodra iemand zo'n certificaat toch accepteert en in z'n browser opneemt (default gedrag bij Firefox) zal deze er nooit meer uit verdwijnen. Mocht de private key gestolen worden heb je een groot probleem. Belangrijker is dat dit tegen het (goede) advies van Donner ingaat: accepteer nooit een foutief certificaat; je weet niet met welke site je verbinding hebt.
(5) DigiNotar maakt er absoluut een zootje van. Na het grote verwzijgen, de bagatelliserende reacties en het feit dat niet bekend is welke valse certificaten zijn uitgegeven, liep gisteravond en eerder vandaag de klok op hun OSCP server bijna 1 uur achter (dat lijkt nu gefixed), waardoor mensen foutmeldingen konden krijgen die formeel onterecht zijn (alhoewel je dit ook weer als een voordeel kunt zien, namelijk dat niets van DigiNotar nog te vertrouwen is).
(1) Veel overheidswebsites (waaronder as.digid.nl) hebben nog geen probleem doordat het DigiNotar intermediate certificate met serienummer 0x013169B0 nog steeds vertrouwd wordt door uiteindelijk de "Staat der Nederlanden Root CA". Het zou mij niet verbazen als er een fout gemaakt is en het verkeerde certificaat is ingetrokken.
(2) Websites met DigiNotar certificaten die foutmeldingen opleveren hebben het uiteindelijke vertrouwen nodig van ofwel het DigiNotar root certificaat (dat uit steeds meer browsers verwijderd wordt) ofwel hebben het vertrouwen nodig van root certificaten van derde partijen zoals Entrust, die ondertussen het vertrouwen in DigiNotar hebben opgezegd.
(3) Revocation werkt niet. Dit ondermijnt SSL/TLS op zeer ernstige wijze. Zowel browserfabrikanten als CA's zijn schuldig. Bijv. dat de Staat der Nederlanden geen OCSP ondersteunt en er vanuit gaat dat elke 3 maanden een CRL ophalen wel genoeg zal zijn vind ik een blunder. Ten slotte wijst het feit dat URL's voor revocation checks in het certificaat zelf zitten erop dat de ontwerpers geen rekening hebben gehouden met gecompromitteerde CA's.
(4) Als noodmaatregel zie ik instanties self-signed certificaten inzetten (notabene zonder OCSP en CRL erin). Zodra iemand zo'n certificaat toch accepteert en in z'n browser opneemt (default gedrag bij Firefox) zal deze er nooit meer uit verdwijnen. Mocht de private key gestolen worden heb je een groot probleem. Belangrijker is dat dit tegen het (goede) advies van Donner ingaat: accepteer nooit een foutief certificaat; je weet niet met welke site je verbinding hebt.
(5) DigiNotar maakt er absoluut een zootje van. Na het grote verwzijgen, de bagatelliserende reacties en het feit dat niet bekend is welke valse certificaten zijn uitgegeven, liep gisteravond en eerder vandaag de klok op hun OSCP server bijna 1 uur achter (dat lijkt nu gefixed), waardoor mensen foutmeldingen konden krijgen die formeel onterecht zijn (alhoewel je dit ook weer als een voordeel kunt zien, namelijk dat niets van DigiNotar nog te vertrouwen is).
04-09-2011, 20:13 door
Erwtensoep
Mooi topic met heldere uitleg :)
Overigens zit er in Firefox nog een optie om ipv de door het certificaat gespecificeerde OCSP server een andere OCSP server te gebruiken om alle certificaten te controleren(dus ook degenen die helemaal geen OCSP specificeren.)
En nog 2 handige addons voor FF gebruikers zijn Certificate Patrol(onthoud certificaten bij websites en waarschuwt bij een verandering van certificaat: https://addons.mozilla.org/nl/firefox/addon/certificate-patrol) en Perspectives(valideert certificaten middels Network notaries en omzeilt zo een deel van het hele probleem: http://perspectives-project.org/)
Overigens zit er in Firefox nog een optie om ipv de door het certificaat gespecificeerde OCSP server een andere OCSP server te gebruiken om alle certificaten te controleren(dus ook degenen die helemaal geen OCSP specificeren.)
En nog 2 handige addons voor FF gebruikers zijn Certificate Patrol(onthoud certificaten bij websites en waarschuwt bij een verandering van certificaat: https://addons.mozilla.org/nl/firefox/addon/certificate-patrol) en Perspectives(valideert certificaten middels Network notaries en omzeilt zo een deel van het hele probleem: http://perspectives-project.org/)
Ik zit te denken. Hoe erg is het als we geen CA encryptie meer hebben op internet? In de begin jaren van PGP wilde de Amerikaanse overheid niet eens dat de burgers toegang hadden tot sterke encryptie (en daarna maar tot 40 bits).
Als je op een openbare wifi zit is het anders, maar als ik van mijn xs4all adsl aansluiting naar digid.nl ga, maakt het dan wat uit als er geen hangslotje is? Okee, mijn communicatie kan meegelezen en veranderd worden. En ik weet niet (zeker) wie aan de andere kant van mijn verbinding zit. Maar ik kan niets verzinnen wat daar realistisch misbruik van zou kunnen maken. Volgens mij komt mijn verbinding niet eens Nederland uit! Laat staan dat Iran er bij kan.
Dus volgens mij is het geen ramp als we CA's niet meer kunnen vertrouwen. Maar het is wel leuk als we SSL/TLS kunnen blijven gebruiken in de toekomst want dat heeft wel voordelen boven geen encryptie.
Als je op een openbare wifi zit is het anders, maar als ik van mijn xs4all adsl aansluiting naar digid.nl ga, maakt het dan wat uit als er geen hangslotje is? Okee, mijn communicatie kan meegelezen en veranderd worden. En ik weet niet (zeker) wie aan de andere kant van mijn verbinding zit. Maar ik kan niets verzinnen wat daar realistisch misbruik van zou kunnen maken. Volgens mij komt mijn verbinding niet eens Nederland uit! Laat staan dat Iran er bij kan.
Dus volgens mij is het geen ramp als we CA's niet meer kunnen vertrouwen. Maar het is wel leuk als we SSL/TLS kunnen blijven gebruiken in de toekomst want dat heeft wel voordelen boven geen encryptie.
https://as.digid.nl/ maakt nu gebruik van een Getronics (KPN) certificaat. Geldig vanaf 2011-09-04. Het is uitgegeven aan Stichting ICTU. (ICTU is de ICT uitvoeringsorganisatie van Binnenlandse Zaken, geen idee wie de Stichting ICTU is).
https://www.pki.getronicspinkroccade.nl/pkioverheid/cps
https://www.pki.getronicspinkroccade.nl/pkioverheid/cps
Dit is onzin bitwiper.
Wat je schrijft is inhoudelijk geen onzin, maar je mist het punt dat mensen gerust moet stellen.
De zuiverheid van de techniek is nooit of minimaal ter discussie geweest. Het gaat om de zuiverheid van de procedures.
Je zet met zo'n artikel iedereen WEEER op het verkeerde been, verdomme.
Leren sommige mensen het dan nooit?
Geef asjeblieft een aanvulling over de procedures achter het maken van een certificaat: de human en de machine factor. Want DAT is waar het over gaat. Ik kan je nu net zo min meer serieus nemen als diginotaor, en tot een paar uur geleden logius, de overheid etc,
DOE ER IETS AAN!
Er zijn mensen die je stukjes lezen en er waarde aan hechten.
Verdomme.
Wat je schrijft is inhoudelijk geen onzin, maar je mist het punt dat mensen gerust moet stellen.
De zuiverheid van de techniek is nooit of minimaal ter discussie geweest. Het gaat om de zuiverheid van de procedures.
Je zet met zo'n artikel iedereen WEEER op het verkeerde been, verdomme.
Leren sommige mensen het dan nooit?
Geef asjeblieft een aanvulling over de procedures achter het maken van een certificaat: de human en de machine factor. Want DAT is waar het over gaat. Ik kan je nu net zo min meer serieus nemen als diginotaor, en tot een paar uur geleden logius, de overheid etc,
DOE ER IETS AAN!
Er zijn mensen die je stukjes lezen en er waarde aan hechten.
Verdomme.
Kortom:
Alle tot nu toe aangetoond feilen is mensenwerk geweest.
Als je de regels leest voor het gebruik van PKI overheid zit de zaak redelijk dicht.
De certificaten zijn vorig jaar nog eens met een versterkt encryptiemechanisme van deze tijd gemaakt (alleen nieuwe!)
In principe kunnen die dus voorlopig weer even " mee".
Je kunt altijd twisten over de tijd dat je een revoke list moet vernieuwen.
Je moet altijd alert zijn op de gevolgen van een inbraak. Hoe zwaar is de schade.
Van achter kijk je een koe in de kont zei mijn vader altijd, maar volgens mij is de eerste les dat je wellicht je inbraak monitoring moet aanpassen. Daar is software genoeg voor op de markt. Dat noemen we defense in depth.
Wanneer ontdek je dat een vreemde in je netwerk zit te purren. Eenmaal ontdekt: is er al iets gestolen en zo ja wat.
In dit geval zijn er certificaten aangemaakt of gestolen. In een goede logging is te zien welke certificaten er zijn gecompromitteerd of gestolen. Tenzij je logging door de hacker is vernaggeld, maar dan is je infrastructuur niet op orde. Hop de revoking list aangepast. En meteen naar je klanten sturen of indien rechtsreeks aangesloten op de list het ding stoppen, zodat er niet meer op revoke kan worden gechecked en DUS geen enkel certificaat van die leverancier meer zou moeten worden vertrouwd, omdat het revoking mechanisme niet werkt. Een goede PKI kan dit soort zaken uitstekend opvangen. (In de vorm van een waarschuwing en het stoppen van het opzetten van een verbinding).
Iets over de beeldvorming bij het publiek en de ingewikkeldheid van de materie.
Ik zat het verhaal bij NOS journaal te bekijken en had het idee dat van de hele overheid alle informatie van iedereen zomaar te benaderen is. Het leek me al vreemd. Er is bij 1 leverancier van certificaten ingebroken en alles zou niet meer werken. De eerste berichtgeving was voor een leek aanleiding om direct in de stress te springen.
Achteraf blijt het in wezen hetzelfde te zijn als het stelen van blanco paspoorten of het verkrijgen van creditcards na een inbraak. Hiermee heeft de maatschappij (banken en overheden) al ervaring opgedaan.
Resume: Breng je inbraakgevoeligheid naar beneden.
Alle tot nu toe aangetoond feilen is mensenwerk geweest.
Als je de regels leest voor het gebruik van PKI overheid zit de zaak redelijk dicht.
De certificaten zijn vorig jaar nog eens met een versterkt encryptiemechanisme van deze tijd gemaakt (alleen nieuwe!)
In principe kunnen die dus voorlopig weer even " mee".
Je kunt altijd twisten over de tijd dat je een revoke list moet vernieuwen.
Je moet altijd alert zijn op de gevolgen van een inbraak. Hoe zwaar is de schade.
Van achter kijk je een koe in de kont zei mijn vader altijd, maar volgens mij is de eerste les dat je wellicht je inbraak monitoring moet aanpassen. Daar is software genoeg voor op de markt. Dat noemen we defense in depth.
Wanneer ontdek je dat een vreemde in je netwerk zit te purren. Eenmaal ontdekt: is er al iets gestolen en zo ja wat.
In dit geval zijn er certificaten aangemaakt of gestolen. In een goede logging is te zien welke certificaten er zijn gecompromitteerd of gestolen. Tenzij je logging door de hacker is vernaggeld, maar dan is je infrastructuur niet op orde. Hop de revoking list aangepast. En meteen naar je klanten sturen of indien rechtsreeks aangesloten op de list het ding stoppen, zodat er niet meer op revoke kan worden gechecked en DUS geen enkel certificaat van die leverancier meer zou moeten worden vertrouwd, omdat het revoking mechanisme niet werkt. Een goede PKI kan dit soort zaken uitstekend opvangen. (In de vorm van een waarschuwing en het stoppen van het opzetten van een verbinding).
Iets over de beeldvorming bij het publiek en de ingewikkeldheid van de materie.
Ik zat het verhaal bij NOS journaal te bekijken en had het idee dat van de hele overheid alle informatie van iedereen zomaar te benaderen is. Het leek me al vreemd. Er is bij 1 leverancier van certificaten ingebroken en alles zou niet meer werken. De eerste berichtgeving was voor een leek aanleiding om direct in de stress te springen.
Achteraf blijt het in wezen hetzelfde te zijn als het stelen van blanco paspoorten of het verkrijgen van creditcards na een inbraak. Hiermee heeft de maatschappij (banken en overheden) al ervaring opgedaan.
Resume: Breng je inbraakgevoeligheid naar beneden.
05-09-2011, 08:25 door
sjonniev
Het grootste probleem van Diginotar was niet dat ze gehacked waren. Het grootste probleem was dat ze het onder de pet probeerden te houden, hierdoor is het een onbetrouwbaar bedrijf gebleken. Goede aanleiding om op dit punt de wet aan te passen, zodat er een meldplicht in Nederland komt.
Door Anoniem: Dus volgens mij is het geen ramp als we CA's niet meer kunnen vertrouwen. Maar het is wel leuk als we SSL/TLS kunnen blijven gebruiken in de toekomst want dat heeft wel voordelen boven geen encryptie.
Helaas, dat is wel een probleem. Verzin een maximum impact scenario en bekijk wat er kan gebeuren. Om een idee te geven: iemand zorgt via DNS poisoning ervoor dat jij naar de website van een aanvaller wordt geleid op het moment dat jij bankzaken regelt, of wanneer jij je mail wilt lezen. Jij hebt niet in de gaten, want hoewel SSL wordt gebruikt weet je helemaal niet met wie jij nou SSL aan het praten bent.
De aanvaller onderschept je gegevens, voert een frauduleuze transactie uit en jij bent 10000 euro armer. Daarna worden al je e-mails gelezen, doordta je wachtwoord is onderschept, en op Internet gezet. Er zitten vast wel wat berichten bij die je niet wil openbaren. Daarna worden er onterecht nog wat subsiduies aangevraagd en geannuleerd via je DigiD code, hetgeen problemen veroorzaakt met de Belastingdienst. Jij weet die allemaal niet, want jij denkt: ik gebruik SSL en ben dus veilig bezig.
Het enige voordeel is dat veel mensen te oninteressant zijn om lastig te vallen. De belangen zijn echter al snel erg groot, zeker voor banken, overheden en bepaald bedrijven (defensie, verwerkers van medische gegevens etc).
Nog 1 opmerking over Bitwiper's verhaal: de tekst "Met andere woorden, de CA verifieert en garandeert dat de aanbieder van zo'n public key de rechtmatige eigenaar van de betreffende website is." klopt niet. Het enige dat een CA doet is het koppelen van een identiteit aan een public key. Niets meer, niets minder.
05-09-2011, 09:26 door
Thijzzz
Nog een mogelijk rampscenario.
Ik plaats een 300,- linux laptopje, of ander klein device in jouw netwerk (draadloos, of rechtstreeks op je netwerk.)
Daarop staat een DHCP server, die sneller reageert dan je eigen DHCP server op verzoeken.
PC wordt aangezet, en wekelijks wordt de IP-lease verlengd. Nu geeft mijn bakje je echter een antwoord, en je krijgt van mij een IP nummer, maar ook een Default gateway, en DNS server. Jouw pc maakt dat niet uit, maar vanaf nu loopt al jouw pc verkeer via mijn linux bakje.
Ga je naar www.rabobank.nl, krijg je de lokaal geinstalleerde kopie om je oren (of iets op het internet), die echter prima werkt, omdat het bakje over een vervalst certificaat beschikt, dus je komt niet uit op www.rabobakn.nl uit met een rabobakn certificaat, maar je ziet er in de URL balk niks van, en krijgt een heel goed certificaat. (net echt)
Jij gaat lekker bankieren, en mijn man-in-the-middle bakje doet op de achtergrond precies wat jij doet, alleen vertaalt jouw betaling net even anders. Sta je dan met je authenticator.
Onmogelijk? Dit is precies wat Iran doet, alleen staat daar geen linux bakje, maar gewoon een ISP die al het google verkeer direct naar de geheime dienst daar relayed.
Ik plaats een 300,- linux laptopje, of ander klein device in jouw netwerk (draadloos, of rechtstreeks op je netwerk.)
Daarop staat een DHCP server, die sneller reageert dan je eigen DHCP server op verzoeken.
PC wordt aangezet, en wekelijks wordt de IP-lease verlengd. Nu geeft mijn bakje je echter een antwoord, en je krijgt van mij een IP nummer, maar ook een Default gateway, en DNS server. Jouw pc maakt dat niet uit, maar vanaf nu loopt al jouw pc verkeer via mijn linux bakje.
Ga je naar www.rabobank.nl, krijg je de lokaal geinstalleerde kopie om je oren (of iets op het internet), die echter prima werkt, omdat het bakje over een vervalst certificaat beschikt, dus je komt niet uit op www.rabobakn.nl uit met een rabobakn certificaat, maar je ziet er in de URL balk niks van, en krijgt een heel goed certificaat. (net echt)
Jij gaat lekker bankieren, en mijn man-in-the-middle bakje doet op de achtergrond precies wat jij doet, alleen vertaalt jouw betaling net even anders. Sta je dan met je authenticator.
Onmogelijk? Dit is precies wat Iran doet, alleen staat daar geen linux bakje, maar gewoon een ISP die al het google verkeer direct naar de geheime dienst daar relayed.
Als je voor elke https verbinding eerst naar een derde partij gaat om te checken of het certificaat niet is ingetrokken, heeft dat ook privacy implicaties: die partij heeft dan een mooi overzicht wie naar welke site gaat.
Mooi stuk Bitwiper.
Ik zat afgelopen weekeind ongeveer hetzelfde te denken, al die certificaten worden maar voor waar aangenomen. er is geen real time controle van de authenticiteit van het certificaat.
Onlangs lazen we dat het apple OS elk willekeurige password accepteerde voor aanmelding bij een LDAP server, ik zou dit in de zelfde categorie durven gooien maar dan een nivo hoger.
De valse diginotar certificaten zijn voor de gebruiker niet te valideren omdat ze (a) kloppen (wiskundig) en (b) diginotar niet eens weet dat ze bestaan dus ze ook niet kan revoken.
Het PKI concept gaat er gemakshalve van uit dat elk certificaat geldig is tenzij ingetrokken, de revocation kun je (gebrekkig, zoals je illustreert) controleren middels de CRL's, maar de geldigheid van niet ingetrokken certificaten kun je kennelijk niet controleren.
Eigenlijk is deze hele hack wel mooi, geeft weer eens wat stof tot nadenken :-)
Ik zat afgelopen weekeind ongeveer hetzelfde te denken, al die certificaten worden maar voor waar aangenomen. er is geen real time controle van de authenticiteit van het certificaat.
Onlangs lazen we dat het apple OS elk willekeurige password accepteerde voor aanmelding bij een LDAP server, ik zou dit in de zelfde categorie durven gooien maar dan een nivo hoger.
De valse diginotar certificaten zijn voor de gebruiker niet te valideren omdat ze (a) kloppen (wiskundig) en (b) diginotar niet eens weet dat ze bestaan dus ze ook niet kan revoken.
Het PKI concept gaat er gemakshalve van uit dat elk certificaat geldig is tenzij ingetrokken, de revocation kun je (gebrekkig, zoals je illustreert) controleren middels de CRL's, maar de geldigheid van niet ingetrokken certificaten kun je kennelijk niet controleren.
Eigenlijk is deze hele hack wel mooi, geeft weer eens wat stof tot nadenken :-)
CA garandeert eigenaar van public key? Door deze hack is het duidelijk dat dit soort garantie niks voorstelt. Ik vraag me af wat de procedure is om de eigenaar te verifieren?
05-09-2011, 18:45 door
Bitwiper
Dank voor alle positieve en negatieve reacties, en natuurlijk ook dank aan allen die over betere oplossingen filosoferen!
Door Anoniem (2011-09-04 22:44): Wat je schrijft is inhoudelijk geen onzin, maar je mist het punt dat mensen gerust moet stellen.
Waarom moet ik mensen geruststellen? Ik ben zelf een ongeruste gebruiker. Ik probeer alleen uit te leggen hoe e.e.a. werkt en welke omstandigheden aanleiding zijn tot foutmeldingen in webbrowsers en welke niet. Wellicht kun je zelf een verhaal schrijven dat mensen (waaronder mijn persoontje) geruststelt?Door Anoniem (2011-09-05 08:50): Het enige dat een CA doet is het koppelen van een identiteit aan een public key. Niets meer, niets minder.
Als dat zo zou zijn zou ik, of bijvoorbeeld ene "Janam Fadaye Rahbar", gewoon een *.google.com certificaat kunnen kopen. Gelukkig is dat niet zo, zie bijv. regel 1 onder "Verification Practices" in http://www.cabforum.org/Baseline_Requirements_Draft_35.pdf:CabForum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates: The CA or RA MUST confirm that, as of the date the Certificate was issued, the Applicant either had the right to use, or had control of, the Fully-Qualified Domain Name(s) and/or IP address(es) listed in the Certificate, or was authorized by a person having such right or control (e.g. under a Principal-Agent or Licensor-Licensee relationship) to obtain a Certificate containing the Fully-Qualified Domain Name(s) and/or IP address(es).
Ik had onderstaande vragen eerder gesteld bij 1 van de artikelen op deze site over Diginotar. Voorgesteld werd ze in het forum te plaatsen. Inmiddels ontving ik enkele antwoorden, staan hieronder.
Ik heb enkele inhoudelijke vragen over de Diginotar-hack. Ik heb inmiddels veel gelezen maar ik begrijp een aantal zaken niet. Ik ben geen security-deskundige dus ik vraag wellicht naar zeer basale zaken.
1.Op het moment dat een CA gehackt, is de hacker in staat een vals certificaat te genereren (bijv. voor gmail.com). Hoe gaat dan de hacker te werk om bijv. mijn gmail te lezen? Ik zal dan doorverwezen moeten worden naar een andere site dan gmail.com? Hoe verloopt dat? Moet hiervoor dan ook een DNS(?)-hack uitgevoerd worden? In Iran zal dat makkelijk gaan, vermoed ik. Is dat in Nederland ook makkelijk te doen?
2.De gmail-hack werd ontdekt door een Iranier door naar de details van het certificaat te kijken. Hoe kon hij zien dat er iets niets klopte? Kan een leek zien dat er iets niet pluis was?
3.Hoe is het mogelijk dat een Nederlandse CA certificaten voor niet-nederlandse domeinen kan uitgeven? M.a.w. kan elk van 650 CA's voor elk domein als rabobank.nl of abnamro.nl certificaten uitgeven?
Alvast bedankt voor enkele antwoorden. Deze hack maakt mij tamelijk onrustig en ik heb het vermoeden dat de certificerings-business grondig onder de loep genomen moet worden.
Antwoorden:
1 - Ja, die certificaten zijn niks waard als je het verkeer niet omleid. Hiervoor zijn echter een boel methoden. Ouderwetse ARP spoof (LAN), malware die je naar 'proxy' verwijst. Een hack bij een ISP. En waarschijnlijk 10 tallen manieren die ik niet ken.
2 - Volgens mij was dit ontdekt doordat de betreffende persoon had gezien dat in het certificerings pad (de chain) het certificaat van DigiNotar zat. Wat vreemd is, aangezien Thawte dit certificaat normaliter uitgeeft. Als ik me niet vergis was er een plugin voor Firefox. Deze controleerd dan via een andere weg (server) of hetzelfde certificaat wordt geleverd. Dit kan uiteraard ook veel false positives.
3 - Jouw browser (of andere) software houd geen rekening met waar de CA geografisch vandaan komt. Daarmee wordt het dus ook lastig om uitgifte van certs. geografisch te beperken. Het is echter wel mogelijk aan te geven wat voor typen certs een CA mag uitgeven.
Ik heb enkele inhoudelijke vragen over de Diginotar-hack. Ik heb inmiddels veel gelezen maar ik begrijp een aantal zaken niet. Ik ben geen security-deskundige dus ik vraag wellicht naar zeer basale zaken.
1.Op het moment dat een CA gehackt, is de hacker in staat een vals certificaat te genereren (bijv. voor gmail.com). Hoe gaat dan de hacker te werk om bijv. mijn gmail te lezen? Ik zal dan doorverwezen moeten worden naar een andere site dan gmail.com? Hoe verloopt dat? Moet hiervoor dan ook een DNS(?)-hack uitgevoerd worden? In Iran zal dat makkelijk gaan, vermoed ik. Is dat in Nederland ook makkelijk te doen?
2.De gmail-hack werd ontdekt door een Iranier door naar de details van het certificaat te kijken. Hoe kon hij zien dat er iets niets klopte? Kan een leek zien dat er iets niet pluis was?
3.Hoe is het mogelijk dat een Nederlandse CA certificaten voor niet-nederlandse domeinen kan uitgeven? M.a.w. kan elk van 650 CA's voor elk domein als rabobank.nl of abnamro.nl certificaten uitgeven?
Alvast bedankt voor enkele antwoorden. Deze hack maakt mij tamelijk onrustig en ik heb het vermoeden dat de certificerings-business grondig onder de loep genomen moet worden.
Antwoorden:
1 - Ja, die certificaten zijn niks waard als je het verkeer niet omleid. Hiervoor zijn echter een boel methoden. Ouderwetse ARP spoof (LAN), malware die je naar 'proxy' verwijst. Een hack bij een ISP. En waarschijnlijk 10 tallen manieren die ik niet ken.
2 - Volgens mij was dit ontdekt doordat de betreffende persoon had gezien dat in het certificerings pad (de chain) het certificaat van DigiNotar zat. Wat vreemd is, aangezien Thawte dit certificaat normaliter uitgeeft. Als ik me niet vergis was er een plugin voor Firefox. Deze controleerd dan via een andere weg (server) of hetzelfde certificaat wordt geleverd. Dit kan uiteraard ook veel false positives.
3 - Jouw browser (of andere) software houd geen rekening met waar de CA geografisch vandaan komt. Daarmee wordt het dus ook lastig om uitgifte van certs. geografisch te beperken. Het is echter wel mogelijk aan te geven wat voor typen certs een CA mag uitgeven.
Nee, geruststellen kan ik niet. Wat ik wel kan is vertellen dat het systeem theoretisch klopt, maar dat heb kij al gedaan :-)
Als er iets niet klopt is dat altijd het gevolg van menselijk handelen. Dat blijkt ook uit de eerste lekken van de Fox IT rapportage
- root niet offline, check;
- Windows password geeft all access, check;
- externe backup in hetzelfde top level systeem, check;
- password strength vulnerable for dictionary attacks, check;
- full disclosure, mwah, uncheck
Wat uit deze hele charade is gebleken is dat er wel ontzettend veel vermeende kenners op dit forum de afgelopen weken verschrikkelijk op hun bek zijn gegaan met hun statements en antwoorden.
Ik was een van de weinigen die consequent heb gewezen op het vermoeden, inmiddels feit, dat de fabriek zelf in zijn geheel was gecompromitteerd. Sommigen hebben dit heel lang proberen te weerleggen. Ik pak je voorstel daarom op en zal op een rijtje zetten wat er - in aanvulling op het certificaat systeem in louter rekenkundige zin - aanwezig moet zijn om het systeem als geheel te laten functioneren. En dat zijn alleen maar human factors: organisatie en procedures.
Ik zal ook uitleggen dat ik vind dat de overheid precies heeft gedaan wat ze moest doen:
- beetje tijd winnen om de organisatie voor te bereiden (noodzaak)
- meteen naar buiten met info zodra deze bekend werd.
- niet complete of foutieve info meteen corrigeren
- communicatie ultimo via de hoogste instantie.
Dat vraagt nogal wat in een ambtelijk apparaat kan ik je zeggen. Gezien de termijn waarbinnen de minister in eigen persoon naar buiten trad is hier waarschijnlijk een hele hoge nationale alarmfase van kracht geweest (is!).
Dat laatste zal ook binnenkort wel naar buiten komen.
Ik mail het morgen wel aan de redactie of plaats het hier.
Als er iets niet klopt is dat altijd het gevolg van menselijk handelen. Dat blijkt ook uit de eerste lekken van de Fox IT rapportage
- root niet offline, check;
- Windows password geeft all access, check;
- externe backup in hetzelfde top level systeem, check;
- password strength vulnerable for dictionary attacks, check;
- full disclosure, mwah, uncheck
Wat uit deze hele charade is gebleken is dat er wel ontzettend veel vermeende kenners op dit forum de afgelopen weken verschrikkelijk op hun bek zijn gegaan met hun statements en antwoorden.
Ik was een van de weinigen die consequent heb gewezen op het vermoeden, inmiddels feit, dat de fabriek zelf in zijn geheel was gecompromitteerd. Sommigen hebben dit heel lang proberen te weerleggen. Ik pak je voorstel daarom op en zal op een rijtje zetten wat er - in aanvulling op het certificaat systeem in louter rekenkundige zin - aanwezig moet zijn om het systeem als geheel te laten functioneren. En dat zijn alleen maar human factors: organisatie en procedures.
Ik zal ook uitleggen dat ik vind dat de overheid precies heeft gedaan wat ze moest doen:
- beetje tijd winnen om de organisatie voor te bereiden (noodzaak)
- meteen naar buiten met info zodra deze bekend werd.
- niet complete of foutieve info meteen corrigeren
- communicatie ultimo via de hoogste instantie.
Dat vraagt nogal wat in een ambtelijk apparaat kan ik je zeggen. Gezien de termijn waarbinnen de minister in eigen persoon naar buiten trad is hier waarschijnlijk een hele hoge nationale alarmfase van kracht geweest (is!).
Dat laatste zal ook binnenkort wel naar buiten komen.
Ik mail het morgen wel aan de redactie of plaats het hier.
05-09-2011, 23:03 door
Bitwiper
Aanvullingen:
Door Anoniem: 1 - Ja, die certificaten zijn niks waard als je het verkeer niet omleid. Hiervoor zijn echter een boel methoden. Ouderwetse ARP spoof (LAN), malware die je naar 'proxy' verwijst. Een hack bij een ISP. En waarschijnlijk 10 tallen manieren die ik niet ken.
Grotere DNS aanvallen komen echt voor. Zo werd gisteren nog verkeer bestemd voor o.a. upc.com en www.theregister.co.uk naar een onjuist IP-adres gestuurd (zie de 2e bijdage, d.w.z. de 1e reactie, in https://secure.security.nl/artikel/38357/1/Verdrietig_over_PKIoverheid.html). Daarnaast zijn dit soort aanvallen heel eenvoudig uit te voeren op openbare of slecht beveiligde WiFi netwerken. Ten slotte fungeren veel ADSL/kabel routers als DHCP- en DNS server, en vaak zijn deze niet goed beveiligd. Zie bijvoorbeeld http://www.h-online.com/security/news/item/UPnP-enabled-routers-allow-attacks-on-LANs-1329727.html.2 - Volgens mij [...]
Nee, naar verluidt is het ontdekt door Iraniërs die Google Chrome gebruiken. Die webbrowser blijkt voor google.com uitgegeven certificaten, naast op de gebuikelijke methode, ook nog aan een hard-coded check te onderwerpen. Daardoor kregen Iraniërs die deze webbrowser gebruikten waarschuwingen op het moment dat de aanvallen plaatsvonden (dat was, naar verluidt, slechts af en toe). Voor de bron zie de tweede URL in https://secure.security.nl/artikel/38285/1/Iran_Google_MITM_Diginotar_cert%3F.html.3 - Jouw browser (of andere) software houd geen rekening met waar de CA geografisch vandaan komt. Daarmee wordt het dus ook lastig om uitgifte van certs. geografisch te beperken. Het is echter wel mogelijk aan te geven wat voor typen certs een CA mag uitgeven.
Klopt. In jouw browser zit bijvoorbeeld ook een certificaat van de Chinese CNNIC, die een allesbehalve goede reputatie heeft (zie http://en.wikipedia.org/wiki/China_Internet_Network_Information_Center#Malware_Production_And_Distribution). Alleen fatsoen belet hen om certificaten uit te geven voor bijvoorbeeld digid.nl.Door Anoniem: 2.De gmail-hack werd ontdekt door een Iranier door naar de details van het certificaat te kijken. Hoe kon hij zien dat er iets niets klopte? Kan een leek zien dat er iets niet pluis was?
De Iraniëre gebruikte Google Chrome. Chrome maakt sinds versie 13 gebruik van HTTPS pins voor het eigen domein. Klopt de root CA in het certificeringspad niet met de root CA die in de broncode van Chrome staat vermeld, dan verschijnt een waarschuwing, ook al is het certificaat verder in orde. Zie http://www.imperialviolet.org/2011/05/04/pinning.html.
Door Anoniem (2011-09-05 08:50): Het enige dat een CA doet is het koppelen van een identiteit aan een public key. Niets meer, niets minder.
Als dat zo zou zijn zou ik, of bijvoorbeeld ene "Janam Fadaye Rahbar", gewoon een *.google.com certificaat kunnen kopen. Gelukkig is dat niet zo, zie bijv. regel 1 onder "Verification Practices" in http://www.cabforum.org/Baseline_Requirements_Draft_35.pdf:CabForum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates: The CA or RA MUST confirm that, as of the date the Certificate was issued, the Applicant either had the right to use, or had control of, the Fully-Qualified Domain Name(s) and/or IP address(es) listed in the Certificate, or was authorized by a person having such right or control (e.g. under a Principal-Agent or Licensor-Licensee relationship) to obtain a Certificate containing the Fully-Qualified Domain Name(s) and/or IP address(es).
Kopen ... dat is een breed begrip. Wat dacht je van een GeoRoot (www.geotrust.com) die je de mogelijkheid geeft om ieder willekeurig certificaat aan te maken? De enige eis die Geotrust (en andere intermediate root vendoren) hier aan stellen is dat je 'beloofd' geen illegale certificaten uit te geven...
--Jeroen
07-09-2011, 00:04 door
westd05
Bitwiper, bedankt voor je uitvoerige uitleg! Mooi topic!
07-09-2011, 01:05 door
Bitwiper
Door Anoniem: Kopen ... dat is een breed begrip. Wat dacht je van een GeoRoot (www.geotrust.com) die je de mogelijkheid geeft om ieder willekeurig certificaat aan te maken? De enige eis die Geotrust (en andere intermediate root vendoren) hier aan stellen is dat je 'beloofd' geen illegale certificaten uit te geven...
--Jeroen
Je zult mij niet horen zeggen dat het systeem met CA's goed in elkaar zit. Etisalat kan ook certifcaten uitgeven en heeft daar al misbruik van gemaakt (http://www.eff.org/deeplinks/2010/08/open-letter-verizon), en een CNNIC root cert in alle webbrowsers is ook echt niet fijn (zie http://en.wikipedia.org/wiki/China_Internet_Network_Information_Center#Malware_Production_And_Distribution).--Jeroen
Van GeoTrust vermoed (hoop) ik echter dat ze een sub-root cert van een reseller (ik neem aan dat je http://www.geotrust.com/sell-ssl-certificates/contract-options.html bedoelt) zullen intrekken zodra die reseller er een potje van maakt.
Door westd05: Bitwiper, bedankt voor je uitvoerige uitleg! Mooi topic!
Graag gedaan!
07-09-2011, 02:29 door
Bitwiper
Voor het gedrag van een handmatige geupdate MSIE8 en Firefox 3.6.22 zie mijn 1e bijdrage in http://www.security.nl/artikel/38386/1/Firefox_6.0.2.html.
Correctie 2011-09-07 19:05: Firefox 3.2.22 moet natuurlijk 3.6.22 zijn, sorry.
Correctie 2011-09-07 19:05: Firefox 3.2.22 moet natuurlijk 3.6.22 zijn, sorry.
Welke check waar (URL) kan worden uitgevoerd staat in het betreffende certificaat. Dat vind ik een enorme design error (de URL in het parent certificaat zou gebruikt moeten worden). Het is wachten op slimme CA-hackers die in buitgemaakte certificaten hun eigen server als CRL/OCSP handler opgeven (dan werkt revocation echt helemaal niet meer).
Dat dacht ik zelf ook, maar toch is er nog een ontsnappingsmogelijkheid.
In het geval van de Diginotar hack kan nog wel de CRL locatie gebruikt worden die in het Diginotar certificaat zelf genoemd staat. Dit certificaat is namelijk niet vervalst, de private key gestolen, echter de ondertekening door "Staat der Nederlanden Overheid CA" garandeert dat de CRL locatie in het diginotar certificaat zelf niet vervalst is. Dit kan dus nog gecheckt worden waaruit dan kan blijken dat het Diginotar certificaat is ingetrokken.
Een gebruiker moet dus altijd de gehele certificaten keten met CRL en OCSP nakijken, niet alleen het laagst gelegen certificaat.
Echter met DNS poisoning kan wel het verkeerde IP-adres behorende bij de bestemming in het CRL distribution point worden weergegeven. Dit biedt de mogelijkheid om een totdat de CRL daadwerkelijk verlopen is volgens de verloopdatum een oude CRL op te dienen aan de vragers. Dit kan 3 maanden ruimte geven aan een hacker.
Voor OCSP is dit weer moeilijker te faken wegens dat requests hier naartoe geheel uniek gemaakt kunnen worden middels de Nonce welke dan ook in het antwoord terug zou moeten komen.
In de praktijk heb ik echter gezien dat zowel Getronics-PinkRoccade als ook Diginotar zelf altijd de waarde null als Nonce meegeven, ongeacht wat in de request zelf als Nonce waarde staat. Dit waarschijnlijk wegens performance redenen omdat voor iedere request een aparte handtekening maken een relatief langzame operatie is die veel performance vereist. Het verzonden antwoord is in de praktijk recent of tot enkele dagen oud (volgens thisUpdate). De nextUpdate datum van de response staat in de praktijk vaak op null (Getronics + Diginotar), dus men moet zelf bepalen tot hoelang het antwoord van een OCSP server betrouwbaar gevonden wordt. Dit kan enkele dagen ruimte geven aan een hacker.
Afhankelijk van het doel van de hacker kan dit in de praktijk genoeg ruimte zijn.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
