Door Anoniem: Door Erik van Straten: Door Anoniem: Voor mij is dit wel (opnieuw) het ultieme bewijs dat al dat gedoe rondom certificaten en beveiligde DNS waar jij steeds op hamert, niet de oplossing van het probleem is.
Ongeacht of Anoniem (Vandaag, 11:37) gelijk heeft dat het hierbij
niet om een criminele partij gaat, is dit wel (opnieuw) het
ultieme bewijs dat
https servercertificaten, waaruit blijkt wie de
eigenaar is van de domeinnaam (noodzakelijkerwijs vastgesteld door een door
internetgebruikers vertrouwde certificaatuitgever) en sterk verbeterde browsers
onmisbaar zijn voor kritische websites (sites die door de bezoeker moeten kunnen worden vertrouwd, bijv. omdat er persoons- en/of financiële- en/of medische gegevens mee worden uitgewisseld).
Maar dat levert toch niks op?
Jawel. Ook in het echte leven is weten met
wie je zaken doet een essentiële voorwaarde voor vertrouwen. Alleen
dán kun je afgaan op reputatie en/of iemand voor de rechter slepen als deze jou belazert. Als je überhaupt nog zaken wil doen als het om iemand uit een ander land gaat waar de kans op "jouw recht halen" kleiner is dan in Nederland of eventueel de EU.
Door Anoniem: Geen enkele gebruiker die dat gaat controleren,
Dat was en is onjuist, en dat *moet* veranderen; mensen moet geleerd worden dat het uiteindelijk in hun eigen belang is (ook als zij op het werk in phishing trappen) dat zij vaststellen met wie zij te maken hebben - en
hoe zeker het is dat het niet om een vervalste identiteit gaat.
Ik ken ook geen (enigszins bruikbaar) alternatief voor een paspoort of ID-kaart - waarbij de identiteit van de betrokken persoon met redelijke betrouwbaarheid is vastgesteld door een derde partij (de overheid). Dat is niet 100% waterdicht, maar hoe dichter je daar in de buurt wil komen, hoe moeilijker (en duurder) het wordt.
Door Anoniem:sterker nog: het gros van de gebruikers heeft tegenwoordig een device waar je dat niet eens KUNT controleren.
Momenteel niet (uitzondering: Chrome onder Android - een niet te onderschatten
percentage gebruikers). Maar dat valt prima te verbeteren (Big Tech zal gedwongen moeten worden, want minder phishing betekent minder inkomsten voor hen).
Bijvoorbeeld: als je met een specifieke browser voor de allereerste keer een website met een specifieke domeinnaam bezoekt, laat de browser
éérst (vóórdat er überhaupt content van de site wordt opgehaald) voor
mensen begrijpelijke identificerende informatie van de juridisch verantwoordelijke voor de website zien.
Tevens hoort daar informatie bij die beschrijft
met welke betrouwbaarheid die identiteit is vastgesteld.
En neem tutorials op in browsers waarin wordt uitgelegd
waarom de "context" belangrijk is (zie de kofferbaksale die ik eerder noemde).
Het is namelijk
zinloos om te bewijzen dat (beiden zijn bereikbaar via https://):
circleci.comde juiste domeinnaam van
jouw website is, terwijl
circle-ci.comvan een nepsite is (nogmaals, zie
https://security.nl/posting/768888 uit sept. 2022).
Tenzij ik het mij verkeerd herinner, werd, daags na de aanval in 2022, jouw browser doorgestuurd naar
https://circleci.com als je
https://circle-ci.com opende.
Dat is vandaag (en waarschijnlijk al maanden) niet meer het geval!De nepsite heeft sinds maart 2024 weer certificaten (zie
https://crt.sh/?q=circle-ci.com) en ziet er véél gelikter uit dan
https://circleci.com. Beiden hebben een Let's Encrypt certificaat.
Als je als beginnend ontwikkelaar met CI (Continuous Integration) aan de slag wilt, hoe kun je dan nep van echt onderscheiden?
Tenzij je de tegenwoordigheid van geest hebt om bijv.
https://www.virustotal.com/gui/domain/circle-ci.com/detection te bekijken (of toevallig ofwel Antiy-AVL, BitDefender, CyRadar, ESET, Fortinet, G-Data, Lionic, Sophos, VIPRE, of Webroot als virusscanner gebruikt op het apparaat waarmee je die website opent, en je dat niet deed
vóórdat de maker van die virusscanner doorhad dat de geschiedenis zich herhaalt met de foute domeinnaam)?
Uit
https://circleci.com/security/:
If you find a serious security issue such as any of the following issues, please contact us with relevant details including steps to reproduce or a proof-of-concept.
[...]
• Email spoofing, SPF, DKIM, and DMARC errors
Wat heb je daaraan als je een mail ontvangt:
From: CircleCI Support <een—naam@circle-ci.com>waarbij SPF, DKIM en DMARC netjes in orde zijn - maar jij niet weet (of je niet realiseert) dat het
circleci zonder minnetje er in moet zijn? En dat alles
mits het door jou gebruikte e-mail programma die regel niet inkort tot:
From: CircleCI Supporten je helemaal geen domeinnaam meer ziet.
Het probleem hier is is dat de kans dat een entiteit (zoals een webserver of een e-mail afzenderdomein)
authentiek is (werkelijk de geclaimde identiteit heeft) kleiner is naamate
impersonatie eenvoudiger is. Waarbij je rekening moet houden met
elke (mogelijk zwakke) schakel, waaronder onvolkomenheden van mensen zoals niet precies weten dat er géén minnertje in de domeinnaam hoort, en de TLD niet
.dev,
.io,
.net,
.me,
.biz,
.id etc. is maar
.com.
Door Anoniem: Dus wat schiet je er dan mee op?
Het maximaal haalbare.
Door Anoniem: Bovendien, indien deze pensioenregelaar vertrouwenswaardig over zou willen komen (en daadwerkelijk het vertrouwen geniet van het bedrijf waar zij het medewerkerpensioen voor zouden willen verzorgen), zouden hun domeinnamen pensioenbij.bedrijfsnaam.tld hebben geluid. Dáár hamer ik wél vaak op (mogelijk geef ik in een volgende reactie nog een hersenloos voorbeeld van hoe het niet moet). Niet dat dit perfect is, maar omdat zo'n hiërarchische domeinnaam een verbetering is t.o.v. een totaal ongerelateerde domeinnaam.
Dat is mooi voor het koppelen van een naam aan een bedrijf, maar het is weer moeilijk voor het verkrijgen van het juiste certificaat.
Betrouwbare authenticatie is duur. Als je betrouwbare authenticatie achterwege laat bij het verkrijgen van https servercertificaten, die ooit expliciet ontworpen zijn om ten minste te bevatten:
1) public key;
2) domeinnaam;
3) uniek identificerende gegevens van verantwoordelijke;
4) metadata (geldigheidsduur, uitgever etc)
dan verdwijnt punt 3 en moet elke individuele internetter zien uit te vogelen van
wie 2 is. En dat schaalt voor geen meter.
Door Anoniem: Immers degene die deze pensioen pagina regelt (externe partij) kan geen certificaten namens het betrokken bedrijf aanvragen.
Dat moet dan iemand bij het bedrijf zelf doen (wie?) en die moet dat verkregen certificaat dan veilig overhandigen aan die externe partij (hoe?).
Een certificaat mag je aan iedereen overhandigen, zo onveilig als je maar wilt. Sterker, via https geopende websites sturen hun certificaat naar elke bezoeker, hoe ombetrouwbaar ook.
Hoe dan wel: op de uiteindelijke server wordt een sleutelpaar en vervolgens een CSR (Certificate Signing Request) gegenereerd. De verantwoordelijke voor de website gaat met dat CSR naar de CSP (Certificate Service Provider, de certificaatuitgever) die vaststelt dat (en/en):
• De domeinnaam in het certificaat van de server is die over de private key beschikt die uniek past bij de public key in het CSR;
• De aanvrager daadwerkelijk degene is die verantwoordelijk is voor de website met de gegeven domeinnaam, of geautoriseerd is om namens die verantwoordelijke het certificaat aan te vragen.
Als alles klopt vult de CSP het CSR verder aan en ondertekent het digitaal, waarmee het CSR een certificaat is geworden (sinds certificate transparency zijn er meer stappen, maar die zijn niet relevant voor deze beknopte uitleg).
Door Anoniem: En na een jaar verloopt het, en moet die procedure herhaald worden (liefst daarvoor al).
Er valt heel goed een eenvoudiger aanpak te bedenken voor het
verlengen van certificaten. Essentieel is dat er bewijs geleverd wordt dat de verantwoordelijke voor een domeinnaam dat nog steeds is (de domeinnaam niet in andere handen is overgegaan).
Je zou kunnen denken aan certificaten met twee public keys: een korte-termijn voor de authenticatie van de website, en een lange termijn voor de authenticatie van de verantwoordelijke (met de daarbij passende private key natuurlijk
niet op de server).
Door Anoniem: Als ik in mijn bedrijf eens rondkijk hoe de personeelsadministratie dat zou moeten regelen dan voorzie ik een hoop ellende.
Als ik eens rondkijk en zie dat Europeanen straks met sterke authenticatie (EDIW aka EUDIW), op -onder meer- potentieel nep porno-, drank- en goksites moeten gaan bewijzen dat zij oud genoeg zijn (in de misplaatste hoop dat dit te jonge mensen tegenhoudt), of sterk moeten authenticeren op nep pensioensites - die daarmee, als "doorzetter" daarnaartoe, identiteitsfraude op authentieke websites kunnen plegen, dan voorzie ik een hoop ellende.
Sowieso: wat heeft
personeelszaken met authenticatie van websites te maken? Dit is echt een taak voor een CIO of security-officer - die direct verantwoording aflegt aan de directie. Die directie mag, net zoals Ali Niknam, verantwoording afleggen als jouw bedrijf voor de camera's gesleept wordt omdat je niet genoeg doet tegen cybercrime.
Als je,
voor jouw klanten, een betrouwbaar bedrijf wilt zijn, in de zin van dat je
hen zo goed als mogelijk helpt voorkómen dat zij in oplichting met een nepsite trappen (door hen handvatten te geven waarmee zij nep van echt
kunnen onderscheiden), heb je een voordeel op jouw concurrenten. Die welliswaar goedkoper kunnen zijn, maar alle waar naar z'n geld. Dit krijgt een boost zodra internetgebruikers in hun browser zien dat het om een risicovolle anonieme low budget website gaat, of eentje waar men respect heeft voor alle klanten.
Door Anoniem: In plaats daarvan gebruikt men dus de domeinnaam onzebedrijfsnaam.bedrijfsnaamvanservicebedrijf.nl waar dat servicebedrijf een (wildcard) cert voor gebruikt wat dus alleen garandeert dat het dat servicebedrijf is en niet ons bedrijf.
Maar dat maakt niet heel veel uit want de gebruikers geloven het toch wel.
Niet
alle gebruikers (ik niet). En als het aan mij ligt, maken we het internet veel veiliger dan het nu is, en gaat het om een toenemend aantal gebruikers die het niet langer pikt dat steeds meer onnaceptabel grote risico's op hen worden afgewenteld - waar een deel van hen daadwerkelijk en op soms afschuwelijke wijze slachtoffer van wordt.
Om een trap na te krijgen van aso's die stellen dat ze niet zo stom hadden moeten zijn, terwijl de problematiek bewust veroorzaakt wordt door hen essentiële informatie te onthouden. Onder het mom van "Geen enkele gebruiker die dat gaat controleren".
Edit 20240824 00:06: link https://circleci.com/security/ toegevoegd