Alles wat je aangeeft klopt, neemt niet weg dat het genoemde aantal certificaten niet gelogen is.

Misschien is een dienst voor gratis certificaten niet zo'n goed idee omdat het vooral scammers trekt.

Je klacht is eigenlijk gewoon dat het in de lucht brengen van een website veel te eenvoudig is. DV certificaten zijn slechts één van de componenenten (naast een webserver en een internet provider) die je tegenwoordig nodig hebt om een website te hosten.

Mijn analyse is dat jij zou graag zou zien dat er meer controle is voor wie een website in de lucht wil brengen. Je zou de schuld voor al die malafide domeinen net zo goed bij de domain registrars kunnen leggen die niet controleren wie er een domein registreert, of de hoster die niet checkt wie zijn klant eigenlijk is.

In de tijd voordat SSL certificaten gemeengoed waren moest je een kvk inschrijving hebben als je een .nl domein wilde registeren, dat voorkomt inderdaad het massaal registreren van sites voor malafide doeleinden maar of we weer naar dat soort beperkingen toe willen?

Toen het SSL/TLS protocol bedacht werd, en https geintroduceerd werd op sites, had men daarbij 2 doelen voor ogen:
1. het voor een bezoeker mogelijk maken zeker te stellen dat de site is wie die zegt te zijn, dus niet een man-in-the-middle
2. het encrypten van de communicatie tussen site en bezoeker, zodat onderweg niet kan worden meegeluisterd.

Er werd toen aan de internet gebruikers onderwezen dat "als er een slotje in je browser stond alles veilig was, immers
dan was het https en dat was met een certificaat en dat was allemaal goed gecontroleerd dus u bent veilig".

Op een gegeven moment hebben fanaten op internet "we moeten alles encrypten" geschreeuwd, vanwege het idee
dat zij hadden dat sommigen alles wilden meeluisteren of het nou interessant was of niet. En dat er zelfs malafide
partijen waren die moedwillig de communicatie met sites aanpasten. Dus moest IEDEREEN over op https.
Als gevolg daarvan is het 1e doel totaal ondergesneeuwd. Als iedereen naar https moet kun je natuurlijk niet meer
gaan controleren of iedereen wel zegt wie die is. Toen zijn er bedrijven als Letsencrypt ontstaan die deze validatie
totaal lieten vallen (daarvoor had je ook al commerciele certificaatuitgevers die dit als optie aanboden).
Het slotje had iedere waarde verloren. Dit is de schuld van de encryptie-schreeuwers en de situatie die ze daarmee
gecreeerd hebben. Zelfs de mogelijkheid van "extended validation" (die overeen komt met wat vroeger standaard
was bij de uitgifte van een certificaat) hebben ze weg weten te bazuinen.

Maar denk maar niet dat ze hiervoor ter verantwoordig worden geroepen, het zijn helden. Want encryptie.

Ik ben in mijn werk als incident responder in het verleden (voor de tijd van HSTS en browsers die alleenTSL verkeer accepteerden) vele malen tegengekomen dat bedrijven gecompromitteerd werden door MITM op bijvoorbeeld public wifi netwerken. Het versleutelen van al het http verkeer heeft een heleboel bijgedragen aan het verminderen daarvan.

Een groot deel van onze economie en communicatie loopt tegenwoordig via http, het niet versleutelen daarvan zou dan ook aanvallen door cybercriminelen een stuk makkelijker maken en leiden tot nog veel meer fraude en diefstal. Het internet zou vele malen onveiliger zijn als het meeste verkeer nog onversleuteld was.

Extended validation had voor mij zeker waarde maar in de praktijk bleek dat het grootste deel van de internetgebruikers helemaal niet goed naar de organisatienaam keek en dus bijvoorbeeld gewoon van de de site "[ABN_AMRO] https://abn_amro.tu" dacht dat het de bank site was (want een mooie groen balk in de browser). ABN_AMRO was gewoon een op tuvalu registreerd bedrijfje dat met die inschrijving keurig een EV certificaat kreeg ;-)

Het is inderdaad wel jammer dat het kind met het badwater is weggegooid want nu is het ook niet meer te gebruiken door mensen die wel goed weten waar ze naar kijken.

Die analyse is onjuist.

Van WIE is die website, ongeacht de domeinnaam?
Vóórdat ik gegevens uitwissel met een website (informatie lees, bestanden download, persoonsgegevens invoer, etc.), wil ik op betrouwbare wijze kunnen zien van wie die website is, zodat ik die eigenaar aansprakelijk kan stellen als deze mij belazert. Als ik dat niet kan zien, kan ik daaruit afleiden dat ik een groot risico neem, en dat het wellicht om een nepsite gaat (en ik verder moet zoeken naar de echte site).

In "real life" weet ik (hopelijk iedereen) dat een kofferbakverkoop meestal geen frisse boel is, en dat de kans dat je kunt ruilen of garantie hebt, nul is. Probleem: op internet zie ik het verschil tussen een kofferbakverkoop en bijvoorbeeld de HEMA niet.

Eén afwijkende letter (die afwijking kan niet of nauwelijks zichtbaar zijn zoals 'l' versus 'I'), of een domeinnaam die heel goed van de bedoelde organisatie zou kunnen zijn, en je bevindt je (bij wijze van spreken) in een achterbuurt van Bogotá i.p.v. bij een vertrouwde organisatie verderop (de kofferbakverkoop versus een HEMA-filiaal).

DV-certs indirecte oorzaak
Op zich zouden DV-certificaten geen probleem moeten zijn, ware het niet dat zij (plus de browsermakers) alle andere soorten certificaten zinloos hebben gemaakt; internetters zien geen verschil meer.

Ik claim absoluut niet dat EV-certificaten "dé oplossing" zijn en ook niet dat iedereen vanzelf zal snappen waar zij op moeten letten. Dat laatste argument ("we zetten de ingrediënten maar niet meer op de verpakking, want bijna niemand leest ze, en als ze het lezen weten de meesten niet wat E-nummers zijn) vind ik echter een stompzinnige dooddoener. Het is in jouw eigen belang om die informatie wel te lezen, te begrijpen wat er staat en hoe te handelen als gegevens ontbreken of niet lijken te kloppen.

Verbeterde EV-certs? en user interface
M.b.t. EV-achtige-certificaten (bijv. met betrouwbaarheidsaanduiding): ik wil eenduidig authenticerende gegevens van de verantwoordelijke eigenaar van een website zichtbaar kunnen maken, en weten hoe betrouwbaar de TTP die eigenaar geauthenticeerd heeft. Uniek authenticerende informatie hoeft echt niet allemaal in de adresbalk van browsers te passen (daar is vaak simpelweg te weinig ruimte voor) maar er moeten ook geen 10 klikken voor nodig zijn. En het moet zeker niet te technisch zijn (leken hebben niets aan de hexadecimale representatie van een public key).

Als een webshop mij iets wil verkopen of een website claimt van de overheid te zijn, zal die eigenaar moeten bewijzen wie daar achter zit. Ik ken geen andere manier dan via een TTP (Trusted Third Party) die de identiteit van die eigenaar op betrouwbare wijze verifieert. Voor zakelijke contacten hebben we daar de KvK voor, maar die verzaakt (onbegrijpelijkerwijs) compleet als het om authenticatie op internet gaat.

Digitaal paspoort in smartphone, IRMA
Zoals ik elders al eerder schreef, van ons internetters wordt verwacht dat wij steeds vaker en steeds meer persoonsgegevens aan websites toevertrouwen, waaronder binnenkort (?) afkomstig van op onze smartphones gedigitaliseerde identiteitsbewijzen, al dan niet beperkt door IRMA: zie [1] (plus-artikel) of [2] (openbaar); zie ook mijn posts daaronder.

Aanvulling 15:18: link [1] lijkt ondertussen openbaar te zijn gemaakt door Tweakers. Daarin discussieer ik met Ivo Jansch (een van de betrokkenen bij de wallet-ID).

[1] https://tweakers.net/nieuws/204138/nederland-krijgt-een-paspoort-voor-op-internet-hoe-gaat-dat-werken.html?showReaction=18249704#r_18249704

[2] https://tweakers.net/nieuws/204604/irma-maker-sidn-neemt-deel-aan-eu-pilot-voor-digitale-identiteitswallet.html?showReaction=18254976#r_18254976

Waarom moeten wij wel authenticeren, en de verifieerder niet?
Steeds meer persoonsgerichte informatie bedoeld voor ons is uitsluitend via internet beschikbaar - waarbij wij geacht worden ons te authenticeren, maar de verifiërende partij niet. E.e.a. als gevolg van het afschalen van papieren post en het sluiten van kantoren. En door winkelsluitingen worden mensen, ook zij die dat niet willen, vaker gedwongen om producten (of licenties, aanvragen voor toeslagen, uitkeringen, coronatests/vaccinaties, internetbankieren, etc. etc.) via internet aan te schaffen of te regelen.

Waarom bestaan er verschillende betrouwbaarheidsniveaus voor de authenticatie van ons (burgers), maar lijkt het niemand te boeien dat dit niet geldt voor verifieerders? Weten wie en waarom jouw identiteit wil vernemen en verifiëren is minstens zo belangrijk om fraude met, of lekken van, jouw persoonsgegevens te voorkomen.

Conclusie
Zonder verstandige, rigide en wellicht ingrijpende maatregelen, gaat cybercrime alleen maar verder toenemen. En waar veel "verdiensten" naartoe gaan, vind ik ook uiterst ongewenst; de meeste, zo niet alle, van de in de bovenste post genoemde domeinnamen van fake sites resolven in 185.149.120.9 - AS57724 van "Ddos-guard Ltd", Russia, Rostov-on-Don.

Kortom, van mij mag jij voor "nas.secoff.duckdns.org" o.i.d. een gratis Let's Encrypt certificaat kunnen verkrijgen. Maar als jij mij zou vragen om https://nas.secoff.duckdns.org/ te bezoeken, wil ik in mijn browser in één oogopslag niet alleen kunnen zien dat mijn browser met redelijke zekerheid verbinding heeft met "nas.secoff.duckdns.org", maar óók dat er totaal geen betrouwbare informatie beschikbaar is van wie die site écht is. Kofferbakverkoop dus.

Omgekeerd, als bijvoorbeeld een overheidsorganisatie weer eens een nieuwe website lanceert, wil ik met redelijke zekerheid kunnen vaststellen van welke overheid die site is (van wie zijn ggdghor.nl en covidvaccinatie.nl, en hoe zie ik dat?) - om verwarring met imitatiesites zoveel mogelijk -en bij voorbaat- te voorkomen.

Het aantal aanbieders, net als bij de cloud, die standaarden voor het borgen van veiligheid ondersteunen, is helaas op de vingers van 1 hand te tellen.

Daar zit het probleem. Afdwingen van opvolging van veiligheidsmaatregelen en anders - 3 strikes means out.

#webproxy

Degene die certs levert aan de familie spam, scam & co,
is niet dezelfde die cert. abuse rapporteert.
Tenminste dat verwacht ik niet.

In die vaststelling en optiek zit veel van de grond van het probleem.

Als ik ergens aan verdienen wil, kan ik dit ook niet uitsluiten en toch zou dat moeten gebeuren, ook als de koper via een andere partij op een eiland ver weg anoniem kan blijven, lukt dat steeds minder.

Gratis is helemaal niet meer te controleren.

Als iets gewoon gevonden wordt, hoe verander je dan zo'n cultuur?

Vergelijk Nederland narcostaat.
Jeugd is er al aan gewend geraakt of gemaakt inmiddels.

Maar wat betekent het dat een site is wie die zegt te zijn? Dat de fysieke adresgegevens kloppen of dat je werkelijk met het domein "praat" dat in je adresbalk wordt getoond?

En er zijn al die tijd mensen met verstand van zaken geweest die erop wezen dat dat onzin is. Dat je weet dat je werkelijk met listenbedrog.nl communiceert wil helemaal niet zeggen dat je listenbedrog.nl kan vertrouwen.

Het vervelende is dat met https een (nogal technisch) aspect van de veiligheid wordt gedekt, maar niet alles, en dat is voor grote groepen mensen veel te abstract en daardoor niet goed uit te leggen. Mijn indruk is dat het meer op PR georiënteerde deel van de tech-wereld dat probeerde op te lossen door de boodschap simpel genoeg te maken voor die mensen, wat tot dat slotje=veilig-beeld leidde. Alleen maakten die het simpeler dan het in werkelijkheid is, en dan wordt zo'n boodschap links en rechts ingehaald door de werkelijkheid. Dat leidde weer tot aanpassingen van de boodschap en van de weergave in de browser, die ook weer niet voldeden en voldoen omdat de werkelijkheid niet zo simpel is als men hem probeert voor te stellen. We hebben het allemaal langs zien komen.

Fanaten? Publieke wifi access points werden populair. Die waren in het begin nog wel eens onversleuteld, en makkelijk te manipuleren vanaf een laptop die er verbinding mee maakte. HTTP was kwetsbaar in die situatie. Ook waren er, niet in Nederland maar bijvoorbeeld wel in het VK, internetproviders die op het lucratieve idee waren gekomen om on-the-fly advertenties te injecteren in via HTTP benaderde websites. Ook niet bepaald wenselijk, dat is een MITM-aanval.

Voor zover ik het heb meegekregen was de drang om alles te versleutelen een reactie op dingen die echt een verkeerde kant op aan het gaan waren.

Zoals ik het me herinner wekten CA's ooit graag de indruk dat ze alles vreselijk goed controleerden, maar zijn ze stevig door de mand gevallen. Toen zijn EV-certificaten bedacht om de controles te doen waarvan men eerder de indruk had gewekt dat die standaard gedaan waren. Bij veel "gewone" certificaten was de controle net zo beperkt als bij LetsEncrypt. Wat LetsEncrypt heeft toegevoegd is niet dat type certificaten, maar het gratis aanbieden ervan en het volautomatisch afhandelen van de aanvraag en vernieuwing ervan.

Volgens mij heeft dat slotje die waarde nooit werkelijk gehad. Het was een illusie op basis van een veel te simplistische voorstelling van zaken.
Die bestaan nog steeds, hoor. Browsers zijn gestopt ze met een groen slotje weer te geven, maar geven in plaats daarvan wel of niet aan aan welke organisatie het certificaat is uitgegeven. Ik vind het nu minder duidelijk dan het geweest is. Maar het is niet weg.

Ik zie geen helden, ik zie geworstel met de gevolgen van onhandige keuzes in het verleden.

Ik heb geen probleem met Let's Encrypt, omdat ik het helemaal geen probleem vindt als alle verbindingen versleuteld zijn, niet als de certificaten gratis kunnen, en niet als wat ooit handwerk was daarbij geautomatiseerd wordt. Verder pretendeert, voor zover ik overzie, Let's Encrypt niet dat het iets anders is dan het werkelijk is.

Ik heb wèl een probleem met die slotje=veilig-boodschap die altijd overgesimplificeerd was en onmogelijk waargemaakt kon worden, en met de nasleep daarvan. Ik heb ook een probleem met commerciële CA's die pretendeerden beter te controleren dan ze werkelijk deden. Bij deze dingen werd gepretendeerd dat dingen meer waren dan ze werkelijk waren. Dat is waar in mijn ogen dingen door mis zijn gegaan.

Uit de Let's Encrypt Subscriber Agreement (alle versies te vinden in https://letsencrypt.org/repository/) v1.0.1, July 27, 2015:
Uit de Let's Encrypt Subscriber Agreement v1.1.1, August 1, 2016 t/m v1.3, September 21, 2022:
Beide zijn onjuist. Een https servercertificaat wordt uitsluitend gebruikt voor authenticatie van een website. TLS kan, in elk geval in theorie, werken zonder versleuteling of zonder certificaat.

Een voorbeeld van stompzinnige versleuteling zonder authenticatie is public WiFi. De verbinding is versleuteld, maar je hebt geen idee of dat met het access point van de kroeg is, of met de WiFi-Pineapple van die gozer met hoodie en laptop op het terras.

Authenticatie zonder versleuteling heeft ook nauwelijks of geen zin. Daarom heb je beide nodig: pas als je weet met wie je communiceert is versleuteling zinvol, en voorkom je dat bijvoorbeeld jouw wachtwoord in verkeerde handen valt.

Een certificaat koppelt een identiteit aan een public key. De authenticatie vindt plaats doordat de server bewijst te beschikken over de private key horend bij de public key in het certificaat. Als dat met succes gebeurt weet je redelijk zeker dat de identiteit in het certificaat bij de server hoort. Dit heeft niets met het versleutelen van de verbinding te maken (daar zorgen de Diffie-Hellman key agreement en ciphers als AES voor).

DV-certificaten hebben in elk geval de twee volgende grote nadelen:
1) De (beschrijving van de) identiteit in het certificaat bestaat uitsluitend uit de domeinnaam van de server. Daarmee wordt het probleem "van wie is die domeinnaam" (kan het om een nepsite gaan) volledig verplaatst naar alle websitebezoekers. Daarmee hebben zij geen idee wie de eigenaren zijn van "pokemon-go[.]io" of "ggdghor.nl", waardoor zij nep niet van echt kunnen onderscheiden. Dit leidt onnodig tot slachtoffers.

2) DV-certificaten zijn nauwelijks betrouwbaarder dan DNS, en dus kwetsbaar voor allerlei aan DNS gerelateerde aanvallen, maar ook voor BGP-hijacks (voorbeeld: https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/). Daarmee beschermen DV-certificaten in een deel van gevallen niet tegen aktieve AitM-aanvallen door geheime diensten en/of "state-level actors" (zoek maar eens naar: ROSTelecom BGP hijack).

Eens, behalve dat laatste: we hebben het veel te snel opgegeven. Als we browsermakers niet heel snel dwingen om internetters veel beter te ondersteunen, en bij certificaatuitgevers niet keihard het kaf van het koren scheiden, neemt cybercrime alleen maar verder toe.

Vooral als we met "NL Wallet's", PGO's en andere ontmenselijking (digitalisering) doorbouwen op deze dikke laag drijfzand.

Jammer van de grote meute, die moet reageren met 'nog nooit van gehoord '. Dat is de enige reden dat zulke onbedoelde of bedoelde misbruik faciliteurs hiermee weg kunnen komen.

Zelfde geldt dat voor hardening tegen NSA spying, fingerprinting, dsk-misbruik,.ontbreken van deugdelijke maatregels als een CSP etc.

Ook het dichtknijpen van ogen door en de tandeloosheid van waakhonden (diensten) en corruptie per default van big Big Tech houdt deze cybercrime bevorderende infrastructuur in stand en verhoedt verandering of verbetering.

Feitelijk is het een systemisch probleem van alles wat kwalijk is in de maatschappij van heden en dan op Interwebz'.

Toch blijven er altijd alerte en untouchable figuren waarschuwen.
Daarom heb ik diep respect voor Erik en de vele anderen hier.
Er zijn echter ook teken ten dienste van de onveiligheidsbevorderaars ook van officiële zijde helaas.

Dat d goede krachten geen roepende in de digi-woestijn mogen blijven.

#webproxy

Ik quote het maar even in zijn geheel, want ik vraag me af wat dit toevoegt aan de discussie.
Niks inhoudelijks over het onderwerp, alleen maar het algemene gefoeter op de wereld en de machthebbers.
Im probeer tenminste nog in te gaan op de problematiek rond certificaatuitgifte en de strijdigheid met het doel van
certificaten, maar in het bovenstaande kom ik helemaal niks relevants tegen.

Als het je niet interesseert wie het aansturen, leef dan verder als aangestuurde. Dat niet zien, voegt eveneens niets toe i.m.n.o.

Certificeringsellende is onderdeel van dit grotere plaatje.

Wanneer begint eens een fundamentele discussie?
Oh, nee. Dat houden belanghebbenden liever buiten beeld.

Ik stel ondersteunende reacties, zoals van #webproxy, net zo op prijs als reacties met afwijkende inzichten. Ik vind het namelijk lastig in te schatten hoeveel mensen het (deels) met mij eens zijn, vooral als helemaal niemand "uit die hoek" reageert (maar op reacties van "reptielendenkers" zit ook ik niet te wachten).

M.b.t. de problematiek rond certificaatuitgifte: ik heb niet de illusie dat je dat 100% betrouwbaar kunt krijgen. Anderzijds, "foute" notarissen bestaan ook.

Daarbij denk ik dat we niet zo bang moeten zijn om om het huidige systeem van certificaatuitgifte flink op de schop te nemen. Het systeem met 100+ rootcertificaten, ook uit landen die ik totaal niet vertrouw, "gemanaged" door een dubieus "CAB-forum" (in hoeverre zijn ICT-gebruikers daarin vertegenwoordigd?) bepaalt voor mij wat goed voor mij is, op basis van een opeenstapeling van laffe compromissen; dat vind ik onwenselijk. Hetzelfde geldt voor de gebruikersinterface van webbrowsers - die veel te vaak en om (mij) onduidelijke redenen verandert.

De eerste T uit TTP staat voor Trusted - noodzakelijkerwijs door mij. Ik heb niet de indruk dat ik hier enige invloed op heb of eenvoudig instellingen kan veranderen.

Daar ben ik het helemaal mee eens! Het hele model van "trust" deugt totaal niet, ik zou niet weten waarom ik certificaten
uitgegeven door een of andere vijandige staat zou moeten vertrouwen. En het is veel te lastig voor gebruikers om daar iets aan te veranderen. Dergelijke trust zou ook niet bij applicaties moeten liggen (zoals Firefox) maar bij het operating system, en je zou eenvoudig een profiel moeten kunnen kiezen wat de vertrouwde uitgevers lijst aanpast naar lokale behoefte van de meeste gebruikers (wat de default zou moeten zijn), aan te passen als die behoeften anders zijn.

En de hippe mode van tegenwoordig om bij iedere release de hele configuratie interface (niet alleen hier van) totaal over de kop te gooien op basis van niet gedocumenteerde "wensen van de gebruikers" dat deugt ook niet. Als gebruikers iets willen aanpassen waarvan ze weten dat ze dat willen (voor betere veiligheid) maar ze kunnen het niet meer vinden omdat alles weer anders is, dan zien ze er veelal van af. Daar help je niemand mee.

Ik heb het niet goed doordacht, maar als je een .nl domein wil, moet je naar de Stichting Internet Domeinregistratie Nederland (SIDN).

Als je echter een certificaat op je .nl domein wil, kan je dat overal ter wereld aanvragen. Zo heeft security.nl een certificaat van DigiCert Inc. Een bedrijf uit Amerika. Hebben die ook een vestiging in Nederland? Of niet?

Een DNS is weer gebaseerd op bijvoorbeeld de registratie bij SIDN voor Nederland. Het zou zo handig zijn als in je DNS record ook een publiek certificaat zat. Dan heb je die hele CA structuur niet meer nodig, toch? Gewoon voor elk toplevel domein een root certificaat in je browser. En deze ondertekent de websites onder dat toplevel domein.

Het lost ook het probleem met Let's Encrypt certificaten op, want die werken niet in .nl omdat ze daar dan niet bevoegd voor zijn. En er kunnen eisen gesteld worden aan 'SIDN' certificaten, bijvoorbeeld dat je met bewijs wie je bent langs gaat bij een kantoor in Nederland. Dit kunnen wettelijke eisen zijn die ieder land zelf kan bepalen. De gebruiker beslist dan of die een website in .ru accepteert om zijn creditcardgegevens bij achter te laten. Of om daar een nieuwsbericht te lezen.

Die controleerden alleen dat de factuur werd betaald, verder handelden ze net zo als die kofferbak verkopers.

Dat is er al, alleen het is zo krukkig en complex in elkaar getimmerd dat niemand het gebruikt.
Er is een SIMPEL record waarmee je in je domein kunt aangeven wie er certificaten kunnen uitgeven voor je domein,
maar daar doen de browsermakers niks mee. En er is een COMPLEX systeem wat een afhankelijkheid introduceert
tussen het certificaat wat je momenteel gebruikt en je DNS, iets wat je niet moet willen.
Dus gebeurt er weer niks...

Beste draadgenoten,

Zo wordt de infrastructuur bedoeld of onbedoeld (leg me dat maar eens uit?) nodeloos complex. Diginotar ellende voorbij zien komen, Symantec uit de certs gestapt, Comodo daar ook weg, enz. Nu de Panama cert route non-trusted. Het houdt niet op.

Niemand kan meer het hele plaatje overzien. Wie staan hier er ook zo in als ondergetekende? Doch nooit spijt gehad hier te zijn gearriveerd. Niet meer voor een gat te vangen, dank zij jullie allemaal.

Groetjes,

#webproxy

Dat is onjuist. SIDN beheert de database, maar voor de registratie van bijvoorbeeld een .nl domeinnaam ga je naar een domain name registrar die door de SIDN geautoriseerd is om .nl domeinnamen te registreren (en te wijzigen en verwijderen). Dat kan bij registrars overal ter wereld, bijv. bij GoDaddy of NameCheap.

Ook voor de feitelijke uitgevers van digitale (https server-) certificaten geldt dat zij veel onderaannemers hebben. Zoek maar eens naar:
ssl certificaat kopen site:nl

Sterker, net de naam van certificaatuitgevers in certificaten wordt gerotzooid: zie

The SSL Certificate Issuer Field is a Lie

in https://www.agwa.name/blog/post/the_certificate_issuer_field_is_a_lie van 18 jan. door Andrew Ayer (mijn bron: https://infosec.exchange/@_r_netsec/109724184590828864).

DNS is een onbetrouwbaar protocol (DNSSEC probeert dat op te lossen maar is geen succes). Eén voorbeeld van wat er mis kan gaan met DNS lees je in https://www.security.nl/posting/782203/Android-malware+wijzigt+dns-instellingen+wifi-routers+via+standaard+wachtwoord.

Zoiets is denkbaar, maar domeinnamen worden niet alleen voor webservers uitgegeven en certificaten niet alleen voor websites. Het is niet heel vreemd om die disciplines gescheiden te houden.

Maar bij Let's Encrypt vertrouw je uiteindelijk de DNS. De DNS leidt je naar een IP adres, en daarop kan je automatisch een Let's Encrypt certificaat aanvragen.


Dat is een keuze geweest van de ontwerpers van SSL. De encryptie die SSL gebruikt is dezelfde als die in andere protocollen gebruikt worden (bijvoorbeeld voor het ophalen van je mail met RSA-AES-SHA). Daarvoor kan dus ook hetzelfde fictieve record in DNS worden gebruikt, en dan nog kan een RFC zelf dingen toevoegen buiten de standaarden. Zoals Microsoft doet met OAuth2. Maar DNS heeft dan een record waar bijvoorbeeld een publiek 4096 bit RSA certificaat in past. Altijd handig. Je weet nooit wanneer je het nodig hebt.

UTF-8 is ook wereldwijd geaccepteerd. Waarom SSL niet?

Anoniem 18:14

Scan eens hier voor iets meer overzicht:
https://dnsviz.net/d/security.nl/dnssec/

luntrus

Antivirusbedrijf Ahnlab beschrijft in https://asec.ahnlab.com/en/45312/, naast pokemon-go.io, ook beta-pokemoncards.io

Ook die laatste website blijkt een heel stel Let's Encrypt certificaten voor "git.git.git"-achtige subdomeinnamen te hebben verkregen: zie https://crt.sh/?q=beta-pokemoncards.io.

Toevallig vond ik ook nversia.ru die het helemaal bont maakt: als ik goed tel in https://crt.sh/?q=nversia.ru * zijn er sinds maart 2022 maar liefst 1363 Let's Encrypt certificaten voor uitgegeven, voor domeinnamen zoals:
maar ook andere onzin zoals
De certificaten daarvoor zijn ook allemaal geldig voor www. gevolgd door de genoemde domeinnaam.

* Soms krijg ik een "502 gateway timeout" te zien voor crt.sh. En zo niet, dan duurt het in dit geval meerdere seconden voordat de server alle records bij elkaar gezocht heeft en een pagina heeft gegenereerd.

Ik ben benieuwd of de vele sponsors genoemd in https://letsencrypt.org/ weten waar een deel van hun geld aan verspild wordt.

Beste Erik,

Hier wordt het door jou aangehaalde chaining-misbruik op Let's Encrypt ook behandeld: https://www.mike-gualtieri.com/posts/chaining-remote-web-vulnerabilities-to-abuse-lets-encrypt.

Het is en blijft een slecht idee, deze manier van certificering.
Geen Ahnung, waarom men er ook ooit mee is begonnen?

luntrus

Dat is gekomen doordat iemand dacht dat het beter was als alles encrypted over internet ging, en daar heel erg op
ging zitten pushen. http sites mochten niet meer, moest https worden. Toen had iedereen ineens een certificaat nodig,
zelfs voor zaken waar dit totaal onnodig voor is, en moest er een methode komen om die efficienter uit te geven.
Daarmee is het kind met het badwater weggegooid, want een certificaat is niet zozeer voor encryptie maar veel meer
voor het vaststellen van de identiteit van de communicatiepartner. Dat aspect is er nu niet of nauwelijks meer.

Anoniem van 10:56,

Eens, duidelijke conclusie.

Wat moet er dan voor in de plaats komen of erbij om de juiste spam, -scam en cybercriminele kwaadaardigheid te kunnen vaststellen en ontwijken? Trust is ondergraven.

#obserwator

Je noemt geen vulnerabilitie! maar verwijst naar een domain ownership voor het verkrijgen van een certificaat. Google doet dat ook zo. Verder gaat het alleen maar over het mogelijk hacken van een challenge wat dan de consequentie is. We hebben het toch ook niet over wat de consequentie is als windows update wordt gehackt.

Die stammen misschien uit de tijd dat L.E nog geen wildcard aanbood.

Als je, in plaats van onnodig grote lappen tekst aan te halen, zou lezen wat er staat en/of op de links zou klikken (de eerste LE certs voor beta-pokemoncards.io zijn van 2 dec. 2022), zou je zien dat de meeste certificaten in de afgelopen maanden zijn uitgegeven. En had je jouw zinloze bladvulling achterwege kunnen laten.

Gisteren (2023-01-24) nog, "omdat het kan" en "het kost toch niks":

Aanvulling 16:34: bovendien willen cybercriminelen vooral unieke certificaten, omdat dan minder snel duidelijk is dat het om dezelfde kwaadaardige eigenaar gaat - en intrekking (revocation) er niet toe leidt dat al hun "sites" in één keer uit de lucht gaan. Een wildcard cert werkt overigens maar voor één subdomein-niveau, maar met SANs zouden ze, naar believen, veel subdomeinen van verschillende lengtes op kunnen nemen. Maar nogmaals, dat is niet in hun belang. Ik sluit zelfs niet uit dat ze uiteindelijk veel certificaten zelf laten intrekken en zo revocation systemen overbelasten (o.a. CRL's absurd lang maken).

Dank voor jouw bijdrage! Die meneer snapt er helemaal niets van, ik kom hier later -met argumenten waarom- op terug.

Ik denk dat je de log niet helemaal goed begrijpt. Dat is ook niet zo raar want het zit heel erg verborgen.
Voor iedere aanvraag bij Letsencrypt is er eerst een entry voor een "Precertificate" en dan pas de entry voor het eigenlijke
verleende certificaat. Het is dus normaal (en geen aanwijzing voor een nepsite) dat er voor iedere aanvraag 2 logregels
zijn.

Beste Erik,

Ik ben voorstander van 'sinkholen' van al dergelijke aantoonbare zich voortdurend bewijzende cybercriminelen. Desnoods als afschrikwekkend voorbeeld een heel AS ten voorbeeld stellen en tijdelijk neerhalen tot het opgeschoond wordt.

Wie cybercriminaliteit gedogen wil, is zelf ook cybercrimineel bezig. Ongeacht om welke 'crooks in action' het ook mag gaan.

Europol zit bijvoorbeeld al lang 'binnen' bij elke anti-virus vendor'. Laat dergelijke diensten maar eens actief worden en 'opschonend' bezig zijn.

Naar mijn weten worden nu acties tegen ransomware artiesten al gecoördineerd uitgevoerd. Dat is waar het heen moet.

Vrij baan voor de legitieme gebruiker van Internet. Naar de 'hall of shame' met de rest - de scam-, spam- & andere cybercrime artiesten.

Goed dat jij dit aankaarten wil. Vind mij aan je zijde.
Voor mij ben je dus 'een digitale kei'.

luntrus

Ah, dank voor die info! Ik wist niet wat zo'n precertificate is, meer info vond ik in https://www.thesslstore.com/blog/ssl-precertificates/.

Ik zie nu inderdaad bij https://crt.sh/?q=pokemon-go.io, als ik 2 certs met dezelfde CN vergelijk, dat deze hetzelfde serienummer hebben en dezelfde public key gebruiken - en één daarvan "CT Precertificate Poison: critical" vermeldt.

Echter, bij https://crt.sh/?q=nversia.ru zijn er dubbelingen waarbij beiden nog een "precertificate" zijn, bijvoorbeeld:

Enkele details uit https://crt.sh/?id=8488510146:

Enkele details uit https://crt.sh/?id=8488510178:

Het laatste certificaat is 2 seconden nieuwer dan het eerste, en er wordt een andere public key in gebruikt.

Hetzelfde geldt voor https://crt.sh/?id=8488473271 en https://crt.sh/?id=8488473335 voor sitemaps.nversia.ru, beide ook van gisteren, met nul seconden verschil, maar wel verschillende serienummers en verschillende public keys.

Verder lijkt het erop dat er vanaf 17 januari alleen nog precertificaten worden gelogd voor subdomeinen van nversia.ru, dus geen echt werkende certs. Zouden ze bij CT al wakker geworden zijn, maar bij LE nog niet?

Ik ben niet op zoek naar een manier om op basis van DV-certificaten (of de uitgifte daarvan) te bepalen of het om een nepsite gaat of niet, want dat gaat nooit lukken.

Waar ik bezwaar tegen maak is enerzijds het gemak waarmee cybercriminelen DV-certs kunnen verkrijgen (en de misplaatste euforie van LE dat ze weer zoveel miljoen (pre-?) certificaten hebben uitgegeven - die allemaal een vals gevoel van veiligheid geven, en anderzijds dat webbrowsers niet op z'n minst visueel onderscheid maken tussen zo'n speelgoedcertificaat en certificaten die veel minder aantrekkelijk zijn voor cybercriminelen.

Waarbij het, in één oogopslag kijkend naar de browser, geen verschil kunnen zien tussen resp. DV-, OV- en EV-certs, er in steeds meer gevallen toe leidt dat noodzakelijkerwijs door ons te vertrouwen organisaties ook maar DV-certs gaan gebruiken - waardoor zelfs het inspecteren van certificaten (voor zover de gebruikte browser dat nog ondersteunt) niet meer helpt om nep van echt te kunnen onderscheiden.

Als je, om de (naar verluidt) privacy-respecterende Signal app te kunnen blijven gebruiken, ineens een Google captcha moet invullen op https://signalcaptchas.org/challenge/generate.html (met "Amazon" DV-certificaat), dan snapt toch elk weldenkend mens dat je erin geluisd wordt - dit kan toch niet waar zijn?

Het blokkeren op basis van IP-adres is lastig. Hoewel zo te zien alle nversia.ru subdomeinnamen naar 185.178.208.170 wijzen, is dat shared hosting (er hoeft maar één brave "borsjt" tussen te zitten). Opnemen van elke individuele subdomeinnaam in "hosts" met 127.0.0.1 of 0.0.0.0 is ook ondoenlijk als er zoveel nieuwe per dag worden aangemaakt.

Ik heb, lang geleden, als test een tijdje "unbound" gedraaid, daar kon (en vermoedelijk kun) je wel eenvoudig *.nversia.ru en dergelijke mee blokkeren - waarbij ik met * ook meerdere niveaus van subdomeinen bedoel (in tegenstelling met wat in wildcard certs geldt). Maar dat zal voor weinigen weggelegd zijn en bij nieuwe TLD+1 domeinen loop je altijd achter de feiten aan.

Ik denk dat dit voorlopig politiek te gevoelig ligt. Je kunt heel Rusland wel afsluiten, maar dan vernemen óók de nog niet volledig gehersenspoelde Russen uitsluitend nog alternatieve "feiten".

Ik vrees dat het, in deze wereld, weinig zin heeft om te proberen zoveel mogelijk cybercriminelen op te sporen en achter tralies te zetten. Het is dweilen met de kraan open, met die kraan in andere landen waarvan de "bazen" er niet over peinzen om deze (op ons verzoek) dicht te draaien (ik geef alleen voorbeelden van domeinnamen, zo zijn er nog ontzettend veel meer).

Het beste dat ik kan doen is zoveel mogelijk mensen ervan proberen te overtuigen dat we digitalisering niet blindelings moeten verafgoden maar de risico's moeten inventariseren én bespreekbaar maken, dat we betere defensieve maatregelen moeten nemen om het aantal slachtoffers van cybercrime zoveel mogelijk te beperken én dat we moeten zorgen voor vangnetten voor diegenen die alsnog slachtoffer worden. Want Internet is geen "safe place" en dat gaat het nooit worden.

En hoe zit het dan met 'cloaking' verschillen tussen 'echt' en 'nepper'? Zitten er verschillen tussen wat er getoond wordt aan bijvoorbeeld Google en googlebot?

Of is het enige verschil waar of je niet wil 'belanden'?

In landen waar zelfs de honden nog 'corrupt' zijn,
kun je niet veel bereiken, wat dit aangaat.

luntrus

Dus we hebben een online certstream scanner nodig (op basis van CaliDog bijvoorbeeld).
Maar hoe krijg je het grote publiek alert genoeg?

#webproxy

Er is zoveel mis met deze uitspraak dat ik niet weet waar ik moet beginnen.

Je wilt dat Europol als certificaat uitgever en domeinnaam registratie gaat optreden? Wat stopt een crimineel om ergens anders een domeinnaam te registeren? Moet Europol dat weer teniet moeten kunnen doen?

Realiseer je je niet dat je hiermee het internet 'stuk' maakt?

Op de provider van een Europees land een domein redirecten naar een pagina van de politie is een ding. Maar om dat bij landen te doen waar je het niet mee eens bent is iets heel anders. Realiseer je ook dat Rusland hetzelfde met domeinnamen hier in Nederland zal willen doen als de technische mogelijkheid er is.

Ben je het ook eens met de blokkade van the pirate bay door Brein bij Nederlandse providers? Ziggo en XS4All waren het hier niet mee eens en om goede redenen. Je maakt het internet stuk als je dit doet. Afhankelijk van in wel land je zit krijg je een ander internet gepresenteerd.

Alles tot je dienst, maar wordt het internet nu al niet stuk gemaakt? Wat voor oplossingen stel je dan voor?

Zelfs Duolingo api niet meer veilig. Moet ieders api account straks op straat liggen met telefoonnummer, mail info? Het is al veel te ver gegaan met al die data breaches.

Waartoe dient dat aan laten modderen tot een onoverkomelijke chaos? Welke systeem krachten streven dat na door op hun handen te blijven zitten?

En die Proxy oorlog tussen twee systemen in de wereld helpt ook zeker niet. Gaan we niet heen aan de narcotica, dan aan de ransomware, de cybercrime en Big Tech data gegraai en zwarte projecten.

#webproxy

Van alles wordt er misbruikt, ook de recaptcha api op csp.withgoogle dot com op het EU Metro frontend. (1e100 dot net).

Zie: https://www.abuseipdb.com/check/2a00:1450:4001:800::200a

Wanneer gaat eindelijk de wal het schip keren? Of hebben de cybercriminelen eigenlijk al gewonnen?

#webproxy

het webforum van security.nl, waar bij iedere zinvolle discussie de hele goegemeente er op in springt met "het is allemaal een grote conspiracy".
Hoe is het dan nog mogelijk om ooit een discussie te voeren?