Uitleg DigiNotar problematiek
04-09-2011,14:52 door
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:
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.
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.
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.
