Check in bouwen bij Let's encrypt die verifeerd of zij ook een certificaat uit hebben gegeven voor het hoofddomein.

Wacht ook nog op een artikel dat beschrijft dat criminelen veelvuldig gebruikmaken van het OV, auto's en dat 100% van de criminelen ooit in aanraking is gekomen met water. Dit laatste is een dusdanig gevaarlijke stof het zou verboden moeten worden.

"maar waarschijnlijk wisten ze toegang tot het beheerderspaneel van de website te krijgen."

Heeft dus geen reet met Let's Encrypt te maken. Hoe zet je een goed initiatief in een slecht daglicht? Vraag het Security.nl. Die schrijven wel iets.

Misschien moet iemand ook een stuk schrijven over hoe criminelen ook gebruik maken van auto's en koffie drinken.

Groots nieuws, de befaamde automobiel wordt door criminelen gebruikt!
Het is voor criminelen zonder te veel problemen mogelijk auto's te gebruiken als:
-vluchtauto
-ramkraak tool
-kinetisch projectiel
-etc

Zegt het voort!

Een computer en een router om alleen te bankieren is misschien de beste oplossing.
Of een apparte HD met een switch.

Het feit dat cyber crimelen een certificaat hebben aangevraagd is niet spannend maar wel gebeurt.
Door deze berichtgeving zou je dus aan kunnen nemen dat niet alle websites met een certificaat te vertrouwen zijn.

"waarschijnlijk" doelt op een ongetoetste aanname. geen goede basis om keiharde conclusies op te trekken.
maar je hebt in dit geval wel voor een groot deel gelijk als je stelt dat het primaire probleem lag bij het verkrijgen van het subdomein. alle verdere handelingen zijn hierop gebaseerd.

Als dat het doel was van dit stuk zou het anders geschreven moeten zijn.

En dat was wel het geval voordat Let's Encrypt er was?

Een bericht, geschreven door TrendMicro die zelf ook een CA zijn, waarin ze lets encrypt, hun directe concurrent in een kwaad daglicht zetten. En jullie nemen het klakkeloos over.

Helemaal in het begin van het certificaten systeem moest je nog met een legitimatie en allerlei documentatie van het
bedrijf komen om een certificaat aan te vragen. Echter die verificatie eisen zijn in een neerwaartse spiraal gekomen
en nu is het al voldoende als je een bestandje op de server kunt zetten.

Net op het moment dat de certificaat uitgevers die het het slechtste deden wat aan hun policies verbeterden kwam er
letsencrypt die het weer terug ramt naar het rock bottom level.

Geen goede zaak inderdaad, maar wat doe je er tegen?

Wat helemaal sneu is dat is die software die ze gemaakt hebben. Je download wat code van een git account en als je
het opstart met een --help optie (wat ze zelf suggereren!) begint het meteen 10 packages te installeren en maakt een
hidden directory aan met allemaal crap erin. Als je het probeert te gebruiken op standaard geinstalleerde omgevingen
krijg je meldingen zoals:
The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('Unable to parse runtime variables',)
lekker informatief...
En als je nog eens kijkt hoe dat dan moet gaan na de 3 maanden wanneer het certificaat weer verloopt, dan blijkt
dat ze het automatisch verversen van het certificaat nog niet af hebben, daar wordt nog aan gewerkt.

Alleen geschikt voor hit-and-run criminelen kennelijk.

Een zin eruit breken en de eigen context maken lijkt mij helemaal niet de juiste tekst voor een artikel.

Veiligheid zoals de consument dat ziet en SSL/TLS hebben weinig met elkaar te maken. De techniek maakt het meekijken moeilijk voor derden. De industrie heeft dat vertaald naar veiligheid en ook in het verlengde de reputatie eraan gekoppeld door controles en speciale certificaten. Die menging maakt het het voor de consument onduidelijk wat wat is.

Dat is nooit anders geweest, certificaten en digitale handtekeningen worden gebruikt om de identiteit van de andere partij te verifiëren, zij zeggen niets over de intenties ven die partij.

Een SSL/TLS servercertificaat zegt niets over de betrouwbaarheid van een website. En (hoewel ik dat vroeger wel dacht en schreef), een servercertificaat zegt ook niets over de kwaliteit van de versleutelde verbinding.

Wat dan wel? Certificaten waren ooit bedoeld om helder te maken wie de eigenaar is van een specifieke website en te zorgen dat je zeker weet dat je verbinding hebt met die specifieke website van die eigenaar.

Hoe? Bij de uitgifte van een certificaat hoort de certificaat-provider zorgvuldig te controleren of de aanvrager is wie hij zegt dat hij is, en dat hij gerechtigd is om voor de opgegeven domeinnaam (zoals security.nl) een certificaat aan te vragen. M.a.w., dit type certificaten voorkomt identiteitsfraude bij domeinnamen.

Of jij vervolgens die eigenaar -en daarmee zijn website- vertrouwt, is geheel aan jou.

Let's Encrypt certificaten (en andere Domain Validated certificaten) ondermijnen dit model volledig. In plaats van te controleren of de aanvrager is wie hij zegt dat hij is, en of hij gerechtigd is om voor een domainname een certificaat aan te vragen, werkt het als volgt:
1) De aanvrager installeert Let's Encrypt software op "zijn" computer, die we X noemen
2) De aanvrager draait de software waardoor een CSR (Certificate Signing Request) wordt gegenereerd en verzonden
3) Let's Encrypt ontvangt het CSR
4) Let's Encrypt doet een DNS lookup van de domeinnaam in het CSR
5) Let's Encrypt maakt verbinding met het, via DNS, verkregen IP-adres
6) De Let's Encrypt software op X antwoordt met een geheim ter bevestiging dat het om X gaat
7) Let's Encrypt is tevreden, ondertekent het certificaat en retourneert het waarna het wordt geïnstalleerd.

Problemen:
A) De aanvrager blijft volstrekt anoniem (zie edit 07-01-2016, 15:11 onderaan deze bijdrage)
B) Een domainname zegt in veel gevallen niets over de eigenaar (voorbeeld: zijn https://www.microsoft-sbs-domains.com/ en https://dist.nuget.org/ van Microsoft of niet? Het grote aantal nieuwe TLD's maakt dit extra lastig)
C) DNS is onbetrouwbaar
D) BGP (routering) is onbetrouwbaar
E) Een MitM (Man-in-the-Middle) aanvaller tussen de Let's Encrypt server en het bedoelde IP-adres, kan zich voordoen als de werkelijke computer op dat IP-adres (denk bijv. aan een webserver achter een gebackdoorde Juniper firewall, maar ook veiligheidsdiensten met toegang tot netwerken - waar de hele "encrypt the web" beweging nou net om begonnen was).

Een fatsoenlijk certificaat elimineert juist alle bovenstaande problemen! M.a.w. Let's Encrypt- en andere DV-certificaten kunnen identiteitsfraude met domeinnamen niet voorkomen.

Doordat Let's Encrypt- (en andere DV-) certificaten identiteitsfraude toestaan, zijn ze feitelijk net zo betrouwbaar als self-signed certificaten (waarbij webbrowsers wel alarm slaan of je helemaal geen toegang geven).

Bijkomend probleem: webbrowsers maken, op het eerste gezicht, geen onderscheid tussen enerzijds "normale" certificaten (zoals PKI Overheid) en anderzijds Let's Encrypt en andere DV certificaten. Pas door het certificaat zelf te inspecteren, kun je het verschil zien. Echter, doordat er geen gestandaardiseerd veld is om dit automatisch te kunnen doen, zullen webbrowsers dit onderscheid nooit betrouwbaar kunnen maken. Gevolg: voor normale gebruikers (die geen certificaten inspecteren) zijn uitsluitend EV-certificaten nog betrouwbaar.

Nb. met de (aanbevolen) Diffie-Hellmann key exchange methode heb je helemaal geen certificaat meer nodig om een verbinding tussen jouw webbrowser en een webserver betrouwbaar te kunnen versleutelen. "Encrypt the web" had dus best zonder de Let's Encrypt crap gekund.

Edit 07-01-2016, 15:11: in plaats van "A) De aanvrager blijft volstrekt anoniem" bedoel ik feitelijk: de eigenaar (de naam van een organisatie of bedrijf, maar kan ook een famileinaam of persoonsnaam zijn) blijft volstrekt anoniem, en dat is relevante informatie om te kunnen vaststellen of je die eigenaar kunt vertrouwen. Dat dit zo is komt doordat de aanvrager anoniem blijft voor de certificaatprovider (gegevens van de aanvrager worden, normaal gesproken, niet in een certificaat opgenomen).

Houdt ons s.v.p op de hoogte van je constructieve verrichtingen op het vlak van onder meer je correspondentie met EFF, het project "Encrypt the web" en alternatieve projecten die daadwerkelijk werken aan het laagdrempeliger maken van veiligheidstoepassingen voor gebruikers aangaande dit onderwerp.

Want het zal toch niet zo zijn dat je alleen hier maar eenzijdig blijft hameren om in je gelijk te volharden of impliciet oproept om EFF te d-dossen, terwijl je ook met je kennis positief, concreet en constructief had kunnen bijdragen in 'making the online world a safer place'.

Doen hoor!
Daar worden we namelijk concreet veel blijer van.

Of heb je een andere agenda?
Van welk materiaal is dat gordijn eigenlijk in die avatar?

Hartelijk dank Erik van Straten voor je immer verduidelijking (omvangrijker dan een brainfart reply).
Twee puntjes:

Nah, een gemiddelde eindgebruiker weet niet het verschil.
...zonder daarbij ook meteen de anoniemiteit te elimineren?
Tja, het web had ook wel zonder fatsoenlijke certifcaten gekunt.
En fatsoenlijke certificaat leveranciers hadden ook wel fatsoenlijke prijsstaffels kunnen maken.

42

En van begin af aan is dat een rotzooi omdat het is uitbesteed aan commerciële CA's, die uit kostenoverwegingen vaak alleen wat we nu DV-certificaten noemen leverden. De EV-certificaten zijn rijkelijk laat in het leven geroepen omdat het gewoon niet goed genoeg was. Maar die kosten heel wat meer dan voor een hobbywebsite of voor een marginaal bedrijfje reëel is.

Ik heb me bij certificaten voor persoonlijk gebruik al vele jaren geleden afgevraagd waarom je eigenlijk niet gewoon met een publieke sleutel op een gegevensdrager naar de burgerlijke stand kan lopen en die op vertoon van je identiteitsbewijs tegen betaling van leges kan laten ondertekenen door de overheid. Voor bedrijven zou zoiets misschien bij de kamer van koophandel of de belastingdienst moeten worden ondergebracht. Gewoon zelf even erheen gaan en voor hooguit een paar tientjes een certificaat met dezelfde geldigheidsduur als andere identiteitsbewijzen regelen met hetzelfde niveau van betrouwbaarheid dat voor paspoorten wordt gehanteerd. De commerciële uitgevers van EV-certificaten zijn dramatisch veel duurder, wat voor mij illustreert dat dingen aan de markt overlaten echt niet altijd zaligmakend is.
De oorzaak van de ondermijning is in mijn ogen wat ik net beschreef, en we leven nu in een wereld waarin dat voorlopig is hoe het werkt. Ik vind Let's Encrypt in dat licht helemaal niet fout, dat is gewoon roeiend met de riemen die momenteel voorhanden zijn toch een verbetering aanbrengen.
Dat is lang niet voor elke website erg. Voor een bank vind ik het zwaar onvoldoende, voor een privé-website is dit helemaal niet zo kritisch. In DNS is tegenwoordig de identiteit van de eigenaar tegenwoordig ook meestal afgeschermd, en dat heeft de wereld ook niet doen instorten.
Wat daar vooral lastig is is de hardnekkige neiging van bedrijven om niet met subdomeinen te werken. Waarom niet static.google.com in plaats van gstatic.com? Waarom niet img.youtube.com in plaats van ytimg.com? Dát maakt het vooral ondoorzichtig.
Hoe groot is de kans? Het lijkt mij waarschijnlijk dat het bij veruit de meeste aanvragen gewoon goed gaat, en dat de kans dus groot is dat het certificaat wordt verstrekt aan de legitieme gebruiker van het domein. Het lijkt mij ook waarschijnlijk dat de legitieme gebruiker er vrij snel achterkomt als zijn domein met een ander certificaat in browsers wordt getoond dan zijn eigen certificaat en actie onderneemt om dat recht te zetten. LetsEncrypt heeft een e-mailadres om securityproblemen te melden en ik zou zelf niet aarzelen om dat aan te schrijven als ze een certificaat aan de verkeerde partij hebben afgegeven. En als dat slecht blijkt te worden opgepakt zou ik niet aarzelen om er een stevige rel over te schoppen. LetsEncrypt moet zich in dat opzicht nog bewijzen maar ik denk dat als zich problemen voordoen die niet onopgemerkt zullen blijven.

Het ACME-protocol ondersteunt de mogelijkheid om bezit van een eerder certificaat te gebruiken als bewijs van controle over een domein, en dat is bedoeld om gebruikt te worden als de server (van LetsEncrypt) kan vaststellen dat zo'n eerder certificaat er is. Zoals ik het lees (en ik hoop dat ik het goed lees) impliceert dat dat dat de primaire manier van werken bij verlengingen is, wat zou betekenen dat als een certificaat eenmaal aan de juiste partij is afgegeven het bij verlenging aan dezelfde partij wordt afgegeven.
https://letsencrypt.github.io/acme-spec/#rfc.section.7.3

Al met al betekent dit denk ik dat de betrouwbaarheid in de praktijk niet absoluut is maar wel hoog kan zijn, ook zonder puur op harde (en dure) validatiemethodes te vertrouwen. Ik weet echt niet zeker of de praktijk mijn optimisme zal rechtvaardigen, maar ik betwijfel of de of de praktijk zo somber zal blijken uit te pakken dat hij jouw pessimisme zal rechtvaardigen.

Bestaan er webbrowsers en webservers die versleutelde verbindingen mèt DH maar zònder certificaat ondersteunen? Is wat je hier stelt niet net zo hypothetisch als een wereld waarin alle certificaten keurig zijn wat ze eigenlijk van meet af aan hadden moeten zijn, namelijk EV-certifiaten?

Ik zie LetsEncrypt echt niet als de ultieme stap naar een ideale wereld. Ik denk wel dat het binnen de huidige omstandigheden een positieve toevoeging is die het in zich heeft om de norm van 'doet er niet toe' naar 'moet versleuteld zijn' om te helpen buigen. En als de neuzen grootschalig die kant op wijzen creëert dat weer draagvlak om aan een robuustere opvolger te werken. Alles behalve de ultieme oplossing afwijzen is (helaas) niet de manier waarop de wereld in de praktijk verbetert. Ik ga er voorlopig van uit dat LetsEncrypt een stapje in de goede richting is.

Dus de aanvaller heeft een DNS-record, in de DNS-zone van een bedrijf aangemaakt, en daarna een certificaat op die zone gezet mbv LetsEncrypt...

Volgens mij is dan de DNS-server van het betreffende bedrijf oorzaak van deze hack, en niet LetsEncrypt...

Niet over de intenties, maar wel over de identiteit. Althans vroeger. Dat was ooit vrij goed geregeld.
Het beeld dat een slotje iets toevoegt aan de veiligheid is met name gestoeld op het gedefinieerd zijn van de identiteit
van je communicatie partner, niet zozeer op de encryptie zelf (die zonder verificatie van de identiteit zowizo weinig
waard is). Zelfs al heeft de andere partij geen goede bedoelingen, dan heb je in ieder geval zijn gegevens, was het idee.
(zodat je dit via het normale rechtssysteem kunt aanpakken)

Maar door de devaluatie van certificaten is daar weinig meer van over. En bij letsencrypt helemaal niks.

"Let's encrypt" certificaten zou iets moeten zijn voor Jan met de Pet.
Alleen mensen die zo'n "Jan met de Pet" al persoonlijk kennen (dus familie, vrienden en bekenden), en de websitenaam
van hem hebben doorgekregen kunnen dan met voldoende zekerheid weten dat ze op de juiste website zitten.
Dit is dan een website die ongeveer net zo betrouwbaar is als de betreffende Jan met de Pet zelf,
en die verhaal kunnen halen als er toch eens iets niet zou deugen, omdat ze weten waar hij woont.

Wat er nog wel wordt gedaan voordat het certificaat wordt verstrekt, is dat via diverse routes een DNS-check wordt gedaan, hetgeen DNS spoofing tot een minimum zou moeten beperken.

Let's Encrypt mag wellicht de waarde van een certificaat onderuit halen volgens velen, maar ik denk dat dit wel meevalt. Het is vrij duidelijk dat je een uitgekleed certificaat krijgt. Geen bedrijf of particulier die heel gevoelige zaken wil beschermen zal Let's Encrypt (willen) gebruiken.

Voor mensen met weinig budget of zin in de rompslomp van de bestel procedure is het ideaal. Ik zie Let's Encrypt niets anders dan een project om voor iedereen een certificaat beschikbaar te maken wat waarschijnlijk beter is dan geen certificaat.

Zou ik klant en of persoonsgegevens er mee encrypten? Nee. Mijn prive sites met WP, ownCloud, myPHPAdmin enz enz, ja die wel.

Dat komt door het fantstische http protocol, als je voor youtube.com een cookie aanmaakt dan krijg je die ook op img.youtube.com.
Dat cookie is ~200 bytes.
Bij 30 plaatjes/stijlelementen en een miljoen bezoekers per dag is dat 1,5TB traffic per dag, dan is die paar dollar per jaar voor een domeinnaam zo terugverdient.

Maar daarmee haal je dus wel de waarde van certificaten in het algemeen naar beneden.
Immers het feit dat het https is zegt nu nog minder dan het al een tijd deed.


Dat is maar de vraag. Misschien is het wel beter als er een onderscheid is tussen goede certificaten en geen certificaat,
in plaats van dat je nog een onduidelijke tussencategorie van bijna waardeloze certificaten krijgt. Daarmee maak je
het alleen maar lastiger om uit te leggen waar een gebruiker nou op moet letten, iets wat in veel situaties zowizo
niet praktisch mogelijk is.
Als niet iedere willekeurige persoon een (ongeverifieerd) certificaat kan krijgen dan zijn we misschien juist wel beter af.

Alternatief: maak voor dat geval een certificaat uitgever die op basis van digid verificatie van de identiteit werkt en wat
in geval van problemen dus (al dan niet uitsluitend voor justitie) traceerbaar is naar de aanvrager.

Dank voor jouw inhoudelijke reactie! Het antwoord is nee (ik heb mijn reactie aangepast): een certificaat hoort te authenticeren, dat kan nou eenmaal niet anoniem. Voor "echte" anonimiteit kun je een self-signed certificaat gebruiken.

Alle waar naar z'n geld, maar verder ga ik de discussie "ik heb slechts geld voor een Panda maar omdat ik hem wel wil hebben maar niet kan betalen jat ik een Bugatti Veyron" niet aan.

Jij ook dank voor jouw onderbouwde reactie!

M.b.t. kosten: het is wel heel sneu voor personen en organisaties die een fatsoenlijk non-EV certificaat hebben aangeschaft dat de waarde ervan zwaar is gedevalueerd door DV en LetsEncrypt certificaten. Ik verwacht dat, vroeger of later, gebruikers DV (en dus ook Let's Encrypt) certificaten gaan blokkeren. Met als collateral damage dat andere non-EV certificaten ook geblokkeerd zullen worden.

Nb. tenzij je vrije tijd teveel hebt, kost het goed onderhouden van een https server behoorlijk wat inspanning (dus geld). In dat licht vallen de kosten van een "gewoon" (non-DV) commercieel certificaat wel mee.

Maak een self-signed certificaat en laat bezoekers de hash telefonisch verifiëren waarna ze het certificaat als vertrouwd kunnen markeren.

Je begrijpt hopelijk dat ik dit niet met je eens ben.

De grote meerderheid van gebruikers kun je uitleggen dat ze op een slotje moeten letten; er zijn er maar weinigen die met whois aan de gang zullen gaan. Authenticatie is niet het doel van DNS - maar wel van certificaten.

Eens, maar er is niets dat een willekeurig iemand belet om binnenkort het domein microsoft.dev te registreren (momenteel resolvt dat nog naar 127.0.53.53). Met het groeiende aantal TLD's is het, zelfs voor grote bedrijven en organisaties, erg duur (als domain-hijackers hen voor zijn) of gewoon onmogelijk om alle variaties van hun naam te "claimen" (zie ook digi-d.nl versus digid.nl).

DV- (en Lets Encrypt) certificaten vergroten deze kans aanzienlijk en daarnaast zeggen ze niets over de eigenaar.

M.a.w. om te voorkomen dat iemand anders ooit een Let's Encrypt certificaat voor jouw domain aanvraagt, moet je nu maar vast een Let's Encrypt certificaat regelen? Bovendien, Anomiem van 07-01-2016 11:15 schreef: Dat heb ik overigens zelf niet geverifieerd.

Welke betrouwbaarheid? Dat DNS hopelijk resolvt in het juiste IP-adres, en achter dat IP-adres hopelijk de bedoelde server zit? En dan ook nog eens zonder dat je weet wie de eigenaar is?

Nee, maar je hebt mijn sectie over self-signed certificaten (direct erboven) weggelaten. Daarnaast zie ik niet waarom browsers niet aangepast zouden kunnen worden aan de kennelijke behoefte aan ongeauthenticeerde maar wel versleutelde verbindingen, bijv. door "https" te tonen zonder dat een slotje wordt getoond.

De reden dat browsers voor self-signed certificaten waarschuwen is dat de identiteit van de eigenaar onbekend is (indien niet opgenomen in het certificaat) en vervalst kan zijn (indien wel opgenomen in het certificaat). Exact ditzelfde geldt voor DV- en Let's Encrypt certificaten. Waarom waarschuwen browsers daar dan niet voor?

Het beste was het geweest als er 3 soorten certificaten waren:
- EV: met zeer uitgebreide validatie, geen wildcard domains toegstaan
- Gewoon: met redelijke validatie
- De rest (DV, Let's Encrypt, self-signed): anoniem, leuk voor TOFU (Trust On First Use), vooral in combinatie met HSTS

Ik vind het een stap de verkeerde kant op.

(off-topic)
Kijk, daar had ik niet aan gedacht, dank voor dit inzicht.

Formeel zou het geen probleem moeten zijn, als een webserver geen domein opgeeft bij een cookie hoort de browser de cookie alleen naar de server te sturen die de cookie geplaatst heeft, en niet andere servers, ook niet op subdomeinen. Het http-protocol is dus fantastisch genoeg om dit te regelen, alleen waarschuwt rfc6265 dat niet alle browsers het goed implementeren en cookies toch naar subdomeinen sturen. Je hebt dus een punt.

Maar toch vind ik het geen sterk argument. Om te beginnen met wat je over youtube zegt, daar zie ik niet één cookie maar vier stuks en die zijn samen nog geen 100 bytes groot. Die zouden makkelijk verder te verkleinen zijn, alleen al de namen van de cookies kunnen korter, de lengte van identifiers verandert de werking van software niet.

Voor statische content kan verder met de max-age parameter van de Cache-Control header worden aangegeven dat de server niet voor ieder gebruik opniew moet worden benaderd, en een request die wordt overgeslagen bevat ook geen cookies. Zouden cookies naar img.youtube.com werkelijk zo'n probleem moeten zijn als je een mechanisme hebt om het aantal requests in de perken te houden? Hier legt Google zelf het heel duidelijk uit: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=nl

Verder is het niet het enige argument dat meegewogen moet worden als je keuzes voor domeinnamen maakt, en hopelijk worden verschillende argumenten tegen elkaar afgewogen. Transparantie over welke zaken bij jou zelf afkomstig zijn is in het belang van jezelf en je gebruikers, onder meer omdat die transparantie een positieve uitwerking heeft op security. Het maakt het bijvoorbeeld veel makkelijker om uit te leggen hoe je een phishing-domein van een legitiem domein kan onderscheiden als al jouw domeinen als subdomeinen onder hetzelfde hoofddomein geschaard zijn. Vandaag de dag weegt dit in mijn ogen zwaar genoeg om voor het besparen van bandbreedte andere oplossingen te zoeken, en die zijn echt wel te vinden.

Als je het vergelijkt met EV-certificaten: ja
Als je het vergelijkt met onversleuteld HTTP: nee

Van de kwart miljoen uitgegeven certificaten is de bulk naar sites gegaan die nog geen HTTPS gebruikten. Maar 5% van de websites gebruikt een EV-certificaat, en wel 70% een DV-certificaat (er zit nog een categorie tussen). Lees dit eens:
https://unmitigatedrisk.com/?p=552

Nou zit je ze motieven in de schoenen te schuiven waar je geen basis voor hebt om maar gelijk te krijgen. Je bent overduidelijk meer dan intelligent en kundig genoeg om niet van drogredeneringen af te hoeven hangen.

Het klopt, ze zijn nog aan het beta-testen, en ze doen niet geheimzinnig over wat wel en niet werkt.

Bestaat voor jou betrouwbaarheid pas als hij absoluut is? Weet je zeker dat je nooit pech zal krijgen met je auto? Is hij anders volkomen waardeloos? Of is het voldoende dat de kans op pech onderweg behoorlijk klein is en noem je die auto toch betrouwbaar? Voor een heel groot deel van het web vind ik het goed genoeg dat de kans dat het klopt een fractie minder dan 100% is, en ik denk dat in de praktijk echt maar een kleine fractie van de DV-certificaten aan de verkeerde partij zijn verstrekt.

Ik had dat bijna niet gedaan maar je schreef: Dus ook geen self-signed certificaat, maak ik daarvan, da's namelijk ook een certificaat. Ik heb je kennelijk iets te letterlijk genomen. Da's een symptoompje van mijn autisme.

Daar ben ik het roerend mee eens.

Omdat het niet altijd om de identiteit van de eigenaar gaat maar vaak om de vraag of je zonder MitM met een bepaald domein communiceert. En omdat het, ondanks alle zwakheden in het geheel, bij de overgrote meerderheid van de DV-certificaten gewoon ook echt de eigenaar van dat domein is die het certificaat heeft dat jij ziet. Dat maakt de kans op een probleem kleiner dan bij self-signed certificaten. Je redeneert (zoals steeds bij dit onderwerp) vanuit een zwart/wit-beeld waarbij alles wat niet perfect is meteen helemaal fout zit. Dat is niet zo, er zijn gradaties, grijstinten, en de keuzes waar jij je tegen verzet zijn gemaakt door mensen die die gradaties wel meewegen.

En houd alsjeblieft eens op over "DV- en Let's Encrypt certificaten" te praten, LetsEncrypt is een leverancier van DV-certificaten die aan dezelfde kwaliteitsstandaards wordt gehouden als andere CA's. Formuleer het niet steeds alsof de certificaten niet in de DV-categorie vallen maar iets aparts zijn, het zijn wel DV-certificaten.

Ah, je hebt toch ruimte voor gradaties, mooi ;-)

Als je het artikel wat ik hierboven link gelezen hebt weet je dat er inderdaad grofweg drie validatieniveau's zijn in de praktijk, al zijn ze misschien niet precies wat jij beschrijft. Ik zou een onderscheid tussen DV en self-signed toevoegen, ik denk dat daar wél een relevant verschil in betrouwbaarheid tussen bestaat. En browsers zouden dat op een duidelijke manier moeten tonen, bijvoorbeeld met een aantal sterren: 0=HTTP, 1=self-signed, 2=DV, 3=OV, 4=EV.

Self-signed certificaten kunnen trouwens best betrouwbaar zijn als de eigenaar van de website de betrokkenen niet alleen via de website kent. Een werkgever zou een website voor personeel met een self-signed certificaat kunnen laten werken, bijvoorbeeld.

Een toevoeging die ik sinds het DigiNotar-debacle mooi zou vinden is als een certificaat door meerdere CA's ondertekend kan worden. Als een CA omvalt kan je gewoon op de certificering van een andere CA doordraaien als dat kan. Kritische sites als banken en sommige overheidsinstanties kunnen dan kiezen om zich meervoudig te laten certificeren. Maar dat is, net als veel andere ideeën, op dit moment domweg niet het geval. Dus roeien we met de riemen die nu voorhanden zijn.

@Erik van Straten: ik besef dat ik dit vermoedelijk anders opgevat heb dan je het bedoelde, je had het vermoedelijk niet over motieven maar over effecten. Excuses voor het misverstand, ik neem deze opmerking terug.