Beveiligingsbedrijf komt met dienst om certificaten voor domeinen te controleren

Het Nederlandse beveiligingsbedrijf Computest introduceert een gratis dienst waarmee domeineigenaren kunnen bijhouden welke certificaten voor hun domeinen worden uitgegeven. Zo moeten zij in staat zijn om snel valse certificaten op te sporen.

Naar eigen zeggen is het idee voor de dienst ontstaan nadat het bedrijf een kwetsbaarheid in de StartEncrypt-tool had ontdekt, waarmee valse certificaten aangemaakt konden worden. Daarnaast geven de problemen die zijn ontstaan rond de certificaatautoriteiten WoSign en Startcom aan dat er fouten kunnen ontstaan die lange tijd onopgemerkt blijven, zo legt Christiaan Ottow van Computest aan Tweakers uit. "De vraag was eigenlijk: wat kan ik zelf doen om mijn domein te beveiligen?", voegt hij daaraan toe. Door een vals certificaat te gebruiken, kan een aanvaller bijvoorbeeld gegevensverkeer onderscheppen door een man-in-the-middle-aanval uit te voeren.

De tool met de naam Suricat doorzoekt op dit moment de logs op de grootste CT-server van Google, bekend onder de naam 'Aviator'. Daarin publiceren certificaatautoriteiten welke digitale certificaten zij uitgeven voor bepaalde domeinen. Doordat een gebruiker zich aanmeldt bij de dienst met alleen een e-mailadres en een domeinnaam, krijgt hij een bericht zodra er een nieuw certificaat voor zijn domein is geregistreerd. "De dienst is geen totaaloplossing, in het geval van WoSign bleek onder andere dat zij hadden toegezegd de certificaten in de CT-logs te publiceren, maar deden zij dit niet", zegt Ottow.

In de toekomst wil hij nog meer functies aan de dienst toevoegen. Zo wil Ottow dat Suricat meer CT-logs doorzoekt dan alleen de grootste Google-server. Dit zou in de komende weken te realiseren zijn, schat hij. Daarnaast wil hij, net als vergelijkbare monitoringdiensten, de mogelijkheid bieden om de database van de dienst te doorzoeken, zodat meteen duidelijk is welke certificaten voor een domein zijn geregistreerd. De dienst van Computest zou van bestaande vergelijkbare diensten verschillen door zijn notificatiefunctie en zijn gratis beschikbaarheid. Daarnaast staat het gebruiksgemak voorop: "Een beetje zoals haveibeenpwned van Troy Hunt, waar je ook alleen een e-mailadres hoeft in te voeren", zegt Ottow.

Hij legt uit dat Computest de opgegeven gegevens alleen opslaat in een database en deze niet zal gebruiken voor marketingdoeleinden, los van informatie over de dienst zelf.

Reacties (22)

Op het moment dat je met HPKP je certificate pint in je headers, kan een derde partij al geen certificaat meer implementeren voor je domein zonder dat browsers (die al eerder op de site zijn geweest) weigeren de pagina te laden. Plus als de browsers binnenkort op DANE/TLSA gaan controleren is het helemaal niet meer mogelijk om valse certificaten uit te geven die werken.
De hierboven genoemde dienst lijkt me interessant voor nieuwsgierige mensen die willen weten wie er pogingen doet om valse certs te implementeren, maar beslist niet essentieel: we hebben immers al HPKP en binnenkort DANE/TLSA in de browsers.

[Reactie gewijzigd door Hans van Eijsden op 18 oktober 2016 14:06]

Binnenkort DANE en TSLA? Ik zou het graag, héél graag zien, maar tot op heden zie ik weinig beweging bij Mozilla, Google en Microsoft.

Met DANE zouden we direct de hele CA's buiten spel zetten, wat een geweldige stap zou zijn, maar het gebeurd gewoon nog niet.

Net zoals dat DNSSEC nog niet écht wil opschieten en dat is wel een essentieel onderdeel van DANE, want zonder DNSSEC geen veilige TLSA records.

Net zoals dat DNSSEC nog niet écht wil opschieten en dat is wel een essentieel onderdeel van DANE, want zonder DNSSEC geen veilige TLSA records.

Ik heb het gevoel dat e-mail de drijvende motor gaat zijn achter DANE en daarmee ook DNSSEC.
Voor webbrowsers hebben we een hele boel middelen om met de gebreken van HTTPS/SSL om te gaan. Ik heb het dan over technieken als HSTS en HPKP maar ook dat er een mens achter de computer zit om moeilijke beslissingen te nemen ("toch doorgaan ja/nee?)".

E-mail heeft dat allemaal niet. Erger nog, in de wereld van e-mail is het heel gebruikelijk om een fallback naar plaintekst te doen, die fallback is eigenlijk niet optioneel maar de facto verplicht. Browsers hebben dat zelfs nooit gedaan. Dat maakt het haast onmogelijk om het probleem op te lossen met de bestaande middelen.

E-mail security wordt steeds belangrijker, wat dat betreft heeft het Clinton e-mail-schandaal wel geholpen om aandacht voor dit onderwerp te krijgen (al gaat dat eigenlijk ergens anders over). GMail geeft tegenwoordig bijvoorbeeld aan of de mail via een beveiligde verbinding is verzonden. Helaas zegt dat niet zo heel veel.
Een tijd lang hebben we nog gehoopt dat end-to-end-encryptie (PGP / SMIME) ons zou redden maar dat is dusver ook geen succces geweest.

Al met al is de nood in e-mailland hoog. DANE/DNSSEC kunnen veel problemen wegnemen. Dat neemt niet weg dat er nog een hoop moet gebeuren. Gelukkig wonen wij in Nederland waar DNSSEC wél is aangeslagen. De rest van de wereld kunnen we nog niet helpen, maar binnen Nederland ligt het binnen handbereik.

HPKP wordt nagenoeg niet toegepast. Zie ook de blog van Ivan Ristic/Qualys van september: https://blog.qualys.com/s...p-public-key-pinning-dead

Heb het zelf geconfigureerd, maar het is nogal een PITA qua configuratie werk en de gevolgen kunnen nogal desastreus zijn. Een van de zaken die ik absoluut nog niet in mijn Ansible deployments op werk mee zou willen nemen.

Als ik het goed begrijp doet dit systeem weinig meer dan kijken in bepaalde registers/databases of een certificaat is aangemaakt voor een specifiek domein. Opzich leuk, maar dat heeft natuurlijk weinig nut wanneer een CA gehacked is en er bewust niet wordt gerapporteerd naar een CT-server.

Kortom, waterdicht is dit zeker niet.

uiteraard blijft er altijd een risico aanwezig, maar het is wel erg prettig te weten dat er een certificaat gemaakt word voor jouw domein (zei het door een gerespecteerde partij) die niet door jou geinitieerd is. Dan weet je dus dat er wat fout gaat, of dat er mensen zijn die je site als doelwit gebruiken.

Niet helemaal. De registers van Certificate Transparancy worden niet alleen gevuld door de CA's zelf maar ook door bijv. Chrome browser. Die uploadt in bepaalde situaties certificaten van publieke websites naar CT. Zo kan een corrupte CA mogelijk toch betrapt worden. Ik kan zo gauw geen informatie vinden over wanneer Chrome dat wel en niet doet en weet ook niet of dat alleen voor 'bekende' sites zoals Gmail gebeurt.

Een halve paraplu is nog altijd beter dan geen paraplu

Hij legt uit dat Computest de opgegeven gegevens alleen opslaat in een database en deze niet zal gebruiken voor marketingdoeleinden, los van informatie over de dienst zelf.

Ergens apart dat de 'terms and conditions' wel leesbaar zijn, maar ik in PDF geen link kan vinden naar de 'Privacy Statement', waarin dit zou staan.

Bedoel je dat linkje op de homepage links onderin, die naar deze PDF linkt?
https://suricat.io/static/privacypolicy.pdf

OT:
Op zich is het een vrij simpele tool die 'enkele' logs doorzoekt. Natuurlijk is het niet helemaal waterdicht, maar de meeste professionele site beheerders, zullen echt wel door bepaalde dingen heen kunnen prikken als iets wel of niet klopt.

Deze dienst klinkt leuk, maar biedt als ik het zo snel zie geen beveiliging als:
- Een CA niet publiceert dat ze een certificaat hebben uitgegeven
- Een websitehouder er niet voor kiest om op de hoogte te worden gehouden

Dit heeft volgens mij wel wat overeenkomsten met de SSL Observatory functie van HTTPS Everywhere.

Deze zin komt ook niet echt overtuigend over:
"We periodically scrape several Certificate Transparency servers (is the plan, for now it's just Google Aviator), and search for your domain in those logs."

Na het invullen van je e-mailadres wordt er (nog) geen bevestiging gestuurd. Je kunt dus ook iemand anders abonneren, of een typfout maken en daar pas later achter komen.

Ik heb wel een registratie mailtje ontvangen. Wellicht is die van jou nog onderweg?

Ik kreeg wel een mailtje. Is misschien in je spam-box terecht gekomen?

Dank voor jullie reacties. Op meerdere e-mailadressen, zowel werk als privé, niets ontvangen. Vreemd...
Edit: vanavond om 21:10 uur kwamen deze mails pas binnen.

[Reactie gewijzigd door Octopuz op 18 oktober 2016 21:56]

Mooi dat ze zelf het 'gratis' let's encrypt gebruken

We hebben https en dergelijke ...s-en. Nu moeten we er zelf op letten dat er slotjes staan en dat die ook gesloten zijn (liefst groen, eventueel geel/oranje maar niet rood). In het beste geval is er dus een match tussen de website, het certificaat van de site en de certificaat keten tot aan de root-ca zoals die in het os of de browser is ingebouwd.... En nu blijken er weer 2 root-certificaat instanties niet zuiver op de graad... Maar uiteindelijk is het vertrouwen tussen de site en het certificaat. False site met fals certificaat bij een gekende root-ca en het slotje is groen.

Certificaat pinning (HPKP bijvoorbeeld) is een mooie, Dan is de site in de browser de eerste keer geregistreerd als bij een bepaald root-certificaat. Als daarna het gebruikte root-certificaat veranderd (een andere CA gebruikt wordt) dan zal het slotje niet meer groen zijn maar oranje of zelfs rood. Dit moet in de browser en het os worden geïmplementeerd maar is dat nog niet. Wat mij betreft moet dit certificaat pinnen niet vertraagd worden (maar niet te snel worden ingevoerd!).

Wie heeft er nog meer ideeën om het vertrouwen op internet weer een beetje op te krikken?

Nou, naast HPKP is Certificate Transparency een prachtige aanvulling! Wanneer CA's verplicht worden hieraan mee te werken, en browsers zelf ook certificaten die ze in het wild tegenkomen toevoegen aan CT, ontstaat een publiek audit log van certificaten. Die transparantie maakt misbruik makkelijker op te sporen.

Trouwens, HPKP is nog mooier dan je beschrijft - de pinning gaat niet op (root) certificaat maar op public key. Dus ook bij een vernieuwing van certificaat blijft de pin werken, zolang je maar hetzelfde key pair gebruikt. En wanneer een aanvaller een certificaat weet te krijgen onder dezelfde root als het valide certificaat, beschermt de pin nog steeds tegen MitM.

Dit biedt nul komma nul meerwaarde.

Zo'n reactie ook.