Geef mij maar self signed certificaten. Dan wordt je tenminste bij elk nieuw certificaat gedwongen om na te gaan of de site betrouwbaar is.

Het root certificaat van CloudFlare is van GlobalSign. Die heb ik direct maar als onbetrouwbaar gekenmerkt in mijn systeem, zodat alle afgeleide certificaten een waarschuwing genereren.

@Briolet
GlobalSign dat is er 1 voor de normale gebruiker: to big to fail.

Ik verwacht dat je wel zo nu en dan een melding gaat krijgen.

Het enige dat bijzonder is bij CloudFlare is dat de certificaten bij hen gratis zijn. Voor de rest wordt er niet meer of minder controle toegepast dan een groot aantal (op gevoel zou ik zeggen: de meeste) andere CA's, namelijk of de certificaatondertekeningsaanvrager ook eigenaar is van het domein.

In dit geval zijn de eigenaars van de phishingsite inderdaad in het bezit van het domein, dus is het certificaat "terecht" afgegeven.

Wablief? Een certificaat is bedoeld voor de beveiliging van de verbinding, niet voor de betrouwbaarheid van de website. CloudFlare vindt dat iedereen recht heeft op encryptie zonder bemoeienis of voorafgaande controle van derden, en terecht.

Een normaal certificaat hoort alleen te controleren of de domeinnaam bij de private sleutel hoort, en is geen antecedentenonderzoek naar de domeinnaamhouder. Alleen dan wordt encryptie schaalbaar en houden we tevens de vrijheid van publicatie op het internet in stand.

Als Briolet zo graag op links in e-mails wil klikken, moet hij simpelweg niet alleen het "https" controleren maar ook de domeinnaam. Dat is de enige weg voorwaarts.

Een certificaat is niet bedoeld voor de beveiliging van de verbinding.

Dat klopt een beetje.

Het doel van een SSL certificaat is dat derden, met "enige" betrouwbaarheid, kunnen vaststellen dat de domeinnaam van een website daadwerkelijk toebehoort aan een specifieke organisatie. Bijv. in het certificaat van mijn.ing.nl vind je onder meer de volgende informatie ("CN"=common name, domeinnaam in dit geval, en "O"=organisatie):


Het type betreffende EV-certificaat hoort hierbij een minimale garantie te bieden voor het vertrouwen dat je, als gebruiker, mag hebben dat je daadwerkelijk met een site van ING BANK N.V. communiceert als de URL in jouw webbrowser begint met "https://mijn.ing.nl/".

Het middel om een website te authenticeren middels een X.509 certificaat, is een public key in het gesigneerde deel van het certificaat, waarbij de eigenaar van de website, elke connectie opnieuw, aantoont over de bijbehorende private key te beschikken (en waarbij je moet hopen dat die private key niet in verkeerde handen valt).

Terug naar het doel: bij een self-signed certificaat is die betrouwbaarheid nul, en bij een gratis Cloudflare certificaat is dat niet veel hoger. Ook "domain-validated" zegt niet zoveel. EV-certificaten suggereren een hogere betrouwbaarheid bij de "echtheid" van een site, maar de implementatie daarvan in webbrowsers is compleet brak.

Het eerste grote probleem met certificaten is dat webbrowsers te beperkt zichtbaar onderscheid maken tussen soorten certificaten (d.w.z. hoe nauwkeurig de certificaatuitgever heeft vastgesteld dat de domeinnaam aan de betreffende organisatie toebehoort, en dat de aanvrager gerechtigd is dat certificaat aan te vragen namens die organisatie), waardoor voor gebruikers het "server authenticatieniveau" niet duidelijk is.

Als gebruiker kun je in zo'n certificaat zoeken naar een "CPS" (Certification Practice Statement) URL. In het certificaat van mijn.ing.nl is dat https://d.symcb.com/cps. Daarin vind je wat de certificate provider doet voordat deze een certrificaat "uitgeeft" (feitelijk een "certificate signing request" digitaal ondertekent waarmee de browser de echtheid van dat certificaat kan controleren). In de praktijk gaat een doorsnee gebruiker niet op zoek naar dergelijke informatie (ik vermoed dat slechts weinigen beseffen dat dit soort informatie überhaupt beschikbaar is).

Ronduit verwarrend is dat http geen foutmelding geeft, en https met een self-signed certificaat wel. Die waarschuwing is domweg een zwaktebod in de plaats van een indicator van de betrouwbaarheid waarmee de identiteit van de site is vastgesteld (is geauthenticeerd). Ooit zullen gebruikers, en daardoor webbrowser fabrikanten, inzien dat zo'n visuele "authenticiteits-betrouwbaarheid-indicator" onmisbaar is, en zal deze worden toegevoegd.

Pas nadat de website is geauthenticeerd heeft het zin (en is het een goed idee) om de verbinding met die site te versleutelen. Op zich heeft het certificaat weinig tot niets te maken met de versleutelde verbinding (bij een Diffie-Hellman key agreement wordt helemaal niets uit het certificaat gebruikt bij de uiteindelijke versleuteling).

Erik, daarmee kan ik het toch niet helemaal eens zijn. Het certificaat dient voor de authenticatie van de server, m.a.w. is de partij waarmee je communiceert, werkelijk de partij die je verwacht a.d.h.v. de domeinnaam die je gebruikt hebt bij het opzetten van de verbinding? Of zit er een man-in-the-middle tussen die de communicatie kan lezen en manipuleren? Als die authenticatiecontrole door de client lukt, kan er op basis van de informatie (publieke sleutel) in het certificaat een geheim afgesproken worden tussen client en server, een geheim dat ook werkelijk geheim is, tenzij de private sleutel van het certificaat niet meer geheim zou zijn. Op basis van dat afgesproken geheim kan dan een geëncrypteerde end-to-end-verbinding opgezet worden, een "veilige" verbinding waarbij je er als gebruiker zeker van mag zijn dat de informatie die je naar de server stuurt en van de server ontvangt, niet-leesbaar en niet-manipuleerbaar is op de netwerkverbinding tussen je client en die server. In die zin is het certificaat essentieel voor de beveiliging van de verbinding.

Er is echter geen garantie over de kwaliteit van de informatie die uitgewisseld wordt, enkel dat ze niet onderweg gemanipuleerd is. (Vandaar dat de veronderstelling die de gebruikers in het artikel lijken te maken, onzin is.)

Anderzijds is de betrouwbaarheid van de authenticatie ook afhankelijk van de rigoureusheid waarmee de CA die het certificaat ondertekend heeft, heeft gevalideerd of de aanvrager van het certificaat ook de eigenaar van de domeinnaam is. Als een getekend certificaat in handen komt van iemand anders dan de eigenaar (iemand die zo'n certificaat (een soort duplicaat) aanvroeg en ook onterecht kreeg door gebrekkige validatie, of iemand die de private key van het reguliere certificaat wist te bemachtigen terwijl het certificaat zelf publiek beschikbaar is), kan je als gebruiker —zonder daarover gewaarschuwd te worden door je client-software— een beveiligde verbinding opzetten met een onbetrouwbare partij. Wat natuurlijk ook ongewenst is.