Die man begrijpt niet veel van security in de praktijk.

RIP CT (tsunami)

Een 6 daags certificaat voor een site die malware host maakt deze niet veiliger voor een bezoeker.

Wat Let's doet is prachtig. Wat je wel hebt zonder certificaat (en ik heb ook veel liever mét) is dat alle browsers gaan piepen dat je sites niet veilig zijn. Weet je zeker dat je door wil gaan want dit is griezelig en eng. Je wordt al afgeknald bij de deur. Terwijl het helemaal niet zo'n drama is. Wat mij betreft mag http gewoon terug. Wel liever met SSL. Maar al die browsers flippen erop als je het niet hebt. Alsof Osama Bin Laden aan je voordeur staat. Doe je de deur open, staat ie er helemaal niet!

Voor walware sites is de tijdsduur helemaal geen probleem....
Maar als een kortlopend certificaat niet meer verlengd kan worden is na 6 dagen een certificaat vervallen, geen checks met ocsp, revocation lists meer nodig.

Andere certificaten leven dan nog 3 maanden, of 1 a 2 jaar.

Het is dus wel een privacy vriendelijk alternatief zonder reele nadelen voor legitieme sites.

Dat lijkt mij ook niet het doel van een certificaat. Het doel is om na te gaan of je effectief met het domein communiceert dat weergegeven wordt.
Om malware sites te detecteren heb je andere oplossingen nodig.

Lijkt me een nachtmerrie voor beheerders om iedere 6 dagen je certificaten te moeten vervangen.

Niet echt veel veiliger als je het mij vraagt maar meer schijnveiligheid , met LE heb je zo weer een nieuwe op ieder domein wat je maar wil.

Deze man heeft het juist heel goed begrepen. Certificaten met een korte levensduur lossen juist heel veel security problemen op die nu bestaan rondom het intrekken van certificaten. Dit is een hele goede stap!

Welk misbruik zou er dan zijn?
Volgens mij is Man-in-the-middle de enige aanval waarvoor je een certificaat kan gebruiken.
Dat betekent dat je aanvaller naast een certificaat gejat te hebben OOK nog in het lokale netwerk zit!
(Of het is een overheid / nation-state actor, maar dan heb je echt wel andere problemen...)

Of je hebt een domeinnaam overgekocht en de voormalige eigenaar zit tussen in je netwerk.
Ik denk dat ik een attack vector mis, aangezien deze uitzonderlijke situaties mij geen goede reden lijken voor deze update.

Inderdaad:

1) De servers van Let's Encrypt steunen, piepen en kraken; als er iets is dat LE *niet* doet is discrimineren. Elke brave Bert maar ook elke Chris Crimineel en Karel Kremlin kan zo vaak en zoveel certificaten verkrijgen als zij willen. Alleen al doordat één idioot, die gemiddeld ca. 30.000 .bond spam-domeinnamen per dag registreert (meer dan 1 miljoen per jaar), stijgt de CPU-load. (Nb. hoewel het om ruwweg 5 subdomeinnamen per hoofddomeinnaam gaat, wordt voor elk van hen een Let's Encrypt cert aangevraagd en verkregen).

2) Om kosten te besparen wil Josh stoppen met OCSP.

3) Het grootste risico vormen onterecht uitgegeven certificaten: zie https://infosec.exchange/@ErikvanStraten/112914050216821746 (en de twee daaraan voorafgaande toots). In zo'n situatie (vooral bij crypto-valuta-sites) is 6 dagen véél te lang.

Nee hoor, dat gaat gewoon automatisch middels certbot en een cronjob.

Ik zie nog steeds geen reden voor certificaten met kortere duur.
Als onterecht uitgegeven certificaten echt een probleem zijn moet je dat anders oplossen.

Bijvoorbeeld door af te dwingen dat een certificaat enkel mag worden uitgeleend over een beveiligde verbinding.
De public key van de aanvrager staat dan in DNS geregistreerd, private key staat op de server naast renew-script.
En als iemand die private key weet te stelen of de DNS weet aan te passen, dan is het sowieso al te laat.

Ik heb net de voordeur open gezet. Want er zijn twee zwerfkatten. De ene hebben we Julio genoemd. De andere Esmeralda de Venezuela. Esmeralda is heel lief, ze woon hiernaast en komt alleen maar om te snacken. Ze eet alles. Julio woont op straat. Maar wil alleen maar ham, gerookte zalm of brekkies. De rest vreet ie niet. Aaien is er ook niet bij. Dan haalt ie gelijk uit.

Ik zit achter mijn scherm. Security en privacy bewaken van al onze sites. Die Julio net weer binnen en alle brekkies opvreten.

Wie dit liedje begrijpt, begrijpt security ook! Zo moeilijk is het allemaal niet. Maar je moet wel bij de les blijven, uithalen mag maar dan vandaag geen brekkies, geen ham en geen gerookte zalm.

Grappenmaker!

Dat was vroeger misschien zo. Als je nu naar https://pvv.nl, https://vvd.nl of https://cidi.nl (of héél véél andere websites) gaat, zit er "gewoon" een MitM tussen. {Eerlijke aanvulling @14:49: dat geldt ook voor https://infosec.exchange.} Niks E2EE (of wel, maar 2x of vaker).

Zie https://infosec.exchange/@ErikvanStraten/114042082778156313 (als ik op deze site plaatjes kon tonen, had ik dat hier gepost).

En vervang jij ook je voordeur elke zes dagen voor deze zwerfkatten.
Is de voordeur ook voorzien van een keurmerk die je elke keer controleert voor je deze plaats of opent.
En waarom heb je geen kattenluik in de deur.
En hoe zit het met je ramen en achterdeur.
Log je wanneer de katten binnenkomen en weer naar buiten gaan.
En ik mag hopen dat ze geen ham en gerookte zalm krijgen elke keer want anders heb je geen kat meer om door de deur te krijgen. Scheelt je wel dan weer de deur open doen natuurlijk.

Beveiliging en makkelijk? Atleast weet je beter hoe je een grap maakt dan een lied over beveiliging.

Bull shit.

- Als iemand de private key weet te stelen, dan is de kans 99% dat die root toegang heeft.
Dat betekent dat hij al het verkeer kan onderscheppen aan de server kant, of gewoon de website zelf kan aanpassen.
(En met een beetje pech heeft hij ook meteen de database te pakken met alle leuke klantdata.)

- Als de aanvaller controle heeft over DNS, dan kan die zelf een MitM proxy opstellen en daarnaar verwijzen.
En daarmee kan hij gewoon net zoals iedereen zelf een DV certificaat aanvragen en inzetten.
De browser zeurt dan niet, maar toch krijg je alle onversleutelde data in handen.
Het enige wat aan de server kant zou opvallen is dat al het verkeer ineens van een beperkt aantal IP's komen.

Zou je "Bull shit." kunnen toelichten?

Sure!

1) Precies zoals je zegt: als een onverlaat de private key kan stelen, heeft het primaire probleem niets meer met certificaten en/of verbindingen te maken.

2) Aan uitsluitend een private key van een webserver (in tegenstelling tot een private key + cert voor code signing) heeft een aanvaller bar weinig: tenzij deze "toevallig" al op de netwerkroute tussen één of meerdere browsers van slachtoffers en de feitelijke server zit (die kans is klein), is een aanvullende aanval nodig om de browser ervan te overtuigen met een ander IP-adres een verbinding te maken. Met een DNS-aanval lukt dat mogelijk voor enkele klanten, maar natuurlijk niet zomaar voor iedereen. Een kwaadaardig script op de server plaatsen (dat bijv. alle user-ID's en nog niet gehashte wachtwoorden afvangt, en tegelijkertijd TOTP secrets uit het klantrecord kopiejat), is dan véél simpeler.

Kortom, aan een gekopiejatte private key van een website-certificaat heeft een aanvaller niet zoveel.

3) Als een aanvaller DNS-records van een webserver kan wijzigen, is het inderdaad "game over" - JUIST vanwege het bestaan van (in een oogwenk verkregen) DV-certs, in de eerste plaats omdat internetters in browsers geen enkel verschil meer zien tussen een website met een DV-, OV- of EV-certificaat.

De website https://bankieren.rabobank.nl gebruikt een EV-certificaat: prima (zie https://crt.sh/?Identity=bankieren.rabobank.nl&exclude=expired).

Stel een crimineel kan het DNS record voor bankieren.rabobank.nl (laten) wijzigen in bijv. 15.197.240.20, een Amazon cloudserver met nepwebsites zoals (enkele van vele):
DV-certificaatuitgevers: GD=GoDaddy, LE=Let's Encrypt, GTS=Google Trust Services.
Bron: https://www.virustotal.com/gui/ip-address/15.197.240.20/relations (open handmatig het VT tabblad "RELATIONS" als laatstgenoemde URL dat niet vanzelf doet).

Duidelijk lijkt mij dat het Amazon en genoemde certificaatuitgevers geen ene moer kan schelen dat zij nedeplichtig zijn aan cybercrime middels overduidelijk foute websites, zoals itspaypal·com. Dan gaat er hoogstwaarschijnlijk ook niemand moeilijk doen over de hosting van, en een DV-cert voor, bankieren.rabobank.nl.

Aanvulling 23:40: voor certs voor itspaypal·com zie https://crt.sh/?Identity=itspaypal.com.

Dus kan een cybercrimineel een nepwebsite voor https://bankieren.rabobank.nl inrichten op 15.197.240.20 en daar probleemloos, gratis, no questions asked en in no time een DV-certificaat voor verkrijgen, bijvoorbeeld van "Google Trust Services" (alleen al het lef om zo'n dienst zó te noemen).

Dat is 1FA (want 1 hack, slechts DNS - de rest kan via ACME).
1FA voor notabene een internetbankiersite.
En klanten zien in hun browser geen enkel verschil met de échte https://bankieren.rabobank.nl - met EV-certificaat.

Een EV-certificaat verkrijgen gaat niet met 1FA. Er mag best tevens een DNS-check bij zitten, maar zo'n certificaat krijgt je niet zomaar, niet zonder de juiste vragen beantwoord te hebben, niet zonder betaling (dus een geldspoor) en niet in een oogwenk (als https://bankieren.rabobank.nl een tijdje niet werkt gaan er niet alleen alarmbellen maar ook telefoonbellen af).

Vandaar dat ik in https://security.nl/posting/876914 schreef dat het hele systeem, inclusief browsers, op de schop moet.

Nogmaals, DV-speelgoedcerts zijn an sich geen probleem voor laag-risicowebsites, als internetters, in hun browser, maar een helder verschil zien tussen websites met zwakke en met sterke authenticatie.

Het was een uitermate doordachte keuze van big tech om dat verschil, met een onzinverhaal, uit browsers te slopen. Met een onveilig en risicovol Internet als gevolg, zoals ik vanmiddag beschreef in https://infosec.exchange/@ErikvanStraten/114042082778156313.

Duidelijk lijkt mij dat het Amazon en genoemde certificaatuitgevers geen ene moer kan schelen dat zij nedeplichtig zijn aan cybercrime middels overduidelijk foute websites, zoals itspaypal·com. Dan gaat er hoogstwaarschijnlijk ook niemand moeilijk doen over de hosting van, en een DV-cert voor, bankieren.rabobank.nl.

Dus kan een cybercrimineel een nepwebsite voor https://bankieren.rabobank.nl inrichten op 15.197.240.20 en daar probleemloos, gratis, no questions asked en in no time een DV-certificaat voor verkrijgen, bijvoorbeeld van "Google Trust Services" (alleen al het lef om zo'n dienst zó te noemen).

Dat is 1FA (want 1 hack volstaat, slechts DNS - de rest kan via ACME).
1FA voor notabene een internetbankiersite.
En klanten zien in hun browser geen enkel verschil met de échte https://bankieren.rabobank.nl - met EV-certificaat.

Een EV-certificaat verkrijgen gaat niet met 1FA. Er mag best tevens een DNS-check bij zitten, maar zo'n certificaat krijgt je niet zomaar, niet zonder de juiste vragen beantwoord te hebben, niet zonder betaling (dus een geldspoor) en niet in een oogwenk (als https://bankieren.rabobank.nl een tijdje niet werkt gaan er niet alleen alarmbellen maar ook telefoonbellen af).

Vandaar dat ik in https://security.nl/posting/876914 schreef dat het hele systeem, inclusief browsers, op de schop moet.

Nogmaals, DV-speelgoedcerts zijn an sich geen probleem voor laag-risicowebsites, als internetters, in hun browser, maar een helder verschil zien tussen websites met zwakke en met sterke authenticatie.

Het was een uitermate doordachte keuze van big tech om dat verschil, met een onzinverhaal, uit browsers te slopen. Met een onveilig en risicovol Internet als gevolg, zoals ik vanmiddag beschreef in https://infosec.exchange/@ErikvanStraten/114042082778156313.

Beste mensen

Luister naar Erik.
Die heeft er verstand van

Ik werk bij een CA
Ook ik weet dat DV alleen maar cybercrime in de hand werkt.
Cybercrime zal alleen verminderen als de eigenaar van de website bekend is. Dan is die namelijk op te sporen.

Zoals DV nu werkt
- een donkere steeg
- u loopt daar
- u krijgt en klap op het hoofd en wordt beroofd
- uw medemens loopt daar (ongeveer 100.000 mensen)
- die krijgen een klap op het hoofd en worden beroofd (zal wel wat minder dan 100.000 mensen zijn, maar toch)
- de politie komt naar dat beruchte donkere steegje.
Voor de slechterik geen probleem.
- die maakt verwijdert het donkere steegje
- verwijdert ook bewijs
- hoeft niet eens op zoek naar een nieuw donker steegje, want de slechterik maakt gewoon binnen een minuut een nieuw donker steegje.
start maar aan het begin

Ik heb een cronjob draaien die iedere dag via certbot alles vernieuwd (hij skipt de domeinen die al een recent genoeg certificaat gebruiken). Job maakt een tijdelijk TXT record aan in mijn PowerDNS, renewed de wildcard certificaten, en verwijdert het record weer.

Handmatig certificaten vernieuwen is zo uit de tijd.