Op crt.sh kun je controleren of anderen op jouw domein certificaten hebben aangevraagd.

Ik vind dit toch eerder een geval van "ip-adres komt uit bij host"-schijnveiligheid. Dat LetsEncrypt daar last van heeft bij de validatie van certificaten is zonder meer waar, maar t.b.v. het afluisteren zelf is de omleiding ook nog nodig.
Als dit een omleidings-actie van overheidswege is dan gaan andere middelen ook niet 123 toereikend zijn.
Om dan middels de kop van dit (zeer interessante) artikel zo sterk de blaam te leggen bij LetsEncrypt is een minnetje in mijn beleving.

Longread , dank je Erik. Ga ik straks lezen

Ik ga er al jaren van uit dat de keys van deze Gratis service gewoon ook bij de NSA liggen. Die mogen me best monitoren (maar niet gaslighten of mijn data verder delen voor bepaalde negatieve doeleinden...)

Welke CA kun je wel vertrouwen?

Ik denk dat alleen self-signed veilig is. Alleen heb je dan een waarschuwing op je site , dus het oogt niet veilig.

Op zich kan het geen kwaad om nog eens duidelijk voor het voetlicht te brengen dat LetsEncrypt de al behoorlijk verslechterde veiligheid van het certificaten systeem totaal ten gronde gericht heeft...
Het oorspronkelijke idee van de certificaten was dat er deugdelijk gecontroleerd zou worden of een certificaat wel aan de goede partij werd uitgereikt. Dat was al kapot met DV certificaten, maar toen iedere handmatige controle ook nog kwam te vervallen door het ACME protocol was er niets meer over.

Nee, het is geen schijnveiligheid.

Het is HTTP (iedereen luistert mee tussen jouw browser en de site) en HTTPS (alles is versleuteld tussen jouw browser en de site).

Natuurlijk zijn er legio andere aanvallen mogelijk, maar HTTPS lost dit onderdeel wel echt op.

EV-certificaten zijn natuurlijk beter: maar de afgelopen jaren hebben browserfabrikanten die eigenlijk nutteloos gemaakt. En ook daar bestonden wel aanvallen op.

Het web is niet perfect, verre van, komt omdat het uit een tijd kwam toen mensen elkaar vertrouwden (en dus systemen ook): waarom zou je immers iets versleutelen als niemand meeluistert. Tijd voor een nieuw web dat van de grond af aan is opgebouwd met ook zero-trust in gedachten.

het hele probleem zit meer in het demoniseren van niet 'https' verbindingen, daar heb ik moeite mee... het is echt voor geen scriptkiddie interesant om op mijn privénetwerk een mann in the middle attack uit te voeren tussen mijn laptop en ups... maar chrome, firefox, opera, arc en brave schrreuwen moord en brand wannneer ik in een beveiligde omgeving naar mijn ups ga zonder goedgekeurd certificaat door de mafia/kartel... en daar is echt alles fout mee.

TLS zegt eigenlijk alleen maar iets over de versleuteling van het verkeer tussen host A en host B.
Het is het minimum dat je moet hebben.

Host A verbind met host B en als het mechanisme op host A het certificaat van host B OV vind zal er veilig data over de lijn verzonden worden.

Het zegt verder helemaal niets over host A of host B.

Eveneens op [7] is een tegenmaatregel te lezen die door LetsEncrypt ondersteund wordt, in deze reactie:
https://www.heise.de/forum/heise-online/Kommentare/Lauschangriff-auf-russischen-Jabber-Server-in-Deutschland-Wer-steckt-dahinter/CAA-als-Gegenmassnahme/posting-43271984/show/
De maatregel bestaat uit een goed CAA-record in de DNS, met: insbesondere das "accounturi" flag.

Nee. https maakt beveiligde communicatie mogelijk tussen jouw browser en een ander systeem, maar of dat andere systeem wel "de site" is dat weet je pas zeker als je zeker weet dat alleen "de site" beschikt over een certificaat dat claimt van de site te zijn. En dat weet je niet zeker bij LetsEncrypt (en andere DV) certificaten.

Dat klopt niet. Jouw eigen systeem genereert de key en slaat die lokaal op, en bij het aanvraagproces van het certificaat wordt jouw key niet naar de certificaat autoriteit gestuurd.

Wat wel fout is dat zijn certificaatuitgevers waar je een certificaat koopt en dan een zip opgestuurd krijgt waarin zich zowel de key als het certificaat bevinden. Dan heeft de uitgever en wellicht de halve wereld ook de key.

In juli 2011 stond de (security) wereld op z'n kop nadat DigiNotar valse certificaten voor o.a. *.google.com had uitgegeven (doordat een aanvaller toegang kreeg tot hun interne netwerk).

Sinds DV-certificaten worden uitgegeven "moeten we er maar mee leven" dat pruts-CA's onterecht certificaten voor jouw domeinnaam/namen kunnen uitgeven, ook als je zelf veel betrouwbaarder certificaten gebruikt ("probleempje": browsers tonen geen verschil).

Als "fix" stel je voor dat domeineigenaren maar op crt.sh moeten gaan bijhouden of een pruts-CA onterecht een certificaat voor hun domein heeft uitgegeven. En wat dan: laten intrekken? Hoe snel gaat dat? En welke browsers checken nog op revocation? Of moet je er genoegen mee nemen dat Let's Encrypt certificaten "maar 3 maanden" geldig zijn? (Veel andere DV-certs 1 jaar of iets langer, zoals van Sectigo en Amazon).

Nog even los van het feit dat crt.sh soms slecht bereikbaar is, soms vertraagd of geheel niet logt en CT niet verplicht is voor certificaatuitgevers.

Dit is de wereld op z'n kop.

DigiNotar kon haar deuren sluiten (terecht) maar welke straf staat er tegenwoordig op het onterecht uitgeven van een https servercertificaat?

Aanvallers zijn niet beperkt tot "statelijke actoren"; met gehackte netwerkapparatuur bij hostingpartijen (denk bijv. aan de recente Cisco kwetsbaarheden) zijn AitM-attacks door cybercriminelen denkbaar (naast BGP-hijacks en DNS-gerelateerde "omleidings"-aanvallen naar een server die aan de andere kant van de wereld kan staan).

Uit hoofdstuk 1 "Introduction" in RFC 8446 "The Transport Layer Security (TLS) Protocol Version 1.3", direct na eisen t.a.v. Authentication, Confidentiality en Integrity:
Met DV-certificaten kun je niet voldoen aan die eis.

Dankzij het feit dat elke serverbeheerder eenvoudig, snel en gratis een DV-certificaat kan verkrijgen, de server correct geconfigureerd kan worden en het certificaat bijtijds automatisch wordt "verlengd" (vervangen door een nieuw exemplaar), is https de norm geworden.

Maar tegen welke prijs? Is "https i.p.v. http" het doel, of het oplossen van de problemen die bestonden bij http - zoals beschreven door o.a. de EFF?

Dank mijnheer van Straten voor uw uitleg.
Voor mij steeds duidelijker.
Noob

He, dank je wel voor de tip!

Wie nog meer goede security tips heeft, laat het dan de community even weten. Alvast bedankt!

Helaas kun je daar alleen zien wanneer er certificaten zijn aangevraagd (en bij welke uitgever), maar niet door wie.
Dat zou er eigenlijk aan die CT moeten worden toegevoegd...

Door de wijze waarop de publieke certificaat-PKI werkt en door wat browsers wel/niet tonen, zullen we (internetters) elke CA moeten vertrouwen, maar dat vertrouwen (ook in browsermakers) is misplaatst.

Een goed beeld geeft ook een netcraft site report scan.

Ik stel me altijd even van te voren op de hoogte,
als ik een website voor de eerste keer ga bezoeken.

En dan nog.

Het diginotar debacle werd nooit goed opgepakt.

Even domein scannen: https://mxtoolbox.com/CERT.aspx

Ik denk dat je je eigen vraag wel kunt beantwoorden.
Nee, het is geen ultiem middel, maar "beter" danwel "minder slecht" dan zonder.

Volgens mij is het cert ingetrokken NADAT de Staat der Nederlanden z'n naam eraan verbond.
Dat komt volgens diverse ongewenste insiders door riekende zaakjes waar DigiNotar zich perfect voor leende.

Anyway, ook Frankrijk heeft zichzelf certificaten voor gmail.com verleend, meer dan DV.
In reactie daarop zijn ook nieuwe beschermingsmethoden gemaakt.

Dus jouw "werd nooit goed opgepakt", maakt mij nieuwsgierig.

Volledig mee eens.
Daarnaast is het voor veel websites helemaal niet interessant of je via http of https verbindt.
Pas als je iets gaat invoeren wordt het interessant (bijvoorbeeld bank, belastingdienst, webshop, enz). Voor iets als bijvoorbeeld wikipedia boeit het geen ene moer of die verbinding versleuteld is. Ok, toegegeven, "ze" kunnen meekijken. Nou en? Veel plezier met dat je weet dat ik op wikipedia iets lees. Hadden "ze" anders ook kunnen achterhalen aan de hand van meta-data.

Dat betekend dus dat niet Letsencrypt maar de DNS het probleem is, een cruciale service die nagenoeg en vrijwel niet beveiligd wordt.
Ook al is daar DNSSec voor beschikbaar en dat is er al jaren.
Overigens, als je een vertrouwde certificate authority compromitteert, kun je precies hetzelfde. Kijk maar terug naar het Diginotar schandaal uit 2011 en hoe die certificaten door de Iraanse overheid zijn misbruikt om precies hetzelfde te doen. Helaas niet de enigste CA die problemen als zodanig hebben gehad over de laatste 10-15 jaar overigens.
Dat Letsencrypt makkelijker is te ge(mis)bruiken hiervoor is zeker zo, vooral omdat de domain validation over http gaat en niet https (dus is te intercepten), maar je hebt ne blijft ook nog de DNS spoofing nodig hebben om zowel het certificaat te krijgen als de uiteindelijke MiTN aanval uit te voeren.

Vanaf ongeveer 2013 (wellicht eerder) waren er op verschillende plaatsen in de wereld ISPs die waren begonnen advertenties in HTTP-verkeer te injecteren. Kennelijk werd dat al eerder toegepast in publieke Wifi-hotspots. Dit gaat niet alleen over scriptkiddies, het gaat ook over ondernemingen die doodleuk aan websites die helemaal niet van hun zelf zijn advertenties toevoegen.

Voor de minder technische medemens bestaat ook https://veiliginternetten.nl/campagnes/scamcheck/

Dat waren voornamelijk ISPs uit Azië hier hebben we dat soort geintjes niet gehad. Wel hadden we dat op open WIFI netwerken van vervoerders restaurant ketens etc maar dat is hun goed recht die draaiden de content dan in een proxy zoals bijv met Squid vanaf hun eigen netwerk. Ze voegden echter geen advertenties toe aan website ze draaiden deze simpelweg erbovenop het verkeer bleef gescheiden. De ISP's echter waren wel echt in de fout.


Op de discussie over schijnveiligheid.
Laten we wel wezen het internet is niet veilig het internet zal nooit veilig zijn. Het is simpelweg niet gemaakt voor wat we nu ermee doen en we plakken elke keer maar weer een plakbandje ergens op in de vorm van nog een protocol.

Niemand zou het internet zoals het nu is hebben geimplementeerd met de kennis die we nu bezitten en de enige weg die we hebben tot een veel veiligere situatie is een complete vervanging. Maar dat gaat niet zomaar gebeuren we hebben het internet zo een kritiek onderdeel gemaakt van onze wereldwijde infrastructuur dat het niet rendabel genoeg is om dat ooit te doen en de stabiliteit is zo slecht dat we grootste deel van onze tijd bezig zijn het kaartenhuis in de lucht te houden in plaatst te innoveren. En het is maar de vraag *als* er al een opvolger komt of we echt beter af zijn of simpelweg andere gatenkaas creeeren omdat we te veel eisen van een technologie.

We zitten in een zeer interessante voor beveiligingbegrip tijdperk namelijk op het punt dat Generative AI malware dominant zal gaan worden en dat kaartenhuis wat we het internet noemen zal steeds vaker instorten en eruit liggen omdat we simpelweg niet snelgenoeg het weer op kunnen zetten. Certificaat issues is echt een van onze minste zorgen momenteel.

Bij de laatste aanval, en die van vorig jaar [6], was er geen sprake van DNS spoofing.

Uit https://datatracker.ietf.org/doc/html/rfc8446:
Er is geen eis t.a.v. DNS of BGP of zelfs IP: TLS kan ook werken via een RS232 lijntje of papieren post (bij dat laatste "protocol': mits er volgnummers in worden opgenomen waarmee een in-order data stream kan worden gegarandeerd).

Uit dezelfde RFC, m.b.t. authenticiteit van in elk geval de server, de vertrouwelijkheid en integriteit van de uitgewisselde informatie, ik herhaal:
DV-certificaten voldoen hier niet aan omdat een aanvaller met (actieve) toegang tot de netwerkverbinding (al dan niet omgeleid via een BGP- of DNS-aanval) tussen de certificaatuitgever en de server, op elk gewenst moment een certificaat op naam van de server kan aanvragen en verkrijgen.

Alle browsers die via het netwerk als eerste de nepserver tegenkomen, kunnen dan worden misleid. Bij een BGP-hijack geldt dat voor alle bezoekers (inclusief certificaatverstrekkers).

De aanval op jabber.ru/xmpp.ru zou je een "last mile attack" kunnen noemen: de aanval vindt dan fysiek zó dicht bij de server plaats dat ál het netwerkverkeer (zowel van certificaatverstrekkers als van bezoekers) naar/van die server wordt onderschept.

"Halfway" aanvallen zijn echter ook denkbaar. Stel dat een overheid binnen AMS-IX een AitM-aanval uitvoert op alle verbindingen met security.nl. Als vanaf dat tappunt bij een buitenlandse DV-certificaatuitgever een certificaat voor (bijvoorbeeld) security.nl wordt aangevraagd, zit het er dik in dat het netwerkverkeer via (of tot en met) dat tappunt plaatsvindt. Dus kan dat tappunt een DV-certificaat voor security.nl verkrijgen. Elke internetter wiens netwerkverkeer via AMS-IX naar de echte security.nl wordt gerouteerd, kan dan worden ge-AitM-ed (zonder DNS- of BGP-aanval).

De kern van het probleem met DV-certs is dat een aanvaller niet hoeft te bewijzen beheertoegang tot een specifieke server te hebben; toegang tot een server "ergens tussen" de DV-certificaatuitgever en die specifieke server volstaat. Waarbij "tussen" kwetsbaar is voor meerdere factoren: fysieke toegang tot de gebruikelijke verbinding of het omleiden daarvan (via DNS- of BGP-aanvallen). Mogelijkheden te over voor statelijke actoren, maar ook voor cybercriminelen met ongeautoriseerde toegang tot de infrastructuur van hostingpartijen, DNS-registrars en/of netwerkproviders.

Ook mensen die zich enigszins bewust zijn van dit risico kunnen in veel browsers geen verschil meer zien tussen DV- en op betrouwbaarder wijze uitgegeven certificaten. Dus hebben DV-certs en browsermakers de betrouwbaarheid van de authenticiteit van servers, waarbij dat van groot (zelfs levens-) belang is, ernstig verzwakt. Dit naast het gemak waarmee phishers DV-certificaten kunnen verkrijgen voor domeinnamen die van een organisatie zouden kunnen zijn.

In dit op drijfzand gebaseerde internet "mogen" burgers straks met hun EDIW (European Digital Identity Wallet) gaan authenticeren op servers van je-hebt-geen-idee-wie (https://security.nl/posting/816027). Dat gaat vast goed aflopen (not).

Ik denk dat het grootste probleem is het niet toepassen van 'best policies '.
Of uit kosten overwegingen of uit een tekort aan besef, maar toch.
DNSSec, header security etc.etc. laten liggen.

De kosten om het niet te implementeren zijn op den duur veel omvangrijker.

Maar ja als het kalf verdronken is etc. is vaak de houding van beleidvoeders.
Je verandert de natuur van de mens niet zo gauw.
Eerst beleven, dan pas geloven tot aan het volgende incident.
We zijn een raar soort wezens.

Eh, ja. Het gaat in die tekst specifiek over content injection aanvallen in HTTP. Die kunnen worden gestopt met HTTPS. Voor de meelezers: omdat HTTP in platte tekst over de lijn gaat kan iemand die er tussen zit daar iets aan toevoegen of aanpassen.


Dit is een voorbeeld van een 'IDN homograph attack'. Dat is geen content injection aanval. Overigens gebruiken phishers al sinds jaar en dag vooral gehackte sites die niet eens lijken op de site die ze willen imiteren. Het gaat kennelijk vooral om de overtuigende tekst. Weinig phishers nemen de moeite een domein te registreren.

Als je de hele post had gelezen, had je gezien dat niet "All of these attacks can be stopped by HTTPS".

Reageer eens inhoudelijk op mijn argumenten, zoals ook in https://security.nl/posting/816576.

Ik claim nergens dat een 'IDN homograph attack' een 'content injection aanval' is.

Onzin; dat gebeurt aan de lopende band. Kijk bijvoorbeeld af en toe naar https://github.com/mitchellkrogza/Phishing.Database/blob/master/phishing-domains-NEW-today.txt.

Uit de versie van zojuist: mygym.nl lijkt inderdaad gehackt, maar kijk bijvoorbeeld eens naar https://crt.sh/?q=ebonking-ch1-ubs.com. Als ik het bovenste certificaat bekijk, zie ik dat Let's Encrypt afgelopen week 7 certificaten heeft uitgegeven voor de dat domein, met de volgende SAN's (een aantal domeinnamen wisselt per certificaat):
Tig domeinnamen (inclusief IDN's); de phishing spat er vanaf.

Of lees https://blogs.infoblox.com/cyber-threat-intelligence/prolific-puma-shadowy-link-shortening-service-enables-cybercrime/ van vandaag en hun IOC-file (1.6MB) op github (bron: https://krebsonsecurity.com/2023/10/us-harbors-prolific-malicious-link-shortening-service/).

Phishers zien domeinnamen als wegwerpartikelen omdat ze op blocklists verschijnen. Nieuwe domeinnamen registreren (of oude die ondertussen van de ellenlange blocklists zijn geschrapt) kost bijna niets en kan anoniem (je kunt eenvoudig liegen over je identiteit, zoals de laatste twee artikelen laten zien). Een DV-cert verkrijgen vormt vervolgens geen enkele hindernis en kan volstrekt anoniem.

Niemand neemt de verantwoordelijkheid om het gigantische probleem van phishing aan te pakken; ook DNS-registrars niet. TLS servercertificaten zijn echter bedoeld om de identiteit van een server aan te tonen: is een server van een geclaimde organisatie.

Doordat in elk DV-certificaat, behalve een domeinnaam (potentieel "lijkt op" of "zou kunnen zijn van"), alle gebruikelijke identifiers van de organisatie ontbreken (en dus ook niet op juistheid worden gecheckt), zitten we nu met deze puinhoop. En met malloten die suggereren dat bijvoorbeeld DNSSEC alle problemen op zou kunnen lossen.

Ik heb wel de originele tekst gelezen, maar jij hebt het niet begrepen dat met "all these attacks" niet wordt bedoeld phishingaaanvallen maar een specifiek soort aanvallen, namelijk contentinjectie. Dat staat er duidelijk, maar jij probeert het kennelijk (nu willens en wetens) te vervormen tot iets wat er niet staat.

Dus lees voortaan beter voordat je het werk van anderen afkraakt op onjuiste gronden en gebruik geen oneigenlijke argumenten.

Het bestaan van een bepaald typosquat of IDN homograph is niet een bewijs van een aanval. Er kunnen allerlei redenen zijn voor het (voort-)bestaan van dergelijke domeinen. Met een statement als "de phishing spat er vanaf" kom je er niet. Veel domeinen worden al gestopt, onklaar gemaakt of overgenomen voordat ze uberhaupt (kunnen) worden gebruikt. Afgezien daarvan, de werkelijkheid is dat phishers veel vaker gehackte domeinen gebruiken en dat het aantal homograph aanvallen in verhouding zeer laag is.

Als je je eigen gepresenteerde bron had gelezen had je ook gezien dat de niet nader benoemde domeinen niet waren gevonden omdat ze in phishing zijn gebruikt, maar via DNS.
Het gaat hier overigens over fake link shorteners. Shorteners worden vaak gebruikt in gewone spam. Blocklists listen shorteners vaak niet omdat ze false positives kunnen veroorzaken, maar dat gaat niet op voor fake link shorteners, die kunnen wel worden geblacklist. De spammers hopen dat niet wordt ontdekt dat de redirectors kwaadaardig zijn.

Anders dan "normale" spammers rekenen phishers op een zeer korte levensduur met misschien effectief een gering aantal slachtoffers voordat een domein wordt neergehaald.

Het verhaal van Infloblox is niets nieuws of bijzonders. Ze proberen aandacht te trekken om klanten te werven.

Je mist mijn punt volledig.

EFF heeft samen met andere organisaties Let's Encrypt gelanceerd om problemen "including account hijacking and identity theft [3]; surveillance and tracking by governments [4]" aan te pakken.

Bijna 10 jaar later zijn die problemen alleen maar groter geworden - los van of het daarbij om "content injection" of om anderssoortige aanvallen gaat. De laatste aanval (op jabber.ru/xmpp.ru) is één van de soorten aanvallen die de EFF noemde ("surveillance and tracking by governments") welke Let's Encrypt zou moeten helpen voorkómen - maar nu bewezen niet doet.

Ik herhaal uit een andere bijdrage:

De big fail van https, browsers en certificaatuitgevers is dat de meeste internetters niet (kunnen) zien of zij met een echte of met een nepserver (al dan niet een AitM) te maken hebben, en zo worden gephisht of afgeluisterd. Let's Encrypt heeft niet bijgedragen aan een oplossing voor dit probleem, integendeel. Dat is wat ik duidelijk probeer te maken.

Mooi voorbeeld van dergelijke schijnveiligheid:
https://superuser.com/questions/1714889/a-unrecognized-domain-vultrusercontent-com-resolving-to-my-localhost

@Erik van Straten Anders dan je denkt miste ik niet het punt wat je probeerde te maken, ik wees je op de fout in je beargumentering.

Je maakt van een mug een olifant. Er zijn weinig phishing domeinen en certifcaten daarvoor veroorzaken niet noodzakelijk een probleem.

Wat betreft typosquatting en homographs: daar kun je over klagen bij de uitgever van de certificaten. Maar eigenlijk moet je een niveau lager zijn, bij de uitgever (registry/registrar) van de domeinen. Goed beheerde domeinen luisteren naar abuseklachten en hebben zelf opsporingsmechanismen.

Het blijft niet noemenswaardig probleem. Banken huren bedrijven in die de domeinen monitoren (mark / brand protection). Die schakelen zo snel dat je weinig kans maakt met een partij phishing domeinen.

Er worden overal security claims gemaakt die inhoudelijk van weinig waarde zijn, ik zou niet op alle slakken zout gaan leggen.

Met de nieuwe zogeheten "privacy-borging" door de EU komt "betaal-uw-scheel" internetten in zicht.
4,95 euro per maand voor het openen van een PDF bestandje op je smartphone.
Betalen voor ad-vrij Facebook, ook al a 13,95 euro per maand.

Wat gaat je digi-toegang van de EU je straks kosten.
Zullen gratis certificaten ook verdwijnen. Ook alles wat vroeger "free as free in beer" was?

Wat houdt dat in werkelijkheid in, het WEF-motto: "U zult niets bezitten en toch gelukkig zijn"?
Krijgen we een digi-dictatuur?

#webproxy

@Redactie: hou maar op met deze site.

Het niet meer vertrouwen van de CA, zoals bij Symantec gebeurde: https://support.apple.com/en-us/HT208860

Dus jij denkt dat makers van browsers en besturingssystemen het vertrouwen in Let's Encrypt gaan opzeggen?

Ik niet, om twee redenen:
1) Let's Encrypt is "too big to fail";
2) Het is geen "fout" van Let's Encrypt, maar een fundamentele zwakte van DV.

Als we dit accepteren, gaan we ermee akkoord dat elke https- (of andere TLS-) verbinding minder betrouwbaar is als gevolg van het toestaan van DV-certificaten. Ook blijven we ermee akkoord gaan dat software (met name browsers) geen betrouwbaarheidsniveau van de identiteit van de https- (of andere TLS-) server tonen.

Met als gevolg de negatieve spiraal van steeds meer DV-certificaten in plaats van certificaten waarbij de identiteit en autorisatie van de aanvrager op fatsoenlijke wijze zijn geverifieerd. Niet voor niets kent bijv. DigiD ook meerdere betrouwbaarheidsniveaus (van authenticiteit, dus hoe betrouwbaar de identiteit van een entiteit is geverifieerd).

Veel te veel mensen denken: "het doel is https want dan is het veilig". Dat is onzin: het doel is een veilige verbinding met een server van de juiste partij. Sinds we forward secrecy gebruiken, is het het enige doel van TLS-certificaten het aantonen dat je met een server van de juiste partij communiceert, en juist die garantie heb je nauwelijks tot niet bij DV-certs.

In Nederland niet, nee, maar Comcast in de VS wel, en als mijn geheugen me geen parten speelt ging de eerste keer dat ik erover las over een grote Britse ISP die het deed.

Je zou denken "maak de kleur van het slotje (en of het precieze symbool) afhankelijk van het betrouwbaarheidsnivo van het certificaat.
Dat is zo'n goed idee dat het al eens gedaan is. Maar toen kwamen de clueless nitwits die hun gebrek aan inzicht zo nodig willen botvieren op wat de gebruikers in hun browserbalk te zien krijgen...

Neen, wat Comcast deed (en anderen) was in DNS als je een niet bestaand domein opvroeg een adres retourneren van een reclame site. Dat is heel wat anders dan het aanpassen van de inhoud van een wel bestaande site.

Ja want de amazon cloud zal dat dan rapporteren. Wat een pruts reactie. Dat is net als dat de politie een crimineel gaat bellen, "hallo sinds vandaag luisteren we je telefoonlijn af".

Wat maakt die key uit, de amazon cloud kan elk certificate gewoon dupliceren.

Advertenties voor zichzelf bij publieke WiFi-hotspots:
https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
Meldingen aan klanten door ze in bezochte websites te injecteren:
https://www.techdirt.com/2016/11/29/comcast-takes-heat-injecting-messages-into-internet-traffic/
Ze hebben zelfs een RFC ingediend voor dat laatste:
https://datatracker.ietf.org/doc/html/rfc6108

Alleen als je het eerst aan hen geeft. Als je je key geheim houdt heeft zelf de amazon cloud die niet.
Wat de cloud wel veroorzaakt heeft is dat steeds minder mensen begrijpen hoe de dingen precies werken, en gebruik zijn gaan maken (en zijn gaan geloven) in een soort tover omgeving waarin alles vanzelf lijkt te gaan en niet meer onder controle is.
Maar als je daar met je eingen server niet in wilt zitten dan hoeft dat ook niet.

Ik kan het niet controleren, maar https://www.security.nl/posting/407334/Vodafone+Nederland+gebruikt+ook+Perma+Cookie+killing+users+privacy lijkt anders te suggereren (vergelijkbaar met https://www.eff.org/deeplinks/2014/11/verizon-x-uidh).

Voor ISP's is user-tracking wellicht wat lastiger geworden (vooral bij die enkeling die een VPN gebruikt - die mag hopen dat de VPN-provider niet trackt), maar ook met https worden we suf-getracked (o.a. door Google).

Internet-breed tracken en monitoren.

Als Google, Meta, Amazon, jouw (meta-)data trackt, dan kunnen we weten,
dat die tracking data ook bij de NSA en de EU monitoring agentuur zullen belanden,.

Het is al een bestaand systeem van totale controle en surveillance, letterlijk alles weten ze al van je.
Meer als je schoonmoeder ooit te weten zou komen of kon vermoeden.

Of je in een koepelgevangenis zit en je niet weet of de bewakers je vanuit het centrum observeren of niet.
Je past je gedrag automatisch aan. Alleen de wezenloze reageert niet of nooit op het panopticum gebeuren.

Willen we dat? Neen, natuurlijk. Maar wat kunnen we eraan doen, nu we het hebben laten optuigen?
Er zal geen haan naar kraaien. Die het optuigen gaan onverdroten verder.
Ze worden er toch nooit op afgerekend. Ze houden elkaar voortdurend de handen boven het hoofd.

Laten we dit monster niet verder voeden of kijken we bewust een andere kant op.

Maar toch, de meesten zien het niet en willen het niet eens weten.
Als ze er aan denken, slaat er iets dicht bij hen.
Neen, even niet aan denken maar, te confronterend.

Als je iemand erop wijst, krijg je steevast een kribbige reactie van "daar heb ie hem of haar weer".
Nou ja, zo is het.

luntrus

Je 'vergeet'/(toeval?) Microsoft met hun 'worst of all' in het besturingssysteem ingebakken tracking.

@ Xavier Ogóle,

Bedankt voor de precisering.
Alle proprietaire software doet er aan mee.
All on the same bandwagon.

Security is altijd een tradeoff.
SSL is beter dan geen SSL en er zijn ook genoeg incidenten geweest bij CA's. Ook dat is niet heilig.

Dat je phishing domeinen kunt voorzien van een certificaat via LE is geen argument. Ook bij een reguliere
gebakkenluchtverkoper kan dat, en ja ook met minimale eisen omtrent identificatie.

Dat we aapjes getrained hebben om naar een slotje te kijken zegt meer over het trainen van de aapjes dan dat dit een inherent probleem is met LE.

Werkt Erik bij Comodo? :P

Er zijn genoeg incidenten geweest met crypto libraries als OpenSSL.

Als je een domein wilt vergeten en niet meer updaten, dan kan je de OpenSSL eraf halen en de kans dat je oude domein gehackt wordt zo ongeveer halveren. Wat de oude site ongeveer twee keer zo veilig maakt.

Minder regels code is minder kwetsbaarheden.

Wat doet men met het misbruik op zgh. 'geparkeerde' domeinen?

Het is vaak een groot probleem qua scam, spam etc.

Daar heb je weer zo'n "je werkt er zeker zelf" opmerking. Ik denk dat je jezelf daar wel heel erg mee verlaagt.

Er zijn intussen een boel 'gerenomeerde' CA's die een certificaat aanvraag vooral middels DV valideren (als jou bedrijf daar een contract voor heeft).

Daarnaast kan je in je DNS nog limiteren welke CA voor jou domein een certificaat mag uitgeven, iets met CAA records in je DNS. Dat helpt, maar natuurlijk niet waterdicht als je attacker een 'trusted rouge CA' gebruikt of heel je internet connectie controleerd zodat die je DNS kan spoofen voor de CA.

Maar goed DV, is een beveiliging, maar kan omzeild worden. Maar dat kan bij een niet DV CA ook best via social engineering of insiders gebeuren. Eigenlijk moet je altijd checken of niet iemand anders een certificaat heeft geregeld voor jouw website en dan dus het verkeer kan onderscheppen en wijzigen. De certificate transparency lijsten zijn dan een begin, als een certificaat daar niet voorkomt, is er iets mis. Of als uitgegeven door de verkeerde CA, of, of...

Naja, ik hoef jou niet te vertellen dat het systeem eigenlijk een beetje stuk is, maar zolang we niets beters hebben...

Natuurlijk ook dat het 'slotje' alleen betekent dat de verbinding naar de webserver encrypyed is, niet dat die webserver te vertrouwen is (iets dat vroeger veel werd genoemd, maar feitelijk niet klopt, want iedereen kon altijd al een certificaat regelen, dus ook de bad guys)

Paar jaar geleden bleek dat je vrij makkelijk een EV certificaat kon krijgen, waardoor de groene balk in de browser kwam. Als aanvrager moest je wel door een paar extra hoepels springen, maar de controle was al zo slecht of makkelijk te 'spoofen', dat je geen grote multinational hoefde te zijn voor zo'n EV cert (een soort van ZZPer was al genoeg). Daardoor was het vertrouwen al weg, voordat de browser fabrikanten het uit hun code hebben gehaald.

Als je zoiets ontdekt (je bent dan natuurlijk veel te laat), moet je zoveel stampij maken dat het wordt opgemerkt door google en microsoft (en andere browsermakers), die dan het root-cert van die pruts-CA uit de truststore van hun brouwsers halen.

Maar goed, je bent dan maanden of in een gunstig geval, weken verder voor de meeste browsers zijn geupgrade en de pruts-CA feitelijk ophoud te bestaan.

Uiteraard staat het iedereen vrij om zelf root-ca certs uit je eigen browser truststore(s) te halen, maar dat is dweilen met de kraan open en schaalt bovendien niet naar alle internet+browser gebruikers (de meesten weten niet eens dat er zoiets in de browser en/of je os bestaat).

Dank voor jouw reactie. Ik had geen zin om op deze insinuerende Anoniem (met "grappige" :P ) te reageren, maar for the record: ik heb nog nooit voor een certificaatverkoper o.i.d. gewerkt en ik verwacht niet dat ooit te zullen doen.

Ach kom op, we kunnen het gesprek toch ook wel een beetje luchtig houden.
De overige argumenten waren overwogen en netjes geschreven toch.
Wel een beetje de kunst om jezelf niet te serieus te nemen.

We kunnen ons beter druk maken over degenen,
die op dit alles geen actie nemen
of het door gelobby en wegkijken mede in stand houden.

Pappen en nathouden helpt alleen de profiteurs
van deze toestanden.

Waarom realiseren zich dat zo weinig lieden?