image

Let's Encrypt dicht achterdeur bij bevestigen aangevraagde tls-certificaten

dinsdag 20 december 2022, 11:44 door Redactie, 14 reacties

Let's Encrypt ondersteunt sinds een aantal dagen een andere manier voor het bevestigen van aangevraagde tls-certificaten, wat moet voorkomen dat aanvallers een certificaat in handen kunnen krijgen. Tls-certificaten worden gebruikt voor het opzetten van een versleutelde verbinding tussen websites en bezoekers en identificatie. Let's Encrypt, dat gratis tls-certificaten uitgeeft, beschikt over verschillende methodes om te controleren of de aanvrager van een certificaat ook de eigenaar van het bijbehorende domein is.

Een van de methodes is domeinvalidatie. Daarbij genereert de certificaatautoriteit een willekeurige string die de certificaataanvrager via zijn domein beschikbaar moet maken, bijvoorbeeld via http of een dns txt-record. Daarmee kan de aanvrager aangeven dat hij controle over het domein heeft, en dus de legitieme beheerder is. Bij het uitvoeren van domeinvalidatie is er echter nog geen certificaat. Wanneer de certificaatautoriteit (CA) verifieert dat het domein over de vereiste string beschikt gebeurt dit dan ook via het onversleutelde http, wat kwetsbaar is voor man-in-the-middle-aanvallen.

"We hebben dus een heel proces om websites certificaten van certificaatautoriteiten te laten krijgen, om ervoor te zorgen dat ze niet kwetsbaar voor man-in-the-middle-aanvallen zijn, waar in het gebruikte proces een certificaatautoriteit een website verifieert op een manier die kwetsbaar is voor man-in-the-middle-aanvallen. Als je niet bekend bent met de CA-industrie, zie je misschien niet de logica hier", zegt webontwikkelaar Hugo Landau.

Uitgegeven certificaten worden bijgehouden in Certificate Transparency (CT) logs. Zelfs wanneer een aanvaller de validatie van een domein door een certificaatautoriteit via een man-in-the-middle-aanval weet te onderscheppen, en zo het certificaat in handen krijgt, is het voor de echte domeineigenaar zichtbaar in het CT-log. Ondanks de kwetsbaarheid van het domeinvalidatiemodel, blijkt het verkeerd uitgeven van certificaten een zeldzaamheid te zijn. Dat neemt niet weg dat het model kwetsbaar is voor man-in-the-middle-aanvallen .

Sinds een aantal dagen ondersteunt Let's Encrypt echter ACME (Automatic Certificate Management Environment) CAA (Certification Authority Authorization) account and method binding, die deze achterdeur dicht, aldus Landau. Daarbij maakt de certificaataanvrager een specifiek dns-record aan waarin de naam van de certificaatautoriteit staat die voor de domeinnaam een certificaat mag uitgeven en een specifiek account. Dit is dan het account van de certificaataanvrager.

Zelfs wanneer een aanvaller een certificaatautoriteit, zoals Let's Encrypt, kan overtuigen dat ze de legitieme eigenaar van een domein zijn, kunnen ze niet zomaar een account bij Let's Encrypt aanmaken en daarmee het certificaat ontvangen. Het CAA-record staat namelijk alleen toe dat een bepaald, door de domeineigenaar opgegeven account, het certificaat aanvraagt. Daarnaast kunnen de aanvallers ook geen certificaatverzoek bij een andere certificaatautoriteit indienen, aangezien in het CAA-record staat dat alleen de opgegeven certificaatautoriteit dit mag doen.

Image

Reacties (14)
20-12-2022, 12:16 door Erik van Straten - Bijgewerkt: 20-12-2022, 12:18
Let's Encrypt (en andere DV-cert-boeren) bieden schijnveiligheid. Internetters mogen het helemaal zelf uitzoeken of een domeinnaam wel of niet van een bedoelde organisatie is, en daar bestaat geen eenduidige procedure voor.

Erger, DV-boeren faciliteren cybercrime doordat zij, met enorme oogkleppen op, certificaten blijven uitgeven aan duidelijk voor phishing bedoelde domeinnamen, zoals login.mlcrosoft.support (zie [1]) en microsofloffice365.com ([2]; ik ken nog véél meer voorbeelden).

[1] https://crt.sh/?q=login.mlcrosoft.support
[2] https://crt.sh/?q=microsofloffice365.com (al 24x, hardleers?)

Speelgoedcertificaten zijn het. Webbrowsers zouden internetters moeten waarschuwen bij DV-certs, maar in plaats daarvan hebben ze EV-certs in de ban gedaan.

Phishing is mogelijk het grootste cyberrisico op internet, en we doen er niks aan dat structureel helpt.
20-12-2022, 12:52 door Anoniem
Door Erik van Straten: Phishing is mogelijk het grootste cyberrisico op internet, en we doen er niks aan dat structureel helpt.

Hiervoor is de FIDO2 WebAuthn standaard ontwikkeld. Die voorkomt nagenoeg alle vormen van phishing.
20-12-2022, 13:33 door -Peter-
Door Erik van Straten:Erger, DV-boeren faciliteren cybercrime doordat zij, met enorme oogkleppen op, certificaten blijven uitgeven aan duidelijk voor phishing bedoelde domeinnamen, zoals login.mlcrosoft.support (zie [1]) en microsofloffice365.com ([2]; ik ken nog véél meer voorbeelden).

aka.ms bijvoorbeeld?
youtu.be misschien?

Domeinen waarvan jij denkt dat het duidelijk phishing domeinen zijn, blijken in de praktijk relatief vaak door de betreffende organisatie te zijn aangevraagd.

Daarnaast kunnen organisaties zelf heel goed (laten) controleren of voor dergelijke domeinen certificaten zijn aagevraagd. Dat doen ze ook niet.

Als laatste blijken er gewoon organisaties te zijn in land X waarvan de naam overeenkomt met een organisatie in land Y. Wie beslist dan of organisatie.X uitgegeven mag worden als organisatie.Y al bestaat?

Peter
20-12-2022, 14:14 door Anoniem
Letsencrypt is een @#$@#$ bedrijfje, zelfs als je een dry-run doet geven ze je hostname aan google.
20-12-2022, 14:45 door Anoniem
Door Anoniem: Letsencrypt is een @#$@#$ bedrijfje, zelfs als je een dry-run doet geven ze je hostname aan google.

euh... dat is zo'n beetje iedere grootte CA op dit moment via Certificate Transparency logs. Want het is voor alles en iedereen zichtbaar, inclusief Google.

Dus ik weet niet waar jij je precies druk om maakt.
20-12-2022, 15:08 door Anoniem
Hoera een certificering voor je certificering zodat je een certificaat kan aanvragen..
Blij dat het voor ze gefixed is minder blij dat we weer DNS troep erbij krijgen.
20-12-2022, 15:14 door Erik van Straten - Bijgewerkt: 20-12-2022, 15:52
Het lijkt erop dat op deze site vooral cybercriminelen reageren die, met eenvoudig te pareren argumenten (maar daar moet ik dan wel elke keer tijd voor hebben en de moeite voor willen nemen) willen dat er niks verandert, en als er wat verandert, dat dit zoveel mogelijk in hun voordeel is.

Door Anoniem:
Door Erik van Straten: Phishing is mogelijk het grootste cyberrisico op internet, en we doen er niks aan dat structureel helpt.

Hiervoor is de FIDO2 WebAuthn standaard ontwikkeld. Die voorkomt nagenoeg alle vormen van phishing.
Nee, de FIDO2 WebAuthn standaard is niet ontwikkeld om aan te tonen dat een website van een bedoelde organisatie is, en bovendien voorkomt een FIDO2 hardware key -afhankelijk van de definitie van phishing- in veel meer gevallen dan wordt gesuggereerd niet dat slachtoffers vertrouwelijke informatie met onbedoelde partijen delen of dat zij op andere wijze in een val trappen waardoor phishing alsnog mogelijk is.

Daarnaast ondersteunen (nog) maar heel weinig websites WebAuthn en zijn hardware keys gedrochten van dingen voor doorsnee internetters (want het is bezopen dat je minstens 2 keys moet hebben om account-lockout te voorkomen bij verlies of defectraken van één daarvan, en ook nog eens dat je er zelf om moet denken om ze "gesynchroniseerd" te houden - wat zuigt als het advies luidt om altijd één exemplaar in een kluis te bewaren).

M.b.t. authenticatie van websites, in de volgende situaties heb je NIETS aan jouw FIDO2 hardware key (of passkey):

1) Websites waarop je geen account hebt maar vanwege de aangeboden informatie, links en downloads, wilt weten of die website authentiek is - in de zin van "wie is de eigenaar" en is dat een mij bekende en daardoor vertrouwde partij (bijvoorbeeld omdat die partij een bepaalde reputatie heeft opgebouwd);

2) Websites waarop je nog geen account hebt maar wel wilt aanmaken. Zoals voor een PGO (zie [3] en de verwijzingen daarin; zowel https://vitaalbank.nl/ als https://mijnpgo.org/ (anderen heb ik niet gecheckt) gebruiken Let's Encrypt certs en zijn dus, als je niet de exacte domeinnaam kent, niet te onderscheiden van identieke websites met afwijkende domeinnamen.

3) Zodra jouw paspoort op jouw smartphone staat [4], willekeurige websites die willen dat jij authenticeert zonder dat jij weet bij wie je dat doet noch of zij, met jouw identificatie, niet als AitM (Attacker in the Middle) met jouw identiteit op een heel andere website (en wellicht voor een heel ander doel) als zijnde jou authenticeren. Bijvoorbeeld zo een lening op jouw naam afsluiten en cashen. Overigens heb ik medewerkers van de Wallet-ID en IRMA aangeraden ([5], "Plus" artikel) om, naast de identificerende gegevens die met een private key op de client worden ondertekend, tevens het https certificaat van de vragende website op te nemen en op te sturen. Bij een AitM-aanval (via een "evil proxy") kan de feitelijke RP (Relying Party, effectief de identiteit validerende site) zien dat de browser (of andere app) niet hun certificaat onder ogen had. Een mogelijk "nadeel" hiervan zijn problemen door "legitieme" TLS inspectie.

4) Een nepwebsite met (licht) afwijkende domeinnaam die je laat inloggen met WebAuthn en meldt dat er iets mis gaat, en vervolgens vermeldt dat er iets mis lijkt met jouw hardware/passkey en je daarom op alternatieve wijze moet inloggen.Nb. dit heeft alleen zin als die alternatieve inlogmanier ook mogelijk is op de echte inlogpagina, maar heel vaak is dat het geval.

5) Als jouw client device gecompromitteerd is.

[3] https://security.nl/posting/778360

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

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

Aanvankelijk hadden https servercertificaten twee doelen:
a) Authenticatie van de website én de eigenaar;
b) Veilig transporteren van de symmetrische sessiesleutel via de, nog onversleutelde, verbinding.

Doel b) is (al jaren geleden) komen te vervallen sinds forward secrecy wordt gebruikt (via de Diffie-Hellman key agreement methode). De public key in moderne https servercertificaten mag niet eens meer gebruikt worden voor versleuteling, maar uitsluitend nog voor het valideren van digitale handtekeningen. Daarmee hebben moderne https servercertificaten niets meer te maken met de versleutelde verbinding tussen browser en webserver, maar dienen uitsluitend ter authenticatie van de server. Dat we daarbij authenticatie van de eigenaar achterwege menen te kunnen laten, is een blunder van jewelste - cybercriminelen lachen zich rot.

Door -Peter-: Domeinen waarvan jij denkt dat het duidelijk phishing domeinen zijn, blijken in de praktijk relatief vaak door de betreffende organisatie te zijn aangevraagd.
Je zwamt.
https://www.virustotal.com/gui/domain/login.mlcrosoft.support
https://www.virustotal.com/gui/domain/microsofloffice365.com
Ook recent: findappledevice.info,
www-xiaomi.com etc. etc.
Zie https://github.com/mitchellkrogza/Phishing.Database/blob/master/phishing-domains-NEW-today.txt (een klein deel daarvan zijn gecompromitteerde websites, dus domeinnamen die niet door cybercriminelen zijn geregistreerd).
20-12-2022, 15:23 door Anoniem
Door Anoniem:
Door Anoniem: Letsencrypt is een @#$@#$ bedrijfje, zelfs als je een dry-run doet geven ze je hostname aan google.

euh... dat is zo'n beetje iedere grootte CA op dit moment via Certificate Transparency logs. Want het is voor alles en iedereen zichtbaar, inclusief Google.

Dus ik weet niet waar jij je precies druk om maakt.

DRY-RUN <<<<<<< dat betekend er hoort helemaal niets ergens opgeslagen te worden.

En sinds wanneer moet er voor een log entry ergens, een dns request worden uitgevoerd?
20-12-2022, 17:45 door Anoniem
Door Erik van Straten: Erger, DV-boeren faciliteren cybercrime doordat zij, met enorme oogkleppen op, certificaten blijven uitgeven aan duidelijk voor phishing bedoelde domeinnamen, zoals login.mlcrosoft.support (zie [1]) en microsofloffice365.com ([2]; ik ken nog véél meer voorbeelden).

Het was goed geweest als ze gewoon certificaten in 2 delen hadden opgedeeld zoals eerst het geval was, waar het geregistreerde bedrijf zo'n groen textje kreeg voor de domein naam.

Dan had je gewone certificaten die iedereen kon aanmaken, en certificaten waarvoor je een background check moest doorlopen.

Ik zou graag iets in die vorm zien terugkomen.
20-12-2022, 22:09 door Anoniem
Compromitering gaat door, ook al denk je weer terug veilig te zijn.
Al te goed is de certificeringsgek.
20-12-2022, 23:33 door Erik van Straten
Door Anoniem: Dan had je gewone certificaten die iedereen kon aanmaken, en certificaten waarvoor je een background check moest doorlopen.
Er bestaan zelfs/nog steeds 3 verschillende soorten https servercertificaten:

1) DV (Domain Validated)
2) OV (Organization Validated)
3) EV (Extended Validation)

Maar met die verschillen schiet je niks op als browsers geen onderscheid meer laten zien.

Met Firefox onder Android kan ik nog net zien wie de uitgever is van een certificaat, maar niet aan welke organisatie het certificaat is afgegeven (ook niet als dat in het certificaat is opgenomen).

"Google safe browsing" blokkeerde vanmiddag hxxps://realest0022-secondary.z13.web.core.windows[.]net/ niet, en zojuist nog steeds niet (lekker betrouwbaar). Bovenin de pagina zie ik een felblauwe balk met witte wolkjes en "OneDrive". Daaronder:
Verify Your Identity

You've received a secure file
564.1MB

To receive and download this Docx file, please enter specific professional email credentials that this document was sent to.

En daaronder een veld om je e-mailadres in te vullen en een "Next" knop. Ik heb een niet bestaand mail adres bij outlook.com ingevuld en "Next" gedrukt, waarna de "Next" knop vervangen werd door een wachtwoordveld en een "Sign In" knop. Een onzin-wachtwoord leidde binnen 1 seconde tot de melding "Wrong password! Please try again". Dit is dus waarschijnlijk een "evil proxy" die mogelijk ook met TOTP 2FA codes kan omgaan (zie https://www.security.nl/posting/778668/TOTP+Authenticators+drama).

Case in point: toen ik met Firefox voor Android op het slotje drukte en vervolgens op > rechts van "Connection is secure", zag ik: "Verified by: Microsoft Corporation". Ik ben niet verbaasd dat sommigen (velen?) die een e-mail met een link naar zo'n "OneDrive" pagina ontvangen, hier intrappen (no thanks, Microsoft).

Onder iOS 15.x weet Firefox niets meer te melden dan "de verbinding is beveiligd" als je op het slotje drukt, en Safari vertelt je zo mogelijk nog minder.

Waarom zou je als organisatie nog moeilijk doen en veel geld uitgeven aan OV of EV certs?

We zitten, qua betrouwbaarheid van het internet, in een neerwaartse spiraal - en bijna niemand lijkt zich daar wat van aan te trekken. We digitaliseren steeds verder op drijfzand.
21-12-2022, 15:40 door Anoniem
Heel mooi verhaal van Let's Encrypt. Ik zie echter legio voor beelden dat er Let's Encrypt certificaten aangevraagd worden voor domeinnamen die een CAA record hebben waar de naam Let's Encrypt niet in voorkomt...Dus Let's Encrypt lapt de regels aan zijn laars of negeert de DNS standaard CAA.
22-12-2022, 14:22 door SecOff - Bijgewerkt: 22-12-2022, 14:29
@erik Even los van het in het artikel beschreven issue met MITM kwetsbaarheden bij een initiele aanvraag, ik begrijp niet waarom je blijft ageren tegen DV tls-cerificaat verstrekkers. Een tls-certificaat is eigenlijk niets meer dan één van de componenten die wordt gebruikt een een versleutelde verbinding tussen een browser en een webserver op te zetten. (net als een webserver,browser software, dns server etc). De DV certificaat leveranciers verkopen geen identificatiemiddel, ze verkopen een stukje code dat momenteel noodzakelijk is om een tls verbinding tussen browser en server op te kunnen zetten.

Dezelfde kritiek die je hebt op de certificaat leveranciers zou je daarom ook kunnen hebben op de domain verkopers en webhosters, die werken net zo goed mee aan het faciliteren van cyber-crime door zomaar iedereen een domeinnaam of webserver te geven zonder de naam te koppelen aan een legitieme organisatie.

De zwarte piet bij de certificaat leveranciers neerleggen is te vergelijken met het aanvallen van een drukkerij omdat ze zomaar in opdracht van een willekeurige persoon enveloppen of visitekaartjes afdrukken met een bedrijfsnaam zonder te controleren of de opdrachtgever wel gemachtigd is om te handelen namens een bedrijf met die bedrijfsnaam. Of zelf de copyshop omdat je hun systemen kunt gebruiken om vals briefpapier te printen.

Ook al zou het verschil tussen EV en DV certificaten nog te zien zijn in browsers, dan nog controleren de meeste mensen niet op wiens naam een EV certificaat is uitgegeven. De reden dat Chrome gestopt is met visueel onderscheid tussen EV en DV certtificaten is:
"Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection."

Zelfs al zou de identiteit van een organisatie goed worden gecontroleerd en weergegeven in de browser dan nog zouden er phishing sites zijn omdat gebruikers die identiteit toch niet goed controleren.

In the old days was het zo dat je voor een .nl registratie (en vergelijkbare eisen bij een aantal andere tld's) een kvk nummer moest hebben, dat maakte het in ieder geval iets omslachtiger en kostbaarder voor cyber criminelen (maar die waren er toen ook gewoon veel minder) een malafide .nl website op te zetten. Ik ben blij dat dat niet meer zo is want dat was een behoorlijke belemmering geweest voor de groei van het internet.

Het echte probleem ligt in het feit dat veel mensen waarde hechten aan tls-certificaten als bewijs dat een website onder controle staat van een organisatienaam die zich op die website presenteert terwijl bij geen enkel certificaat, ook EV niet, zo is.

Ik denk dat het probleem van welke website er wel of niet vertrouwd kan worden niet eenvoudig op te lossen is. Het komt uiteindelijk neer op een goede controle door de bezoeker en dat gaat in veel gevallen niet goed. Er zijn ook nog steeds mensen die hun bankpas en pincode afgeven aan iemand die aanbelt en zegt namens de bank te komen.

Of heb jij hier wellicht een briljant idee voor? Ik denk dat we het wel eens zijn dat daar behoefte aan is.
22-12-2022, 23:01 door Erik van Straten
Door SecOff: Een tls-certificaat is eigenlijk niets meer dan één van de componenten die wordt gebruikt een een versleutelde verbinding tussen een browser en een webserver op te zetten.
Je hebt geen certificaat nodig voor een versleutelde TLS verbinding!

Uit https://wiki.openssl.org/index.php/Diffie_Hellman#Diffie-Hellman_in_SSL.2FTLS:
There are three versions of Diffie-Hellman used in SSL/TLS.
• Anonymous Diffie-Hellman
• Fixed Diffie-Hellman
• Ephemeral Diffie-Hellman

Anonymous Diffie-Hellman uses Diffie-Hellman, but without authentication. Because the keys used in the exchange are not authenticated, the protocol is susceptible to Man-in-the-Middle attacks. Note: if you use this scheme, a call to SSL_get_peer_certificate will return NULL because you have selected an anonymous protocol. This is the only time SSL_get_peer_certificate is allowed to return NULL under normal circumstances.

You should not use Anonymous Diffie-Hellman. You can prohibit its use in your code by using "!ADH" in your call to SSL_set_cipher_list.

Fixed Diffie-Hellman embeds the server's public parameter in the certificate, and the CA then signs the certificate. That is, the certificate contains the Diffie-Hellman public-key parameters, and those parameters never change.

Ephemeral Diffie-Hellman uses temporary, public keys. Each instance or run of the protocol uses a different public key. The authenticity of the server's temporary key can be verified by checking the signature on the key. Because the public keys are temporary, a compromise of the server's long term signing key does not jeopardize the privacy of past sessions. This is known as Perfect Forward Secrecy (PFS).

You should always use Ephemeral Diffie-Hellman because it provides PFS. You can specify ephemeral methods by providing "kEECDH:kEDH" in your call to SSL_set_cipher_list.

Bij de gebruikelijke Ephemeral Diffie-Hellman worden de de DH-parameters door de server ondertekend met diens private key. De client, die als het goed is dezelfde parameters gebruikt, checkt die digitale handtekening aan de hand van de public key in het servercertificaat en vergelijkt de parameters. Als daar een verschil tussen bestaat, is er sprake van een AitM.

Bij Anonymous Diffie-Hellman heb je geen https servercertificaat nodig.

Het eerste probleem
Anonymous Diffie-Hellman (geen certificaat) is prima als er geen AitM (Attacker in the Middle) tussen jouw browser en de server zit en DNS betrouwbaar is (de DNS-records niet gehacked zijn en de communicatie tussen de DNS-server en jouw browser niet gemanipuleerd wordt).

Bij een DV-certificaat vertrouw je erop dat, tijdens certificaat-uitgifte, er geen AitM tussen de certificaat-provider en de server zat en dat DNS betrouwbaar was (de DNS-records niet gehacked waren en de communicatie tussen de DNS-server en de certificaat-provider niet gemanipuleerd werd).

Een DV-certificaat is dus nauwelijks een verbetering t.o.v. geen certificaat, en dit gaat in de praktijk ook daadwerkelijk fout. Voorbeelden (waarbij Let's Encrypt certificaten voor specifieke domeinnamen aan cybercriminelen voor heel andere servers werden verstrekt):

• BGP-hijack: https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/. Nb. zo'n aanval is steeds moeilijker naarmate het langer duurt voordat de cybercrimineel z'n (onterecht afgegeven) certificaat verkrijgt. "Dankzij" het bloedsnelle Let's Encrypt is dit geen probleem voor de aanvallers.

• Primary DNS-records hacked: https://www.mandiant.com/resources/blog/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.

• Subdomain takeover attacks: https://0xpatrik.com/subdomain-takeover-impact/

• Bij de voorbeelden van "Domain Shadowing attacks (https://unit42.paloaltonetworks.com/domain-shadowing/) kon ik geen Let's Encrypt of andere DV certs vinden, maar het zou mij verbazen als die niet gebruikt worden bij dit soort aanvallen.

Probleem twee
De meeste phishing-sites gebruiken DV-certificaten. Je krijgt ze onmiddellijk, niemand checkt of de domeinnaam duidelijk bedoeld is voor phishing, ze zijn gratis (geen money-trail) en het is "no questions asked"; er komt geen organisatienaam in het certificaat waarvan je moet bewijzen dat jij namens die organisatie geautoriseerd bent om dat certificaat aan te vragen. Perfect voor cybercriminelen.

Probleem drie
Gebruikers kunnen onmogelijk weten of een domeinnaam in de adresbalk van hun browser van de organisatie is die de pagina zegt te zijn (de link genoemd in https://www.virustotal.com/gui/url/bdf3e928b4ad185b713d25a58348fa79d3a7aaa596c244c03f1783bd4bc6a3d5/details is nog steeds live, en suggereert een OneDrive pagina te zijn).

Doordat webbrowsers geen onderscheid meer laten zien tussen de verschillende soorten certificaten, weten gebruikers van geen enkele site (ook niet van digid.nl, hun bank of cryptovalutaboer) hoe zeker het is dat je echt verbinding hebt met de in de adresbalk vermelde domeinnaam (zie probleem 1: het kan om een nepsite gaan). Bovendien kun je in steeds minder browsers certificaten bekijken en last but not least gebruiken steeds meer sites, waarbij de authenticiteit cruciaal is, ook DV-certificaten.

Tegelijkertijd wil de EU dat wij ons paspoorten digitaliseren op onze smartphones zodat wij ons wel "betrouwbaar" kunnen authenticeren - op websites waarvan we geen idee hebben van wie zij zijn.

Door SecOff: Dezelfde kritiek die je hebt op de certificaat leveranciers zou je daarom ook kunnen hebben op de domain verkopers en webhosters, die werken net zo goed mee aan het faciliteren van cyber-crime door zomaar iedereen een domeinnaam of webserver te geven zonder de naam te koppelen aan een legitieme organisatie.
Webhosters hoeven niet te weten welke fout-klinkende domeinnamen naar hun servers wijzen en ook horen zij, vanwege privacy, niet op de servers van hun klanten rond te neuzen.

Het kan mij persoonlijk niet schelen of DNS-boeren danwel certificaatverstrekkers controleren, maar zoals je zelf zegt deden certificaatverstrekkers dat van oudsher. Zij vervulden, en bij OV/EV certificaten vervullen zij nog steeds, een soort notarisrol die de aanvrager authenticeert. Ook zitten zij, via het CAB-forum, met de browserboeren aan tafel. En als een certificaatboer zich misdraagt (onterecht certificaten uitgeeft aan criminelen), kunnen de rootcerts uit browsers worden geschrapt.

Door SecOff: Ook al zou het verschil tussen EV en DV certificaten nog te zien zijn in browsers, dan nog controleren de meeste mensen niet op wiens naam een EV certificaat is uitgegeven. De reden dat Chrome gestopt is met visueel onderscheid tussen EV en DV certtificaten is:
"Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection."

Zelfs al zou de identiteit van een organisatie goed worden gecontroleerd en weergegeven in de browser dan nog zouden er phishing sites zijn omdat gebruikers die identiteit toch niet goed controleren.
Verstandige gebruikers letten daar wel op. En die verstandige gebruikers bestaan (ik ben er één van). Belangrijker is dat ik nu niet meer fatsoenlijk aan iedereen, die het wil horen, kan uitleggen waar ze op moeten letten, want het verschil tussen nep en echt is flinterdun geworden sinds browsers EV-gegevens niet meer tonen.

Door SecOff: Het echte probleem ligt in het feit dat veel mensen waarde hechten aan tls-certificaten als bewijs dat een website onder controle staat van een organisatienaam die zich op die website presenteert terwijl bij geen enkel certificaat, ook EV niet, zo is.
Kul. Het is niet 100% onmogelijk maar wel extreem veel moeilijker voor cybercriminelen om een EV-cert voor een gegeven domeinnaam te kopen, dan een DV-cert te verkrijgen.

Door SecOff: Ik denk dat het probleem van welke website er wel of niet vertrouwd kan worden niet eenvoudig op te lossen is.
Als je weet dat een partij Sywert van Lienden of "WC Eend" heet, wil dat niet zeggen dat die partij betrouwbaar is. Maar dat probleem bestaat al sinds mensenheugenis. Wel is het zo dat als je de naam van een partij kent en zeker weet dat je met die partij (en niet met een identiteitsfraudeur) te maken hebt, je bijv. naar reputatie kunt kijken. De risico's tussen "face to face" zakendoen met een partij zijn dan vergelijkbaar met zakendoen via een website met een geauthenticeerde partij.

Door SecOff: Het komt uiteindelijk neer op een goede controle door de bezoeker en dat gaat in veel gevallen niet goed. Er zijn ook nog steeds mensen die hun bankpas en pincode afgeven aan iemand die aanbelt en zegt namens de bank te komen.
We kunnen het aantal internet-fraude-slachtoffers, net als het aantal verkeersdoden, waarschijnlijk nooit op nul krijgen - maar wel lager. En bij een kleiner aantal slachtoffers zijn vangnetten (zoals grotendeels vergoeden van de schade via een fonds of evt. verzekeringen met betaalbare premies) wellicht ook acceptabeler.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.