[1] https://github.blog/2022-09-21-security-alert-new-phishing-campaign-targets-github-users/
[2] https://discuss.circleci.com/t/circleci-security-alert-warning-phishing-attempt-for-login-credentials/45408


De aanvallers gebruikten (vanzelfsprekend, snel en geen geldspoor) Let's Encrypt certificaten voor hun nepsite (zie https://crt.sh/?q=circle-ci.com).

Naast domeinnaam-registrars en hostingboeren, vinden uitgevers van DV (Domain Validated speelgoed-) certificaten het namelijk niet hun taak om te controleren of "circle-ci.com" een phishingsite van "circleci.com" zou kunnen zijn. Mocht dat zo zijn dan is dat jouw probleem.

Omdat bijna niemand lijkt te (willen) inzien dat:
1) je niets aan encryptie hebt als je niet weet met welke partij je communiceert (d.w.z. met de bedoelde partij of juist met misleiders die zich voordoen als), en

2) authenticatie van de server al vele jaren het enige doel is van https servercertificaten, en

3) uitgevers van DV-certificaten niet controleren wie de eigenaar is van een domeinnaam, noch of die domeinnaam misleidend kan zijn,

gebruiken ook ook [1] en [2] speelgoedcertificaten van Let's Encrypt (naast de idioterie van domeinnamen zoals "github.blog" in plaats van "blog.github.com").

Dat een arme sloeber die een thuis-NAS aan internet wil hangen daar zo'n Let's Encrypt certificaat voor gebruikt begrijp ik, maar als ook "officiële" websites (zoals [1] en [2] maar ook ggd.nl en ggdghor.nl) dat doen, kan een bezoeker niet snel aan de hand van de certificaatuitgever zien dat het waarschijnlijk om een phishingsite gaat (laat staan dat je in zo'n certificaat meer identificerende informatie van een organisatie kunt vinden dan slechts de domeinnaam, die hier juist misleidend is).

Met andere woorden, omdat bijvoorbeeld
ggdghor.nl een Let's Encrypt certificaat gebruikt, is het risico op phishing met
ggd-ghor.nl onnodig groot (omdat phishers ook bij voorkeur Let's Encrypt certificaten gebruiken).

Terug naar circle-ci.com: de meeste vormen van 2FA/MFA, zoals SMS of TOTP (Time-based One Time Password via bijvoorbeeld Google Authenticator, Authy of Microsoft Authenticator) bieden geen enkele bescherming tegen dit soort "proxy"-aanvallen.

Kortom, tenzij je een FIDO2 hardware key in WebAuthn modus gebruikt (of een PassKey, of een "slimme" wachtwoordmanager en jij je niet laat verleiden tot handmatige invoer), die in jouw plaats domeinnamen onthoudt en je uitsluitend op sites met herkende domeinnamen laat inloggen, zit er niets anders op dan zelf te onthouden dat "circleci.com" exact zo gespeld moet zijn (zonder minnetje en met uitsluitend letters uit de ASCII karakterset) om te voorkómen dat je in dit soort phishing-aanvallen trapt.

En mocht je een mail krijgen dat je naar
ggd-ghor.nl moet voor een vette tegoedbon als je een prikafspraak maakt (of een boete als je dat niet doet), of om een binnenkort noodzakelijke QR-code aan te vragen (en je dat het beste snel kunt doen omdat het binnenkort storm loopt), zul je moeten weten dat er geen minnetje in die domeinnaam hoort te staan. Want voor zo'n nepsite heb je zelfs geen hardware key of passkey die voorkómt dat je bijvoorbeeld allerlei persoonsgegevens prijsgeeft aan criminelen en/of "inlogt" via een -eveneens valse- DigiD website (met een smoes dat de DigiD-app tijdelijk niet werkt).

Blijkbaar is het dan toch te makkelijk om belangrijke dingen te doen, zoals het toevoegen van sleutels zonder daar nog eens een keer extra een wachtwoord voor te vragen.

Zelf gebruik ik FIDO2 sleutels voor zowel het inloggen op de site als voor mijn ssh sleutels.

Je doet nu net of let's encrypt fishing in de hand speelt. Het probleem dat let's encrypt oplost (dat veel websites niet beveilgd waren) weegt ruimschoots op tegen de eventuele nadelen. Dat hele systeem van uitgevers die je dan maar op hun blauwe ogen moet vertrouwen is natuurlijk ook echt hopeloos verouderd.

Je kunt veel beter mensen leren hoe fishing te herkennen en hoe het te voorkomen. Regel nummer één: klik nooit op een link om vervolgens in te loggen. Als je gaat inloggen, typ je altijd zelf de URL in.

Een FIDO2 sleutel helpt alleen tegen dit soort aanvallen als die sleutel de domeinnaam checkt en weigert als die domeinnaam niet klopt.

Als die FIDO2 sleutel tevens de mogelijkheid heeft om, bijvoorbeeld met een knopje op dat ding, handmatig een 2FA-code in te vullen in een 2FA-veld of op andere wijze op te sturen - ongeacht de domeinnaam van de server -, en je zelf niet gezien hebt dat de domeinnaam niet klopt en toch zo'n code opstuurt, helpt zo'n hardware key geheel niet tegen dit soort "proxy" aanvallen - waarbij de aanvallers onmiddelijk als jou inloggen op de echte site.

DV-certificaten waren al een probleem vóórdat Let's Encrypt begon, maar LE heeft het phishers enorm veel eenvoudiger gemaakt doordat hun certificaten gratis zijn (geen money trail) en een certificaat volledig geautomatiseerd en binnen seconden geïnstalleerd is. Ideaal voor phishers met wegwerpdomeinen dus.

Het gaat niet om beveiliging van websites, maar om beveiligde verbindingen.

Omdat het versleutelen van een verbinding met een website van criminelen, zoals "circle-ci.com", totaal zinloos is (uit oogpunt van de bezoeker), is het noodzakelijk dat de bezoeker zeker weet dat diens webbrowser een verbinding heeft met een website van de bedoelde eigenaar, ongeacht de domeinnaam (die er sterk op kan lijken). DV-certificaten helpen websurfers hier geheel niet mee; integendeel, hen is geleerd dat een slotje voor een "veilige website" staat.

Zo te zien heb je er geen idee van hoe ondermijnend dit soort aanvallen zijn voor het internet en digitalisering in het algemeen.

Ik zie niet wat dat met deze aanval te maken heeft: tenzij je er heel diep induikt en alle rootcertificaten die je niet vertrouwt verwijdert of blokkeert, ben je afhankelijk van dit systeem.

Klinkt leuk maar heel vaak bevatten links in mails aanvullende informatie om, na inloggen, een speciale handeling uit te voeren (zo ook in dit geval). Doordat de meeste organisaties mails met links erin versturen, wordt mensen juist geleerd om te klikken op links in mails. Als je dat niet doet moet je op de kennelijke website op zoek naar die functionaliteit - en iedereen die dat wel eens gedaan heeft, weet hoe eenvoudig dat meestal niet is.

Interessant vind ik ook de boze reacties in [2] die ik eerder noemde: circleci zou DMARC onjuist hebben geconfigureerd (p=none). Dat is onhandig, maar of dat veel slachtoffers had voorkómen, betwijfel ik.

Want als je een mail-account bij Microsoft hebt en *@circleci.com als "safe sender" hebt aangemerkt, wordt DMARC genegeerd en komt de mail van een ander afzenderdomein, dat zich voordoet als circleco.com, gewoon in jouw inbox.

Daarnaast vraag ik mij af hoeveel van die slachtoffers het zou zijn opgevallen als de criminelen "circle-ci.com" als afzenderdomein hadden gebruikt (dat de aanvallers zelf van geldige SPF, DKIM en DMARC hadden kunnen voorzien).

2FA is iets wat je kwijt kan raken plus iets wat je kan vergeten.

Gebruikers zouden altijd zelf de afweging moeten kunnen maken of ze dit willen. Zelf wil ik alleen 2FA voor mijn bank en verder niets. Vooral geen dingen waarbij ik toegang verlies tot al mijn data en documenten. Als het echt belangrijk is zet ik er wel een goed wachtwoord op en zorg ik dat ik die alleen invoer op vertrouwde apparatuur.

Ik had Js uit staan dus mijn originele uitgebreide/onderbouwde reactie is waarschijnlijk verloren gegaan.

Korte samevatting:

Dit is geen technisch probleem. of tenminste, het is een ander technisch probleem.

De oplossing is on computergebruik zo moeilijk te maken dat je er zonder goede basis geen gebruik van kunt maken.

PEBKAC

Een van de redenen om desondanks HTTPS te prefereren boven HTTP is dat sommige internetproviders waren begonnen om advertenties te injecteren in pagina's die via HTTP werden geladen. Voor zover ik weet is dat niet in Nederland gebeurd, maar in het VK wel. Je hebt het dan over een soort MITM-aanval waarbij het er niet toe doet met welke server je eigenlijk verbinding maakt, het gaat erom dat er iets aangepast kan worden. Vanuit het perspectief van aanbieders van webpagina's die bewust geen advertenties bevatten is het zeer onwenselijk dat er internetproviders zijn die doodleuk advertienties aan de pagina's gaan toevoegen. Vanuit het perspectief van aanbieders van pagina's met advertenties trouwens ook. HTTPS blokkeert dat soort ongein.

En het maakt verschil voor elke netwerk node waar netwerkverkeer langs komt. HTTP staat echt wagenwijd open voor MITM-aanvallen. Zelfs zonder dat je weet wie eigenlijk die HTTPS-webserver bestiert voegt het al wat toe dat in ieder geval geregeld is dat je een foutmelding krijgt als er met het verkeer tussen jou en die server geknoeid is.

Voor zover ik het begrepen heb is dat de motivatie geweest voor Let's Encrypt, of een belangrijk deel van de motivatie.

Ja, het zou geweldig zijn als de verificatie van alle certificaataanvragers zo sterk zou zijn dat het slotje in de adresbalk zekerheid zou geven dat je met een bona fide partij in verbinding staat. Maar die zekerheid had je voor Let's Encrypt ook al niet, CA's hadden allang de verwachtingen op dat vlak beschaamd. In de praktijk lijkt dat een gepasseerd station te zijn.

Juist, en dan nog: Ten eerste zouden er genoeg zijn waar dit zelfs niet genoeg voor zou zijn. Ten tweede zouden de aanvallers andere manieren vinden om menselijke zwakheden te exploiteren.

Men zou misschien iets gebaseerd op virusscanners of spamfilters kunnen implementeren (maar dan in reverse). Bijvoorbeeld een laagje tussen de gebruiker en de programma's. Iets met plugins and signatures. Een gebruiker wil een programma starten (bijv. browser) maar in werkelijkheid start de gebruiker een browser specifieke plugin wrapper die competentie test (gebaseerd op signatures voor een plugin die je kunt bijwerken) alvorens al dan niet tot uitvoeren van het doel programma over te gaan. Niet scherp genoeg? -> Access denied.

Die plugins en signatures kunnen dan op maat gemaakt worden voor betreffende programma's. Je kunt ze bijwerken zodat dingen met de tijd mee gaan. (subscription model $$$$$$)

Veiligheidsdiensten
Als ik mij niet heel erg vergis werd het belangrijkste argument aangedragen door Edward Snowden, namelijk dat internetverkeer massaal werd afgeluisterd door veiligheidsdiensten. Vandaar dat de EFF zo'n voorstander was en is van https.

Omdat veiligheidsdiensten zelfs versleuteld (https) verkeer massaal zouden opslaan wordt de symmetrische sessiesleutel allang niet meer door de webbrowser gegenereerd en versleuteld met de public key uit het servercertificaat (waarna alleen degene die over de bijpassende private key beschikt, normaal gesproken de webserver, die sessiesleutel kan decrypten), maar wordt het Diffie-Hellman (DH) algoritme gebruikt voor de symmetrische "key agreement".

Sterker, in moderne https-certificaten staat dat de public key daarin uitsluitend gebruikt mag worden voor het checken van digitale handtekeningen. Zo'n "signing" certificaat heeft dan ook geen enkele relatie meer met het versleutelen van https verbindingen; het enige doel is het bewijzen van de identiteit van de server (doordat de server de hash van een aantal verbindingsparameters versleutelt, waardoor iedereen die het certificaat met public key heeft kan checken of aan de clientzijde gebruik gemaakt wordt van exact dezelfde verbindingsparameters, en er dus geen aanvaller tussen zit).

Doel van DH en "signing certificates": mocht een geheime dienst ooit de private key van de server opeisen, dan kan daarmee, dankzij DH, niet alle eerder door die veiligheidsdienst opgeslagen versleutelde communicatie worden ontsleuteld (daarom wordt het gebruik van DH en signing certs "forward secrecy" genoemd; pas vanaf het moment dat een derde de private key van een webserver in bezit heeft, kan die partij zich voordoen als die webserver).

Om dezelfde reden wordt DoH aangemoedigd en ondersteunt TLSv1.3 versleutelde SNI.

Adverteerders
Ongetwijfeld werden de EFF en andere privacy-organisaties hierbij enorm gesteund door partijen die leven van advertentie-inkomsten, zoals Google, Facebook en dergelijke. Niet omdat die adverteerders zich zorgen maken over de privacy van burgers, of dat burgers teveel advertenties zouden zien, maar omdat (zoals je schreef) hun advertenties in webpagina's werden vervangen door die van anderen, maar ook vanwege "click fraud": partijen "onderweg" die deden alsof de gebruiker "aan het einde van de lijn" op een advertentie klikte.

Derde partijen buiten de deur
Een versleutelde verbinding tussen een webserver gegeven diens domeinnaam en een webbrowser voorkómt de meeste vormen van toegang tot die verbinding door derde partijen. Daar bestaan uitzonderingen op, maar dat zijn incidenten vergeleken met de eenvoud en massaliteit waarmee http-verkeer werd afgeluisterd, gewijzigd en/of omgeleid.

Voor de (vertegenwoordigers van de) adverteerders (de twee-en-een-halfde partijen) zijn DV (Domain Validated) certificaten goed genoeg; die houden die derde partijen buiten de deur. Ook als je alleen maar wilt dat veiligheidsdiensten (ook derde partijen) niet massaal kunnen afluisteren, volstaan in de meeste gevallen DV-certificaten.

Nb. veiligheidsdiensten kunnen nog steeds meta-data vergaren (in elk geval van-naar IP-adressen, het aantal uitgewisselde bytes en daarmee zelfs versleutelde webpagina's identificeren) en onversleuteld aftappen bij hosting- en CDN-providers. Ook kunnen ze actieve aanvallen uitvoeren door een server direct vóór de echte server te plaatsen (met hetzelfde IP-adres dus), daar een DV-certificaat voor aanvragen (bijvoorbeeld van Let's Encrypt) en daar (desgewenst selectief, bijv. afhankelijk van het IP-adres van de client) nauwelijks detecteerbare Attacker-in-the-Middle aanvallen mee uitvoeren. Maar dit is allemaal veel meer gedoe en/of levert minder "intel" op dan http-verkeer afluisteren deed.

Je hebt (deels) gelijk
Je hebt dus gelijk dat DV-certificaten derde partijen buiten de deur houden (niet de twee-en-een-halfde partijen: adverteerders, analytics-boeren en ordinaire meekijkers waarvan de website-eigenaar vindt dat zij mogen meekijken en manipuleren).

Echter, voor burgers die zich netjes aan de wet houden (dus niets te vrezen zouden moeten hebben van veiligheidsdiensten), en die zelf geen last hadden van vervangen advertenties en/of klik-fraude, zijn deze certificaten irrelevant. Voor hen is het van primair belang dat een website, van een tweede partij, van de organisatie is waarvan zij denken dat die website is, en dat zij niet om de tuin worden geleid door cybercriminelen.

Klopt. Ik heb dan ook altijd gepleit voor https i.p.v. http.

Maar waar het hier om gaat is niet http versus https, maar https met een legitieme partij versus https met een criminele partij die zich voordoet als een legitieme partij.

Wat een onzin. "Mijn bankrekening is geplunderd maar gelukkig kreeg ik geen https foutmelding en kon er niemand meekijken!"

Sterker, als jouw router en/of jouw ISP http verkeer op kwaadaardige links en/of content scannen, zou http wel eens veiliger kunnen zijn dan https. Niet voor niets zijn er organisaties en virusscanners die je rootcertificaten laten installeren om "TLS-inspectie" te kunnen doen.

Zonder dat soort (controversiële en nieuwe risico's introducerende) maatregelen zijn organisaties volledig afhankelijk van "endpoint security" maatregelen, die een single point of failure vormen (en te vaak niet werken). Ik zeg niet dat we naar http terug moeten, maar wel dat we veel te weinig zekerheden hebben over de andere kant van versleutelde verbindingen.

Dat is larie want dat kan nooit. Als jij zaken doet met iemand waarvan jij precies weet wie het is, zegt dat totaal niets over de betrouwbaarheid van die persoon. Hooguit weet je hoe die persoon zich in het verleden heeft gedragen, maar dat biedt geen harde garanties voor de toekomst.

Het beste dat we met techniek voor elkaar kunnen krijgen, is dat je redelijk zeker weet met welke partij je communiceert en dat dit niet eenvoudig gespoofed kan worden. DV-certificaten blijken in de praktijk veel te eenvoudig te misbruiken door criminelen.

Vergelijkbaar: als je vindt dat er teveel jongeren met grote messen rondlopen en verbieden niet helpt, kun je er ook voor zorgen dat die grote messen niet "bij de HEMA voor het grijpen liggen".

Er zijn incidenten geweest (zoals de hack van Diginotar). Maar die wegen nauwelijks op tegen hoe vaak het goed ging en gaat. En dat is nodig ook, want er bestaat, in de praktijk, geen alternatief.

Helaas zijn EV-certificaten onderdrukt doordat de USA geen fatsoenlijke federale kamer van koophandel heeft (waardoor onderzoekers konden demonstreren dat je in elk van twee staten een andere organisatie kon oprichten die dezelfde EV-karakeristieken kreeg, bijvoorbeeld "Duplicate, Inc. [USA]").

Nog veel meer helaas is dat webrowsers sindsdien niet in één oogopslag duidelijk maken dat de server een DV- of een betrouwbaarder certificaat heeft opgestuurd.

Zoals ik al eerder aangaf: een gebruiker heeft niets aan een DV-certificaat als hij/zij niet weet of een domeinnaam van de bedoelde organisatie is of niet - vooral niet als misbruik supereenvoudig is omdat Let's Encrypt (maar ook andere DV-cert-uitgevers), zonder blikken of blozen, certificaten uitgeven die duidelijk bedoeld zijn voor phishing, en dat in no time, zonder enige vorm van authenticatie van de aanvrager en geheel gratis. Dat is de kat op het spek binden.

Voorbeelden: microsoft-sso.net, mlcrosoft.cloud en mlcrosoft.info (die laatste krijgt al meer dan 2 jaar DV-certs, zie https://crt.sh/?q=mlcrosoft.info). Drie voorbeelden uit een lange lijst met domeinnamen te vinden in https://blog.group-ib.com/0ktapus (bron: https://www.security.nl/posting/765689/Tienduizend+accounts+bij+130+organisaties+getroffen+door+grote+phishingaanval).

Ligt dit probleem niet eerder in de keten? Bij het verstrekken van het domein?
Een DV is, zoals bedoeld, alleen een validatie dat de server hoort bij een domeinnaam. Totaal niet of een domein naam hoort bij de eigenaar van het domein. Die stap zou al eerder gedaan moeten zijn: bij het aanvragen van het domein. Volgens mij zou daar de controle al plaats moeten vinden of een domeinnaam niet bij een andere club hoort. Wat dat betreft zit er geen verschil tussen de domeinnaam verstrekker, en het certificaat verstrekker. Dus deze zouden beide het domein niet mogen uitgeven lijkt mij. Dus dan beter bij de bron aanpakken. Zonder domein kun je ook geen certificaat aanvragen.

Je kunt een backup maken op een ander apparaat, ik bedoel niet syncen.

Nee, om meerdere redenen:

1) Er vindt ook phishing plaats met domeinnamen die nauwelijks of niet met de kennelijke organisatie te maken hebben. Die zijn vaak lastig van echt te onderscheiden omdat veel organisaties ook zulke stomme dingen doen.

2) Als je een domein verzinmaar.xyz hebt gekocht, is het veel lastiger voor domeinnaamboeren om te voorkomen dat jij een domein als login.microsoftonline.com.verzinmaar.xyz registreert.

3) Als een crimineel de DNS-records van een organisatie hackt, is het daarna een koud kunstje om voor nepservers DV-certificaten te verkrijgen. Een nieuwe techniek daarbij is Domain Shadowing waarbij bestaande records niet worden gewijzigd, maar er nieuwe worden toegevoegd - waardoor er minder snel alarmbellen kunnen gaan rinkelen. Voorbeeld: stel dat aanvallers toegang krijgen tot de DNS-records van digid.nl, zij toevoegen: aanmelden.digid.nl verwijzend naar een server onder hun controle, waar ze vervolgens bijna instantaan een DV-certificaat voor kunnen verkrijgen. Meer info: https://unit42.paloaltonetworks.com/domain-shadowing/ (bron: https://www.bleepingcomputer.com/news/security/domain-shadowing-becoming-more-popular-among-cybercriminals/).

4) Ook zonder hack van je DNS-records kunnen er problemen ontstaan als je een subdomeinnaam laat "bungelen", bekend als "dangling subdomain" of "subdomain takeover". Zie https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover. Overigens hoeft dat niet jouw "fout" te zijn: zeer veel organisaties hebben een subdomein zoals e.example.com dat direct of indirect (CNAME) naar een of meer servers van een derde partij verwijst - die hun mailings verzorgen. Als zo'n derde partij gehacked wordt (niet ondenkbaar, denk aan mailchimp) en de aanvallers toegang krijgen tot die server(s) -en wellicht de adresdatabase- kunnen zij er een webserver van maken, een DV-certificaat voor verkrijgen en een phishingcampagne opzetten.

5) Dat je jouw DNS-records niet goed beheert of prutsers vertrouwt, is natuurlijk stom. Maar sowieso is standaard DNS een zeer onveilig protocol. Een veiligheidsdienst (of een foute medewerker van een hostingbedrijf) hoeft niets aan jouw server te veranderen om het netwerkverkeer ermee (desgewenst selectief, afhankelijk van het IP-adres van de client) af te kunnen luisteren: als zij er een server vóór kunnen plaatsen die (tijdelijk) hetzelfde IP-adres heeft, krijgen ze daar gewoon een DV-certificaat voor. E.e.a. kan in principe ook met DNS-poisioning-aanvallen, maar ik kan me niet herinneren gelezen te hebben van een succesvolle aanval daarmee.

6) Ten slotte vinden er ook BGP-hijacks plaats. Vorige week schreef Dan Goodin dat criminelen in augustus het netwerkverkeer bedoeld voor cryptocurrencyboer "Celer Bridge" met domeinnaam cbridge-prod2.celer.network een paar uur hebben omgeleid naar een andere locatie. In die paar uur kregen ze een DV-certificaat waardoor klanten van, naar verluidt, $234,866.65 werden bestolen. Zie https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/.

Nb. omdat https://cbridge.celer.network/ (*) ook een Let's Encrypt DV-certificaat gebruikt (althans de site met die naam die ik zojuist bezocht, wie weet zijn ze weer gehijacked) heb je geen idee met welke organisatie je communiceert.

(*) security.nl wil hier niet eens een clickable domeinnaam van maken, zal wel aan het TLD liggen (het wachten is op het moment dat je .local kunt registreren)

Dit zijn allemaal redenen waarom je, in elk geval zolang browsers geen duidelijk onderscheid laten zien met OV- en EV-certificaten, geen DV-certificaten moet willen hebben. DNSSEC en RPKI zijn nog geen groot succes, maar zelfs als dat ooit wel zo is, lossen ze maar een deel van de problemen op.

DNS is er voor identificatie, certificaten zijn er voor authenticatie. En niet voor de server waar de IP-pakketjes tijdens de certificaataanvraag en/of nu toevallig mee worden uitgewisseld, maar voor een server van een specifieke eigenaar. Want dat is waar bezoekers mee willen communiceren, niet met een nepsite - ook klopt de domeinnaam of lijkt de domeinnaam te kloppen.

Sterker, als DNS en routering 100% betrouwbaar zouden zijn, zouden we geen DV-certificaten nodig hebben; een ongeauthenticeerde versleutelde verbinding zou dan volstaan. En dat is het kromme: om een DV-certificaat te kunnen vertrouwen, moet je (in elk geval tijdens de certificaataanvraag) voor 100% op DNS en routering kunnen vertrouwen. Russische roulette dus.

Aanvulling op mijn post van 01:51 hierboven: die 6 punten zijn natuurlijk naast het feit dat voor nagenoeg alle phishing-websites (naast gehackte webservers die al een certificaat hadden), DV-certificaten worden aangevraagd en geïnstalleerd, die veel te eenvoudig (no questions asked) en gratis te verkrijgen zijn.

Pak maar een willekeurige "vreemde" domeinnaam uit https://github.com/mitchellkrogza/Phishing.Database/blob/master/phishing-domains-NEW-today.txt en vul die in op https://crt.sh/.

Nb. "vreemde" zoals "steamcomnulinty.ru", "verify-lnstagram.bedrijfmaju.com" of "microsoft-sicherheitsupdate.com", want in die lijst staan ook domeinnamen van legitieme doch gehackte webservers waaraan phishing-webpagina's zijn toegevoegd, zoals op dit moment "rijschoolhoorn.nl" (de phishing-inlog-pagina voor de Capital One bank, hxxps://rijschoolhoorn[.]nl/de/capone/, is momenteel nog live; zie https://urlscan.io/result/a302637d-6287-4b8f-86fa-27a21f01fd0f/ voor info).

Volgens mij is DNS het telefoonboek van het internet. Of te wel: wat is het IP van security.nl
Een certificaat is ALLEEN om je er van te verzekeren dat jij een veilige verbinding hebt naar de server die zegt security.nl te heten.

Een EV certificaat heeft nog aan vullende informatie zoals hoe het bedrijf achter de aanvrager heet.

Een certificaat is niet voor authenticatie. Alleen voor de versleuteling. Niets meer en niets minder.

Bij de al jaren gebruikelijke "forward secrecy" (Diffie-Hellman key agreement) wordt het https servercertificaat niet eens meer gebruikt om de symmetrisch encryptiesleutel veilig (via de nog onversleutelde verbinding) van de client naar de server te sturen.

M.a.w. bij DH heb je geen certificaat meer nodig als de authenticiteit van de server jou niet interesseert.

Uitsluitend omdat de meeste mensen, die verbinding maken met bijvoorbeeld https://mijn.ing.nl, wél zeker willen weten dat dit niet een server van cybercriminelen is maar een server van de bedoelde bank, stuurt die bank een door de browser vertrouwd https servercertificaat naar de browser, waarna de de server bewijst over de bijbehorende private key te beschikken. Het enige doel van een https servercertificaat is dus authenticatie van de server.