Aan de rechterkant van deze pagina is momenteel een vacature bij Vecozo te zien. Als ik daarop druk wordt mijn browser doorgestuurd naar een URL die begint met https://werkenbij.vecozo.nl/ waarvoor die website een OV certificaat naar mijn browser stuurt, dat geldig is voor:
• vecozo.nl
• www.vecozo.nl
• werkenbij.vecozo.nl
• verwijzen.vecozo.nl

De tenaamstellingsgegevens zijn:
CN: vecozo.nl
Country: Netherlands
City: Tilburg
Organization: VECOZO B.V.

Mijn complimenten, zo hoort het!

(Nou nog mobiele browsers die alle bovenstaande gegevens tonen).

Je hebt blijkbaar gemist wat de reden was voor de push naar "alles encrypted" .

Dat was om de _massale_ en niet-legale interceptie van "alles" ('sleepnet') die gedaan werd (bij ATT 'room 641A' werd toevallig 'betrapt' dankzij een whistleblower) dwars te zitten .
De onthulling van Snowden kwamen daar natuurlijk nog bovenop .

Je moet leren om breder te kijken , en niet zo'n monomane focus en het bericht uitdragen hebben dat als iets nog kwetsbaar is voor een _gerichte_ _high-effort_ aanval het DUS HELEMAAL NUTTELOOS is.

Er is qua interceptie een waanzinnig verschil tussen plaintext en de noodzaak om een actieve MITM in het verkeer te brengen, danwel het juridisch key/content vorderings verhaal in te gaan.
De interceptie capaciteit, zelfs van een NSA is uiteindelijk eindig .

Ik heb net idee dat je bent blijven hangen in het historische gebruik van SSL - alleen 'high value' bestemming (zelfs alleen de authenticate.bank URL ) gebruiken SSL, en er is een heel zwaar toekennings proces voor een certificaat, zodat 'vanzelf' alleen heel erg betrouwbare bestemmingen (en heel erg slimme admins) uberhaupt een cert willen/kunnen krijgen.
Met de race to the bottom van budget certificaat boeren was er dan nog het 'EV' cert om (kunstmatig) een duurder cert extra waardevol te maken met een groener kleurtje .
Die 'meerwaarde' is nooit echt zichtbaar geland in de markt en gebruikersperceptie en dus weer afgevoerd.

Jammer de bammer . "alles en niks encrypted" gaat niet samen met 'alle aanvragers zwaar gechecked' en de wereld is geland op "alles en niks encrypted" .

Ik ben het hier wel mee eens. De oplossing zit niet in de infrastructuur, de oplossing zit in mindset een keuzes.

Willen we een veilig internet, of willen we een anoniem internet. Dat is alvast de eerste fundamentele keuze, want deze twee gaan niet eindig hand in hand samen.

Tot zover de correcte analyse en samenvatting van alweer een herhaling van grotendeels onterecht klagen.

Ja, inderdaad: de aanwezige hypotetische potentie is prachtig!
Net als het fabuleus fantatisch zou zijn als elk domein op het internet en omg. accurate SPF records zou hebben...

Het wordt alleen wel vervelend als ik de realiteit niet kan accepteren en constant mijn gelijk blijf proberen te halen tegen beter weten in.

En er was meer. Ik herinner me een bericht over een Britse ISP die was begonnen om in websites die zijn klanten via HTTP benaderden advertenties te injecteren. Dan is je eigen ISP, waar je al aan betaalt voor toegang, een commerciële MITM met parasitair gedrag.

Je kunt erop wachten totdat cloud-hosting partijen, en vooral CDN's zoals Cloudflare en Fastly, precies dat gaan doen.

Iets wat we trouwens, via een andere route, al volstrekt normaal zijn gaan vinden. Namelijk dat elke bezoeker van de meeste websites (voor de eigenaren van die websites volstrekt onvoorspelbare advertenties, van volstrekt onvoorspelbare adverteerders) via RTB (Real Time Bidding) in webpagina's (binnen kaders daarvoor) geïnjecteerde advertenties worden voorgeschoteld, noodzakelijk geacht door de eigenaren van die websites (om inkomsten te genereren).

M.a.w. die gepersonaliseerde advertenties krijg je in hun opdracht te zien, zonder dat zij weten wat jij te zien krijgt. En zonder dat zij en jij weten wie de adverteerder is en hoe betrouwbaar deze is (denk bijvoorbeeld aan popups die stellen dat er een virus is aangetroffen op jouw PC of smartphone, en je dringend word geadviseerd om "the ultimate anti-malware solution" te sideloaden, maar -vooral in de VS- politiek geörienteerde leugens).

Met als "bijvangst" voor die adverteerders, toegevoegde kennis m.b.t. de op dit moment door jou bezochte website.

Je ZULT advertenties te zien krijgen, gewenst of niet. Los van of dit een acceptabel inkomstenmodel vormt, en wat daar een beter alternatief voor zou zijn; misschien is het een idee om niet de FUD van de Google's van deze wereld na te kakelen?

oh ja, dat herinner ik me nu ook .

Ik heb de tijdslijn niet meer scherp genoeg om te weten of dat ook duwde naar 'encryptie overal' , maar als het op het juiste moment gebeurde zal het zeker meegespeeld hebben.

Deed ik dat dan?

 
Heb je überhaupt wel gelezen wat je aanhaalt?
 
 
Uit https://infosec.exchange/@ErikvanStraten/112914050216821746:
Dat voorbeeld laat fraai zien dat aanvallers (in dit geval mogelijk een overheid, maar welke?), dankzij ANONIEM en zelfs gratis te verkrijgen DV-certificaten, doodsimpel versleutelde verbindingen kunnen aftappen.

LET OP: bovenstaande AitM aanval werd pas bij toeval ontdekt toen de AitM-eigenaar bleek te hebben vergeten om het valse DV-certificaat voor de AitM proxy bijtijds te vernieuwen. Met als gevolg dat bezoekers van jabber.ru gingen klagen over certificaatfoutmeldingen. Wat voor de beheerder van jabber.ru een totale verassing was, omdat hij de certificaten voor de (echte) jabber.ru server steeds bijtijds had vernieuwd.

Met DV-certs heb je geen idee of overheden tappen. Ik geloof er dan ook helemaal niets van dat dit uitsluitend bij jabber.ru gebeurde, en nu nergens meer. Bijvoorbeeld https://t.me en https://telegram.org lijken mij kansrijke kandidaten (dat wil niet zeggen dat iedereen die op Telegram z'n middelvinger opsteekt, onmiddellijk wordt opgepakt. Want overheden willen natuurlijk niet dat, INDIEN zij Telegram tappen, dit bekend wordt - doordat zij een, blaffende maar niet bijtende, naïeve dwaas -die anoniem denkt te kunnen zijn- op de guillotine te leggen).

Merk op dat precies DIT hét scenario is waar Google (en door hen gesponsorde boter-op-het-hoofd clubs) voor waarschuwde dat QWAC's mogelijk zouden maken.

Stel dat een overheid ál het netwerkverkeer (of een specifiek deel daarvan) met server S wil afluisteren, zonder die server S zelf "aan te raken", of (op afstand) te hacken. Dan volstaat het voor die overheid om een (AitM) proxy (kortstondig) tussen S en ergens op de netwerktoute naar de DNS-checker van Let's Encrypt (of een andere DV-certuitgever) te plaatsen, om zo een DV-certificaat bestemd voor S te verkrijgen. Afhankelijk van de certificaatverstrekker kan, met het onterecht verkregen DV-certificaat, 3 maanden of 1 jaar "getapt" worden (de keuze, door de AitM-proxy-eigenaar, voor de certificaatverstrekker kan worden beperkt middels CAA. Sowieso is het verstandig om bij dezelfde CA te shoppen, omdat bijv. Firefox voor Android wél kan laten zien wie de CA is, en als je méér ziet, geen websitebezoeker certificaatserienummers e.d. gaat checken - voor zover daaruit iets zinvols valt af te leiden).

Dat kunnen tappen betekent overigens niet alleen dat de eigenaar (overheid, crimineel, of een door voornoemden onbedoelde hacker / dubbelspion) van de AitM-proxy onbeperkt kan afluisteren. Maar ook dat deze, on-the-fly, data bestemd voor bezoekers van S kan manipuleren. Dat kan zówel tijdens het uploaden naar S (eenvoudiger detecteerbaar door de uploader - tenzij je die uploader, als een soort rootkit, bij het teruglezen iets anders laat zien dan elke ander). Of door (later, na ongewijzigde upload), bezoekers van S (desgewenst filterend op alle, of één of meer specifieke, bezoekers), gemanipuleerde data te verstrekken. Naast dat via de AitM-proxy op deze manier tekstuële informatie vervalst kan worden (waaronder het wijzigen van daarin opgenomen URL's), kan ook malware worden geïnjecteerd.

Cloudflare groeit als kool en sluit steeds meer haar ogen voor cybercrime; zij claimen slechts "doorgever" te zijn en daarom geen enkele verantwoordelijkheid te dragen (zie https://arstechnica.com/security/2024/07/cloudflare-once-again-comes-under-pressure-for-enabling-abusive-sites/ van afgelopen week, door door Dan Goodin).

CDN-provider Fastly lijkt strenger, maar hergebruikt, al vele jaren, slechts enkele asymmetrische sleutelparen voor duizenden websites van haar klanten, met honderd domeinnamen van klanten per certificaat. Als Fastly moeilijk doet als overheden willen "meekijken" op onversleuteld netwerkverkeer met al die klanten, hoeven three-letter agencies slechts (met FISA section 702 in de hand) een kopie van die paar private keys op te eisen - om daarna (*) al het netwerkverkeer met al die klanten te kunnen AitM'en.

(*) Forward secrecy voorkómt dat zij daarmee eerder opgeslagen, versleuteld, netwerkverkeer kunnen decrypten, maar FS biedt geen enkele bescherming meer zodra een private key in "verkeerde" handen valt.

Stel dat de NSA wil weten wat men uitspookt bij russianorthodoxchurchlondon.ca, of bij grupoalcazar.cl, of beide. In dat laatste geval komt de NSA een heel eind als deze zou beschikken over drie private keys passend bij de drie public keys waarvan de eerste 15 bytes van de modulus de volgende waardes hebben:

Die private keys passen bij de public keys waarvan de sha256 waarde steeds op het einde van de volgende drie URL's te zien is:
(1) https://crt.sh/?spkisha256=17a8d38a1f559246194bccae62a794ff80d419e849fa78811a4910d7283c1f75

(2) https://crt.sh/?spkisha256=6b81681f2127b0585ab88c74c3f801ef2c2c943ead58693cdc9d85e8fbf5a610

(3) https://crt.sh/?spkisha256=bbdd71febbfd8af32b5ced1dbba37600123a0628957c3d13f7d0d3133a2a4afe

Nb. op zo'n link drukken heeft geen zin omdat crt.sh dan "crasht" doordat er veel te veel "hits" zijn (dat crt.sh niet crasht bij meer dan de gebruikelijke 1 of 2 resultaten zie je met https://crt.sh/?spkisha256=2fddfadff8bd22ba1b8a7822df9a12cce0293627b95388e517bb3376c3126ae7 van tweakers.net).

Vanaf het moment dat de NSA over kopiën van één of meer van de genoemde 3 private keys beschikt, kunnen zij -op door hen gewenste netwerkknooppunten- naar hartelust tappen.

Ter illustratie geef ik enkele linkjes naar, in het kader van CT (Certificate Transparency) gelogde, recente (nog geldige) certificaten, met met elk 100 domeinnamen (waarvan ik elke keer 4 voorbeelden noem), die de NSA zou kunnen AitM'en indien zij over een kopie van de betreffende private key beschikken:

https://crt.sh/?id=14011564365: pubkey: (3)
voertuigvinder.nl, postyoga.ru, cookieapps.kr, pensioenbij.spservices.nl

https://crt.sh/?id=13981048722: pubkey: (2)
hebjijhetgoudenei.nl, www.ticketwallet.nl, bouwbedrijflove.nl, dsm.appdashboard.nl

https://crt.sh/?id=14010846840: pubkey: (1)
dev.gods.gift, puv.jp, worldwidetakeover.harteliebe.de, runno.dev

https://crt.sh/?id=14008253568: pubkey: (1)
bigdata.pelalawankab.go.id, app.wauthier-ctp.be, promstroiservice.ru, recipeo.cz

https://crt.sh/?id=13648963743: pubkey: (3)
membership.toray-research.co.jp, sispro.ec, www.akti.com.tr, verwoerd.it

https://crt.sh/?id=13756445475: pubkey: (2)
verwoerd.it, www.verwoerd.it, butthole.dev, www.torihius.fi

Hoe kan ik die vraag beantwoorden als ik niet eens weet of jij dezelfde anoniem bent als de anoniem die de FUD van de Google's van deze wereld nakakelt?

Is deel van 't probleem niet gewoon dat er 2 functies in 1 oplossing gepropt zijn?

1: Zorgen dat alle verbindingen encrypted zijn.
2: Aantonen dat je verbonden bent met een bepaalde partij.

Die 2 zouden losgekoppeld moeten worden. De meeste websites hebben geen belang aan punt 2, maar de gebruiker heeft altijd belang bij punt 1.

Punt 1 zou dus standaard moeten zijn (en plain HTTP kan dan ook gewoon verdwijnen), met punt 2 optioneel en eventueel betaald; banken e.d. zouden dan wettelijk verplicht aan punt 2 moeten voldoen, terwijl de voor meeste websites het prima voldoet om alleen punt 1 te hebben.

Dit is gedaan omdat het niet veel zin heeft om een verbinding te encrypten als je niet zeker weet dat je verbonden bent met de partij die je denkt.
Immers als je dat niet zeker weet dan kan iemand "halfweg" ook de verbinding naar jou toe onderscheppen, het verkeer naar jou toe decrypten, bekijken, opnieuw encrypten, en naar jou toe sturen.
Dan vervalt het dus het voordeel van "iemand halfweg kan niet meekijken".

(ik schrijf het maar even kort en bondig en zonder gebruik van vette letters en bij lezers waarschijnlijk onbekende afkortingen)

 

Natuurlijk.
Maar waarom wil je zo graag laten zien dat je NOG STEEDS NIET BEGRIJPT wat het verschil is tussen massaal in bulk aftappen (plaintext) en actieve/inter-actieve interceptie wat - zoals je aanhaalt - best zichtbaar is en orden van grootte duurder dan plaintext sniffen ?

Kom je weer met een berg links van actieve interceptie - alsof dat net zo makkelijk is als slurpen van 100+G linken met plaintext verkeer .

Je hebt blijkbaar een stroman : "TLS is helemaal perfect en als er maar TLS gebruikt wordt kan er op geen enkele manier ook maar iets gedaan worden met het verkeer".
En tegen die stroman ben je met een enorme brij aan details aan het vechten alsof de hele wereld daar (nog) in gelooft.

Of denk je werkelijk dat iets wat met de nodige inzet en moeite _kan_ tegen enkele domeinen wil zeggen dat daarom massaal ongericht afluisteren nog steeds makkelijk is ? Dat is een bijzonder onlogische "conclusie" .

Security - en zeker globale verschuivingen in gebruik, protocol of applicaties is ALTIJD een trade-off van een hele hoop belangen en noodzakelijkheden. Soms binnen het security domein zelf, soms (alleen) tussen security en resources/kosten , of security vs usability .

Professionals realiseren zich dat - mensen als Bruce Schneier schrijven al decennia boeken om dat inzichtelijk te maken .
De keuzes (of uitkomsten) zijn niet altijd geweldig - Bruce's 'movie plot threat' is een voorbeeld.


Nee, dit voorbeeld laat zien dat er actief en zichtbaar werk nodig was om deze site af te luisteren, wat bij plaintext verkeer ontzettend veel makkelijker en ontzettend veel onmerkbaarder geweest zou zijn.


En bedenk nu hoe onzichtbaar de tap geweest zou zijn als jabber in plaintext liep.

Geavanceerder - stuxnet werd publiek betrapt omdat google applicaties 'certificate pinning' deden , dus klaagden ondanks een valide (niet eens DV) certificaat .
Vergeleken met plaintext - TLS interceptie is veel zichtbaarder , 'duurder' dan plaintext interceptie .

'alles is encrypted' is alleen maar mogelijk met enorm geautomatiseerde certificaat uitgifte - en dus een niet perfecte controle van aanvragers. Soit.

De functies _zijn_ in zekere zin losgekoppeld , met een self-signed certificaat heb je al (1) maar , zonder extra kennis geen (2).

Of de gebruiker 1+2 nodig heeft hangt af van het threat model .
Als je streeft naar privacy in een sleepnettende wereld, of een passieve afluisteraar op een stuk netwerk dat je gebruikt heb je inderdaad genoeg aan 1.

Maar een actieve afluisteraar (actief = kan verkeer omleiden , sessie termineren etc - a mitm) kan dan nog steeds verkeer van de gebruiker onderscheppen of manipuleren als aan 2 niet voldaan is.
Het kost, vergeleken met passief meeluisteren meer moeite (dus massaal onderschappen is veel lastiger geworden) - maar is vaak dus niet onmogelijk.
Erik besteed veel tijd aan het laten zien van wat voorbeelden ervan (en dat extrapoleren tot "reusachtig probleem fout concept")

De identiteits-garantie van de meeste certificaat-uitgevers is en was vrij beperkt.

Er was ooit - EV extended validation - als concept, maar dat is gewoon mislukt . Het was er, de browsers lieten het verschil zien, maar "de markt en de gebruikers" hebben het verschil tussen een 'gewoon' en EV certificaat nooit voldoende opgepakt om levensvatbaar te blijven.

Diverse banken (en aimgh ook overheids sites )hadden netjes inderdaad EV certificaten , maar uiteindelijk mislukt.
EV vereiste dus een bezoek aan het bedrijf, contract, handtekeningen van tekenbevoegde bij de KvK , cert op de juridische bedrijfsnaam etc etc.



Zie EV. Het was er en werkte niet.

Webverkeer is ontzettend zichtbaar - maar op precies dezelfde manier is er SSH (vs telnet).
De host-fingerprint van SSH moet bewijzen dat je met de juiste server connect, en die zou je op een betrouwbare manier moeten krijgen (liefst voordat je verbinding maakt) .
Het IS een enorme verbetering tov van telnet/rlogin .
Maar zonder check op de host key blijft er een risico voor een actieve aanvaller bestaan.

Handen in de lucht van serverbeheerders die structureel elke 'host key changed' melding najagen ...

Dat is, even kort door de bocht, zo'n beetje het onderscheid tussen DV- en EV-certificaten (er zit nog iets tussen dat OV-certificaten heet, maar ik kan me niet herinneren dat me ooit is opgevallen dat ik die in het echt tegenkwam). Bij DV is alleen gecontroleerd of de aanvrager bij dingen kan waarvoor je beheerder van de website moet zijn, bij EV is ook gecontroleerd of de aanvrager is wie die beweert te zijn.

Een belangrijke reden dat er, voor zover ik kan overzien, niets te bedenken is dat echt goed werkt is dat er een grote groep mensen is die een onderscheid tussen "dit kan ik vertrouwen" en "dit kan ik niet vertrouwen" willen zien en voor wie elk systeem dat genuanceerder werkt te moeilijk blijkt te zijn. Dat de verbinding naar een website behoorlijk versleuteld is (DV-niveau) zegt nog niets over van wie die website is en of die wel betrouwbaar is. Dat de eigenaar van een website met redelijke zekerheid vaststaat (EV-niveau) wil nog helemaal niet zeggen dat die eigenaar geen schurk is of niet voortdurend allerlei steken laat vallen.

Daar komt nog bij dat veel van de mensen voor wie dat allemaal te ingewikkeld is ook geen URL in de adresbalk van de browser weten te lezen en dus zonder het door te hebben een betrouwbare verbinding kunnen hebben naar een malafide site in plaats van naar de site die ze denken te bezoeken.

Zie dat maar op te lossen.

Het is precies andersom. Als security.nl nog http zou ondersteunen, en ik zou daar een http-verbinding mee openen en een betrouwbaar en herkenbaar persoon (met een account dus, bijv. Briolet) zou een goede tip hebben voor een handig stukje software, dan kan de lezer van die posting belazerd worden en malware installeren (de aanval kan ook later plaatsvinden, als dat stukje software via een verbinding met een niet geauthenticeerde server - een andere dan bedoeld - wordt gedownload).

Hetzelfde geldt voor bijv. Marktplaats - waar je een https verbinding mee hebt. Dat helpt je geen zier als je daar een Rolex koopg en een doos met een dode mus (of helemaal niks) krijgt thuisgestuurd. Vooral niet als die persoon vervolgens ongrijpbaar blijkt.

Ik vraag mij zó onzettend af waarom sommige nitwits op security.nl reageren.

Ik ook!

Dat een iemand een account heeft zegt helemaal niets over die persoon of zijn bedoelingen.
Dat soort (h)erkenning is schijnveiligheid. Net zoals het helemaal niets zegt of iemand wel of niet anoniem reageert.

Heb jij het woord "reputatie" nog niet gehad - op de basisschool?

Zeker wel. Reputatie is niets anders dan een vluchtige perceptie gebaseerd op subjectieve waarneming.
Het is net als een Bratwurst. Alleen in Duitsland is ie lekker, want in Nederland is de saus toch anders.

Het is ook niet generiek oplosbaar.

Er is een hele overlappende serie van 'betrouwbaarheid' betekenissen.

Een certificaat kan onterecht voor voor een site uitgegeven zijn, waarna een actieve man-in-the middle mogelijk is.
Dat kunnen (tijdelijke) hacks zijn voor DV , het kunnen gehackte CAs zijn (diginotar als bekend voorbeeld), het kunnen staats-CAs die verplicht moeten meewerken , het kan het gestolen (hack) valide certificaat van de feitelijke site zijn.

Het kan een naams-gelijkende site zijn, met valide certificaat voor de net-niet naam . (lngbank.com , ofzo) .
Alles kan technisch kloppen , alleen de site-operator is onbetrouwbaar .

Er is gewoon geen generieke manier waarop je _en_ 'overal' encryptie kunt hebben _en_ diepgaande controle dat aangevraagde certificaten bij de juiste site horen , en dan ook nog controle op typo-squatters of "gaat misschien gebruikt worden voor abuse" sites .

In beperkte domeinen is het wel mogelijk om het VEEL beter te doen .
Google applicaties (chrome) doen aan certificate pinning voor google services . Dat haalt een hoop aanvalsvectoren op google services onderuit. Stuxnet is op die manier betrapt - ondanks een technisch valide cert door een hack van een CA (diginotar).

Ik verwacht dat Apple software precies zo Apple services controleert, en dat iemand die van een erkende CA een apple/icloud certificaat weet te krijgen daar toch weinig of geen misbruik mee kan plegen.

Ook verwacht ik dat bjvoorbeeld banking apps ten eerste natuurlijk ongevoelig zijn voor typo squatting, maar ook certificate pinning doen en niet "gewoon" de OS CA store gebruiken . Of wellicht geen volledige pinning maar wel een aantal aanvullende checks.
(speculatie - ik heb niet de tijd of de faciliteit om het 'even' te testen. Moet wel te doen zijn, evt met een android emulator, een eigen root-CA toevoegen, en kijken welke apps je kunt MITM'en en welke apps een harde check doen op het het juiste certificaat. ).

Voor een bedrijf/service betekent een harde pinning dat je bij eventuele certificaat wissel "alle" apps snel genoeg moet kunnen laten updaten , en je hebt altijd een percentage gebruikers die daar lang mee wacht of dat nooit doet .
Het voordeel zit erin dat je je gebruikers beter beschermt tegen relatief geavanceerde aanvallers die erin slagen een certificaat voor je domein te krijgen .

En dan kun je ook nog bedenken dat er een zekere verschuiving is naar een 'virtueel' web . Je kunt "facebook" ook beschouwen als een virtueel eigen internet . De site is bekend en betrouwbaar genoeg, en dan heb je alleen te maken met entiteiten die binnen facebook bestaan en daarbinnen gevalideerd (of niet) zijn.
Of zoals de 'gevalideerde' X (twitter) accounts .

Zoals de stroman "een betrouwbare verbinding met een valide tweedehands-site zegt dat de verkopers op de site ook betrouwbaar zijn" aanvallen , alsof dat werkelijk een breed gedeelde misvatting is die door security experts bestreden moet worden ?

Nu ja, misschien moet het telkens weer uitgelegd worden.

Joh dit is precies wat ik al een aantal malen probeer duidelijk te maken.

Betrouwbaarheid is door externen manipuleerbaar. Daar veranderen certificaten niets aan, sterker nog het risico op verminderde transparantie word daarmee zelfs veel groter. Je vertrouwd op iets wat onbetrouwbaar is.

Het kan niet waar zijn dat wij dit al security professional’s proberen uit te dragen (en de rest wegzetten als nitwits)

Jawel [1]. Nooit 100% betrouwbaar, maar er zou m.i. wel een indicatie moeten worden meegegeven van de betrouwbaarheid (niet van de eigenaar, maar van de zorgvuldigheid waamee de identiteit van de verantwoordelijke voor de website is vastgesteld).

We stoppen ook niet met paspoorten omdat daarbij, in een klein deel van de gevallen, tijdens de uitgifte gefraudeerd wordt.

[1] Zie vanaf "Noodzakelijke veranderingen" in https://security.nl/posting/852741.

We hadden DV, OV en EV certificaten , precies dat , inclusief de indicatie in browsers (iig bij EV) _dat_ er behoorlijk zwaar gecontroleerd was wie de eigenaar was.

(Nu had EV nog steeds de beperking dat name-collisions in verschillende juridische domeinen mogelijk zijn - "Stripe, Inc" uit Kentucky kon opgericht worden en een EV certificate krijgen - maar is niet de payment processor "Stripe, Inc" uit Delaware .)

Maar hoofdzakelijk is gebleken - en onderzocht - dat de gebruikers de extra veiligheid (of extra alertheid) bij EV sites gewoon niet zagen.

Het is geprobeerd,op wereldwijde schaal, _met_ browser support , het werkte niet , maar je hebt dat wiel opnieuw uitgevonden ?


Huh ? Is er uberhaupt iemand die wil stoppen met TLS certificaten ?

Van alle participanten spring jij er het meeste uit als degene die een kleine fractie aan fraude (of een mogelijke aanval met behoorlijke effort ) gelijk stelt aan een totaal systeem falen waarvoor alles anders moet .

De realiteit was gewoon dat registrars geen beep gaven om verificatie.
Hoi klant wil een EV certificaat. Dat kan uiteraard vul hier alle informatie in. Hartelijk bedankt oh ik zie dat de naam hier anders staat en ook het telefoonnummer. Ah klanten je kent het wel. We passen de naam even aan in de tussentijd kunnen jullie dit totaal niet te controleren 06 nummer als verificatie nummer erin zetten? Sure doen we top top.

Hey de certificaat uitgever geeft aan dat ze geen contact kunnen krijgen met de partij hebben jullie een alternatief mail adres? sure hier een niet te controleren hotmail adres. Top thanks bij deze meldt certificaat uitgever dat certificaat is uitgegeven. Super volgend jaar weer dit gezeik? Nah we bellen meteen wel alternatieve nummer en mailen email adres wat nergens als vertrouwd staat in ons systeem. Cool Cool. Hier hebben jullie de 150 euro van de 320 die we aan de klant hebben verkocht.


Dat is hoe het er in groot deel van de puinhoop aan toe ging bij ISP's
Uiteraard was sales wel heel enthousiast want peperduur product met weinig moeite.
Want dat was het simpele oplichterij eaarbij de focus niet was veiligheid maar bedrijfsnaam marketing.
Hey de bank heeft zijn naam jn de adres balk dat wil ik ook!

Dan had je de klanten die om zoveel tijd naam verandering deden van bedrijf maar de EV notatie veranderde niet dus ineens had je een legitiem domein met een bedrijfsnaam erin vermeldt dat compeet niet overeen kwam met de inhoud van de site.

Dan had je de ellende van klanten die overal subdomains hadden en waar je zeker in begin bij EV uitgevers er expliciet stond geldt niet voor subdomeinen. Dus dan mocht je losse aanschaffen regelen en afwijkende vernieuwing datums bij gaan houden.
Gevolg vaak uitval want contactpersoon was er niet of zelfs niet meer werkzaam.

Ik denk werkelijk waar niet dat er hier veel mensen zijn die met certificaten in massa hebben gewerkt want de regulering was een puinzooi er was niks veiligs aan dit de uitgevers liepen de kantjes ervan af we hebben zelfs een grote gerenomeerde partij een keer betrapt op het niet bellen voor verificatie van eigenaar en gewoon meteen de boel werdt uitgegeven.

Dus ja DV is ruk Maar EV en ook OV was dat ook. Verschil kosten mensen kosten.
De enige manier dat je dit goed krijgt is door strenge controle op straffe van afnemen vergunningen. En we weten allemaal dat gaat niet gebeuren. Dus het is tamelijk nutteloos om te klagen over certificaten omdat het na dat we te maken kregen met massa hype voor EV (ja dat was een ding vanuit marketing) het *nooit* meer betrouwbaar was het was een lucratief busines model geworden niet meer een tool.

Dus doe jezelf een lol en kap met druk maken over iets dat realistisch nooit meer gerepareerd gaat worden.
Net zo als dat SPF DKIM DMARC nu een komedie zijn geworden omdat grote bedrijven geen beep geven om hoe veilig alles is enkel hoeveel risico ze lopen op juridische bsht. En dan krijg je dus taferelen waarop sommige grote spelers eisen van verzenders buiten hun om dat ze al die sht in orde hebben terwijl hun eigen mail clusters door business afspraken nooit geblokeerd worden ongeacht de status van zojuist genoemde DNS records.

Maak je druk om de volgende reeks CVE daar kun je wel wat mee maar dit is een done deal leer er mee te leven of ga met pensioen.

Sorry hoor maar dat is een bullshit verhaal!
Wij haalden onze certificaten altijd bij de als slecht bekend staande prijsvechter Comodo en wat je daar beschrijft dat gebeurde daar zelfs niet voor "normale" (dus niet EV en niet DV) certificaten!
Man man man wat heb ik vaak door een hoepels moeten springen om ons certificaat weer verlengd te krijgen.
Adres wat vorig jaar nog acceptabel was (bijv info@ of postmaster@) dat mocht ineens niet meer.
Dan moest je weer een adres kiezen/aanmaken wat ZIJ bepaalden.
Zelfs toen we onze ICT hadden geoutsourced en die partij voor ons certificaten ging aanvragen was er nog dat gezeur.
En "doe toch niet zo moeilijk we hebben dit certificaat al 10 jaar" dat werkte echt niet.

Ja echt bshit? Wel hier is een redacted versie van een van onze contacten jaren geleden omtrent een SSL/TLS.

Klinkt dat als betrouwbaar een registrar die doorgeeft op verzoek van SSL leverancier of ze het adres mogen aanpassen. In plaats dat er zoals het hoort gewoon een nieuwe KVK-aanpassing door de klant zou moeten worden uitgevoerd en de aanvraag herstart had moeten worden door alle betrokkenen?


Betrouwbaar niet?

Dat het jou niet is overkomen ben ik alleen maar blij voor. Maar bullshit noemen omdat het jou niet is overkomen, dat is een rookie reactie eentje die ik heel erg ontraadt want het zorgt voor tunnelvisie. Jouw ervaring is als bedrijf beheerder gok ik? Wij beheren honderden als managed provider via rechstreekse inkoop bij DC's. Iets andere lijntjes en reactietijden van vendors. Maar dan nog mag dit nooit gebeuren, maar dat was of beter gezegd is wel de realiteit.

Dus noem het bshit wat je wil, maar het gaat niet veranderen hoe slordig het er achter de schermen echt aan toe ging en nog gaat bij sommige. En dat is waarom providers zoals ons zeiden fck them we gaan wel over op DV"s want what is the point als de validatie niet eens door ons zelf als mediator correct kan worden bestempeld?

Wat heel wat verhitte discussies heeft gekost met sales managers kan ik je vertellen uit eigen ervaringen en van andere Operations Managers omdat het sales hun bonus raakte. Het was een melkkoe die gelukkig in obscuriteit raakte door het verdwijnen van de naam in de adresbalk en wat schandalen waardoor de illusie van veiligheid ook weg was. Dat wil niet zeggen dat ik het eens ben met de reden en motivatie van de browser partijen hierover, maar ik ga ook niet doen alsof het resultaat slecht was voor ons en onze klanten. En zoals de meeste in de industrie we simply moved on.

En Sectigo (Voorheen Comodo CA) was hier ook net zo makkelijk in. Je hebt simpelweg niet genoeg contact met ze gehad om daar een ander oordeel over te vormen en wees daar maar blij om. En dat is meeste wat ik qua eigen mening erover ga zeggen.


Maar je hoeft mij uiteraard niet te geloven hier een los voorbeeldje van een kleine organisatie onder de naam Mozilla Foundation dat discussie voert over hoe Sectigo twee bedrijven door elkaar heeft gehaald bij een aanvraag en dit vaker gebeurt. https://groups.google.com/g/mozilla.dev.security.policy/c/Cd8PtS3vtvU