De betrouwbaarheid van DigiD neemt af. Zie mijn eerdere reactie in https://security.nl/posting/790326.

Later las ik in https://www.logius.nl/domeinen/toegang/digid/documentatie/factsheet-dv-en-ov-certificaten-bij-digid dat, sinds vorig jaar, DV (Domain Validated) https servercertificaten goed genoeg zijn.

Oftewel, als een cybercrimineel schrijftoegang verkrijgt tot de DNS-records van een site waar je met DigiD kunt inloggen, kan deze een nepsite optuigen (als "evil proxy") en daarna, binnen zeer korte tijd, het DNS record naar diens eigen server laten wijzen en daar (in een oogwenk, gratis en no questions asked) eveneens een DV-certificaat opzetten. Voor elke gebruiker die daarop inlogt kan de aanvaller hetzelfde als die gebruiker op de echte website.

In plaats van een aanval via DNS kan dit ook met een BGP-hijack.

Burgers moeten met steeds grotere betrouwbaarheid inloggen, terwijl de betrouwbaarheidseisen aan de andere kant steeds verder worden afgezwakt. Rara wie lopen hier de risico's?

Aanvulling 11:16, uit laatstgenoemde Logius pagina:
Als zelfs de "experts" (Logius) niet meer begrijpen waar een https servercertificaat voor bedoeld is, zijn we m.i. reddeloos verloren.

Vandaar dat ik voorstander ben van het Europese Qualified Web Authenticatie Certificaat (QWAC).
Inclusief de verplichting voor bigtech om die in hun truststores op te nemen.
Dat kan heel gemakkelijk door het Europese register van Qualified CA's naar die truststores te vertalen.

En dit moet ook gelden voor alle andere gekwalificeerde certificaten voor al die andere doelen.

En hoe zie ik in mijn webbrowser dat een website gebruik maakt van zo'n (Alfred Jodocus) QWAC, en hoe zie ik wie de geregistreerde organisatie is?

Een domeinnaam in een URL is immers (behoudens enkele uitzonderingen, zoals "bol.com") niks meer dan een pseudoniem, en dat is precies wat phishing zo eenvoudig maakt.

Leuk verhaal Erik, in de praktijk maakt het geen drol uit.

Ook toen Logius nog PKIoverheid afdwong voor aansluithouders was dat risico aanwezig. Een eindgebruiker kijkt niet inhoudelijk naar het certificaat zolang de browser nergens over mekkert. Niet voor niets is de groene adresbalk voor EV verdwenen, men kwam tot de conclusie dat het gedrag niet verandert en dat het dus een in de praktijk nutteloze toevoeging was.

Overigens goed om te vermelden, daadwerkelijke DigiD authenticatie gebeurt op digid.nl, niet op de website van de aansluithouder. Communicatie is op basis van SAML 2.0.

Dat is een foute uitspraak. "De meeste gebruikers kijken niet naar het certificaat..." wil ik geloven.

"Men" is vooral Google. En ook hier geldt dat er wel degelijk mensen zijn die hier op letten. Veel (ik weet niet welke niet) Nederlandse banken gebruiken nog steeds een EV-certificaat, wat ik hartstikke verstandig vind en op prijs stel.

De stommiteit bij PKI-Overheid was dat zij heel lang géén EV-certificaten ondersteunden, en dat pas gingen doen toen Google de groene balk begroef. Met als belangrijkste "reden" dat de VS geen fatsoenlijke federale KvK heeft.


Fijn. Maar bij Cloudflare is er op dit moment een tweede server met een https servercertificaat dat geldig is voor zowel:
• mijnkeizerkliniek.nl
• *.mijnkeizerkliniek.nl
waarbij www.mijnkeizerkliniek.nl resolvt naar die server. Ik weet (nog) te weinig van SAML 2.0 maar als iemand met toegang tot de CloudFlare infrastructuur kwaad wil en https://www.mijnkeizerkliniek.nl (188.114.97.0) niet doorstuurt naar https://mijnkeizerkliniek.nl (84.241.179.155) maar als reverse proxy naar die site werkt, dan weet ik niet of DigiD je na inloggen terugstuurt naar waar je vandaan kwam, www.mijnkeizerkliniek.nl (en de aanvaller kan wat jij kan), of jou doorstuurt naar de bedoelde "echte" site mijnkeizerkliniek.nl.

Na een hack van het DNS record van mijnkeizerkliniek.nl (of een BGP-hijack) kunnen ook ervaren internetters niet meer zien of hun browser de echte mijnkeizerkliniek.nl toont, of een "evil proxy" - want zowel echt als nep hebben een DV-cert.

En als DigiD de gebruiker onvoorwaardelijk terugstuurt (bijv. naar evilproxy.example.com) is het systeem zo lek als een mandje.

Als het goed is er een trust relatie tussen de site die je bezoekt (i.e. de SP) en DigiD (i.e. de IdP), over en weer op basis van PKI. Het zou niet zo moeten zijn dat de echte DigiD IdP een verzoek honoreert van een onvertrouwde SP (de evil proxy), laat staan dat deze na authenticatie terug redirect naar deze evil proxy. Dat is zo, wanneer alleen authenticatie geinitieerd door een SP gehonoreerd worden en authenticatieverzoeken die direct via de IDP lopen niet worden gehonoreerd. In het laatste geval loop je kans op een MitM attack (zie ook https://www.identityserver.com/articles/the-dangers-of-saml-idp-initiated-sso).

Nu weet ik niet of DigiD IdP initiated authenticatie honoreert of niet en wat de eventuele maatregelen zijn die ze dan genomen hebben om de risico's te mitigeren. Daarvoor zou je dan denk ik in de DigiD SAML implementatie moeten duiken, maar daar heb ik op dit moment geen tijd voor.

@Erik van Straten

Heb je het probleem bij Logius gemeld?

Wat zeggen ze daar?

Grappig, die link die je noemt heb ik een paar dagen geleden ook gevonden.

Als ik het goed begrijp is er een "driehoeksrelatie" tussen:
1) browser (van burger) <—> service provider
2) browser (van burger) <—> digid.nl
3) digid.nl <—> SP (bijv. mijnkeizerkliniek.nl)

In de tijd, als ik het goed begrijp (ik weet niet precies wanneer 3 plaatsvindt):

Een AitM zou tussen de browser en de SP kunnen zitten:

Als de SP mijnkeizerkliniek.nl is en de AitM bijvoorbeeld mijnkeizerkliniek.xyz heet, en DigiD de burger terugstuurt naar mijnkeizerkliniek.xyz (niet opdraagt om naar de geregistreerde mijnkeizerkliniek.nl te gaan), verkrijgt de AitM het session cookie.

Dit wordt ook wel "Phishing 2.0" genoemd (zie https://www.ubisecure.com/security/phishing-2-0/ waarbij die auteur verwijs naar een artikel van Kuba Gretzky, de auteur van Evilginx in https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens/).

Dit werkt prima bij zwakke MFA (SMS, TOTP), maar of het bij DigiD werkt weet ik niet; ik lees het graag als de beschreven truc niet werkt.

De afpersing is gestopt: moeten betalen voor iets wat je onder dwang moet gebruiken.
Het lijkt wel op de 'linnen verhuur' en de restauranthouders uit maffia films.

Bij SAML 2.0 wissel je eerst de metadata met elkaar uit met daarin een certificaat (public key). Voor DigiD dient hierin een certificaat gebruikt te worden uitgegeven onder het PKIoverheid G1 private vertrouwensketen, verschillend voor acceptatie en productie.

Als een eindgebruiker gaat inloggen, dan stuurt de SP stuurt een digitaal ondertekend authenticatiebericht welke wordt geverifieerd voordat het bericht verwerkt wordt. Bovendien registreer je ook de ACS URL, dus het systeem van DigiD stuurt alleen daar de SAML response naar terug.

Vwb EV ben ik het met je eens hoor, laat ik dat voorop stellen. Jij kijkt naar dat certificaat (ik ook trouwens), maar 98 van de 100 anderen niet. Dat is gewoon de praktijk. Op mobiele apparaten is het ook nog ingewikkelder / minder toegankelijk dan een desktop browser.

Zodat de EU overal een MITM attack kan uitvoeren? Nee laat maar.

Stop eens met de aandacht naar je toe te trekken. Het artikel gaat over heel iets anders!

Die truc werkt alleen als je ook over de private key van de SP beschikt en de DNS weet aan te passen oid. Zoals ik al had gesteld is er een vertrouwensrelatie over en weer tussen SP en IdP op basis van PKI. De SP signed het request, de IdP controleert dan of de signature klopt bij de bijbehorende SP. Als dit ok is dan wordt de authenticatie uitgevoerd. De response wordt gesigned door de IdP. De SP moet dit weer controleren.

Verder wordt er alleen teruggeredirect naar vertrouwde partijen door DigiD. Er vindt eerst een onboarding traject plaats.

Zie ook https://www.logius.nl/domeinen/toegang/digid/documentatie/koppelvlakspecificatie-digid-saml-authenticatie#signing-vercijferalgoritmes-hashfuncties. Ik zie hier overigens ook dat IdP Initiated authenticatie niet wordt ondersteund.