Let's Encrypt schakelt validatiemethode uit vanwege probleem met shared hosting

Let's Encrypt heeft domeinvalidatie via tls-sni uitgeschakeld, omdat dit het in bepaalde gevallen mogelijk maakt om een certificaat voor een domein aan te vragen dat niet aan de vragende partij toebehoort. De organisatie werkt aan een oplossing.

In een bericht op zijn website legt Let's Encrypt uit dat het onlangs een waarschuwing ontving van Frans Rosén van Detectify dat hij in staat was om via een tls-sni-01-challenge, deel van het acme-protocol, een certificaat voor een domein aan te vragen dat niet aan hem toebehoort. De organisatie zegt dat dit te maken heeft met een bepaalde shared-hostingsconstructie en dat zij inmiddels in gesprek is met hostingproviders die kwetsbaar zijn. Op die manier wil Let's Encrypt zijn validatiedienst snel weer kunnen aanbieden door de providers in kwestie te blokkeren.

Het probleem doet zich alleen voor als een hostingprovider veel gebruikers achter hetzelfde ip-adres onderbrengt en als gebruikers certificaten voor willekeurige namen kunnen uploaden zonder te bewijzen dat ze eigenaar zijn van het desbetreffende domein. Dit zou zich in ieder geval voordoen bij twee grote providers, aldus Let's Encrypt. Als een aanvaller bijvoorbeeld een site heeft achter hetzelfde gedeelde ip-adres als dat waarnaar de dns van het doelwit verwijst, kan hij door gebruik te maken van de genoemde challenge uiteindelijk een certificaat instellen voor dat domein. Door een ongeldig acme-certificaat in te stellen tijdens het validatieproces, kan de aanvaller de acme-server er namelijk van overtuigen dat hij bevoegd is om certificaten voor het desbetreffende domein uit te geven.

In een post op Hacker News zegt Josh Aas van Let's Encrypt dat er geen redenen zouden zijn om aan te nemen dat kwaadwillenden van deze methode gebruik hebben gemaakt. Certificaten worden gebruikt om het internetverkeer tussen een client en een host te versleutelen, bijvoorbeeld als een gebruiker een bepaalde website bezoekt. Door het lek zou bijvoorbeeld een man-in-the-middleaanval mogelijk zijn.

Reacties (54)

[Helium-3]

Ik hoop voor vele website eigenaren dat dit niet een al te grote impact gaat hebben. Ik kan me voorstellen dat met het budget van shared hosting je snel Let's encrypt neemt, terwijl je met de prijzen van een dedicated server al snel ook wel je eigen betaalde certificaat kan veroorloven. Mijn hypothese is dan ook dat een groot deel van de Let's Encrypt websites op shared hosting staat. Ben benieuwd naar de impact. Ook voor mezelf, ik maak graag gebruik van Let's Encrypt op mijn websites

[ouweklimgeit]

Dit heeft echt helemaal niets met de kosten van een certificaat te maken, maar met de complete onzin om voor een certificaat te betalen. Wij hebben tientallen dedicated servers draaien, allemaal voorzien met certificaten van LetsEncrypt. Het grote voordeel is dat je via een simpele cronjob automatisch je certificaten kunt verlengen en alle onzin wat betreft het genereren van CSR’s tot het verleden behoort.

De dure certificaat-aanbieders zijn gewoon de dinosauriërs van het internet die voor de komst van LE bakken met geld verdienden met het verkopen van lucht.

[Aikon]

Dat is wel een tikkeltje overdreven natuurlijk. LE biedt geen Organization Validation (OV) of Extended Validation (EV) certificaten aan immers, daar zitten - mits goed uitgevoerd - handwerk en dus kosten aan. En ook een normaal certificaat is niet geheel kosteloos, maar inderdaad wordt daar nu wel te veel voor gevraagd.

Helaas lijkt mijn hoster LE te blokkeren voor de goedkopere pakketten en dus moet ik er alsnog indirect voor betalen.

[nst6ldr]

OV en EV is ook niet echt wat waard, kan me nog herinneren dat ik een telefoon in m'n handen kreeg gedrukt van een collega met een Indiër van Comodo aan de lijn. Die vroeg of ik zijn manager was en hoe ik heette. Uiteindelijk hebben we een EV certificaat gekregen op basis van verzonnen gegevens.

Uiteindelijk moet een organisatie als een bank of iets dergelijks toch echt zelf in de gaten houden of men probeert te phishen en hier hun klanten of bezoekers van op de hoogte stellen.

[Aikon]

Ook een tikkeltje overdreven Een EV vereist iets meer dan zomaar een belletje. Je moet wat documentatie opsturen en je wordt op het nummer dat bekend is bij de KvK gebeld en nog enkele controles. Ik beweer niet dat het waterdicht is, maar óf je verhaal klopt niet óf Comodo houdt zich niet aan z'n eigen regels.

[nst6ldr]

Ben bang van niet.

Het was voor een klant die niks wilde weten van dat hele computer gebeuren, we moesten z'n site regelen en wij keken maar hoe we het deden. We hebben toen hun bedrijfsnaam opgegeven, de rest van de gegevens konden we verzinnen. Collega in kwestie had het naar eigen zeggen vaker zo gedaan.

[sdk1985]

Dan zijn ze tegenwoordig een stuk strenger. Vorig jaar heeft het 3 maanden geduurd omdat bij iemand het telefoonnummer op KvK afweek van het ingestuurde nummer (oud nummer) en DUNS ook het oude nummer bevatte.

[Sito]

Als het laatste het geval is (dat Comodo zich niet aan de regels houdt) is het dus totaal niet waterdicht. Je hebt namelijk een single point of failure: de uitgever van het certificaat.

[Aikon]

Ten eerste zeg ik letterlijk dat ik niet denk dat het waterdicht is? Ten tweede is het nogal logisch dat de uitgever de spof is, het systeem is gebaseerd op vertrouwen in die uitgever, en dat kan (en zal ooit) geschonden worden. Tijd voor een systeem dat niet op vertrouwen is gebaseerd (zoals de blockchain bijv.).

[Barryke]

Helaas lijkt mijn hoster LE te blokkeren voor de goedkopere pakketten en dus moet ik er alsnog indirect voor betalen.

Dat noem ik "featureslack" .. het eerste TV ontvang kastje waarin ik niet zelf zender volgorde mocht bepalen, omg wat werd ik daar boos van!

[Steef435]

Als dat echt zo is zou ik direct een andere aanbieder zoeken. Dit soort grapjes slaan nergens op.

[cakemasher]

Heb je al eens een browser client gebruikt? Certificaat wordt aangevraagd en uitgegeven op een andere server, waarna je het certificaat etc. kan opslaan in je hosting pakket (mits je provider natuurlijk dit ook controleert). Nadeel is alleen wel dat je deze handelingen elke 90 dagen moet herhalen.

[Aikon]

Bedankt, maar de .well-known/acme-challenge/ folder is geblokkeerd en de andere opties lijken ook niet te werken...

[EraYaN]

En de DNS verificatie? Of is dat geen ding meer?

[Olaf van der Spek]

LE biedt geen Organization Validation (OV) of Extended Validation (EV) certificaten aan immers, daar zitten - mits goed uitgevoerd - handwerk en dus kosten aan.

Hoeveel mensen zou het opvallen als je gewoon LE gebruikt en niet OV of EV?

Dan nog, vroeger was het enige dat een certificaat garandeerde dat er iemand geld had betaald. Sinds LE is zelfs dat niet meer waar.

[Reactie gewijzigd door Olaf van der Spek op 27 juli 2024 00:49]

[mg794613]

Blokkeren?
Pardon? Dat mag zomaar?

Maar inderdaad OV/EV != normaal cert. Daar betaal je dan ook voor.

[Aikon]

Van wie zou het niet mogen? Zij bieden hosting aan, moeten ze zelf weten toch. Dat ik weg ben als het waar is, is een ander verhaal

[mg794613]

Ah volledig managed hosting, dacht even dat er bedoelt werd dat je zelf niet je eigen ssl provider mag kiezen op je eigen host.

[sdk1985]

Dit heeft echt helemaal niets met de kosten van een certificaat te maken, maar met de complete onzin om voor een certificaat te betalen. Wij hebben tientallen dedicated servers draaien, allemaal voorzien met certificaten van LetsEncrypt. Het grote voordeel is dat je via een simpele cronjob automatisch je certificaten kunt verlengen en alle onzin wat betreft het genereren van CSR’s tot het verleden behoort.

De dure certificaat-aanbieders zijn gewoon de dinosauriërs van het internet die voor de komst van LE bakken met geld verdienden met het verkopen van lucht.

Let's encrypt verstookt 2.91 miljoen per jaar dus zo'n onzin is het niet om voor een certificaat te betalen. Met de 100 miljoen certificaten die ze nu hebben uitgegeven zijn de kosten per certificaat natuurlijk peanuts.

Voor die tientallen servers bestaat natuurlijk de wildcard, iets dat (nog) niet via Let's Encrypt kan. Kost je per jaar circa 50 euro en daarmee kun je een onbeperkt aantal servers beveiligen. Ook kun je overal hetzelfde certificaat inknallen dus dat kan tijdbesparend werken.

De waarde van Let's Encrypt zit voor mij niet in de kosten maar juist in de snelheid van uitgifte. Alles is volledig te automatiseren en zelfs bij een Comodo DV moet je toch altijd weer een hoop stappen doorlopen (csr genereren, email, file of dns validatie, keys opzoeken, root certificate erbij pakken, enz). Met let's encrypt ben je letterlijk in 10 seconde klaar. Bij een normaal certificaat duurt het snel een uur, ivm wachten op validatie.

[Reactie gewijzigd door sdk1985 op 27 juli 2024 00:49]

[nils83]

Onzin?

Wie gaat er nu voor bvb een betaalsite met een certificaat van LetsEncrypt werken? Er zijn zat voorbeelden waar alternatieven alles behalve onzin zijn.

[Belgar]

"false equivalent". Voor een betaalsite wil je al snel een EV certificaat en geen DV certificaat, wat het enige type is dat let's encrypt uitgeeft.

Voor DV certificaten is wat mij betreft let's encrypt net zo goed als verisign

[rbr320]

Voor DV certificaten is wat mij betreft let's encrypt net zo goed als verisign

Niet alleen wat jouw betreft, dat is aantoonbaar waar.

[Yggdrasil]

Mwah, er worden steeds meer twijfels gesteld bij de toegevoegde waarde van EV t.o.v. DV. Het idee is goed, maar door o.a. de inconsequente uitvoering in browsers en het ontbreken van een HSTS-achtige header waarmee een domein EV kan verplichten is het feitelijk waardeloos.

Troy Hunt heeft hier een interessant artikel over geschreven. Aanrader: https://www.troyhunt.com/...as-phishing-lets-encrypt/

[Helium-3]

Daar heb je eigenlijk helemaal gelijk in

[.oisyn]

De impact is vrij klein. Shared hosting is niet het enige criterium, de hoster moet ook nog eens toestaan dat gebruikers willekeurige certificaten kunnen uploaden die niet aan hun eigen domein toebehoren.

.edit: ter verduidelijking, met "uploaden van certificaten" bedoel ik niet dat je random bestanden in je user folder zet. Ik bedoel dat je een willekeurig certificaat aanbiedt aan de hoster, zodat hij deze serveert via SNI. Het zou niet moeten kunnen dat je een certificaat aanbiedt dat bedoeld is voor een ander domein dan die van jezelf.

[Reactie gewijzigd door .oisyn op 27 juli 2024 00:49]

[TD-er]

Is dat het probleem waardoor men een MitM zou kunnen veroorzaken? Of zou deze maatregel toch ook effect kunnen hebben voor gebruikers van hosters die die mogelijkheid niet bieden, maar wel LetsEncrypt gebruiken?
Ik heb zelf bijvoorbeeld een server met daarop ISPconfig als hosting omgeving en gebruik daar LetsEncrypt.
Tevens zijn alle domeinen beschikbaar via 1 IP. (want heb aanzienlijk minder IPs dan domeinen)
Kortom, zelfs als ik niet het uploaden van een certificaat toe sta, zal ik toch last kunnen krijgen van deze maatregel?

[.oisyn]

Nou ja, het stelt je in staat om certificaten te bemachten voor domeinen die je niet in je beheer hebt. En als je eenmaal het certificaat van een ander domein hebt, dan kun je je uitgeven alsof je de eigenaar van dat domein bent, zoals in een MITM aanval. Jij hebt immers de private key van het certificaat, en het certificaat is legit, dus de browser zal niet klagen.

[sdk1985]

Wat dat betreft blijft een EV dan toch zijn meerwaarde hebben. Zie je bij de xbank/yshop ineens geen bedrijfsnaam in de browserbalk dan gaat er hopelijk een lampje branden.

[Verwijderd]

Dat lijkt me niet zo'n heel groot probleem; ik heb niet echt het idee dat mijn hosters controleren welke files ik op mijn data-volume zet.

[.oisyn]

Het gaat niet om data, het gaat om het feit dat je server die certificaten serveert. En dat jij dus een certificaat kan aanbieden voor henk.nl, terwijl je zelf alleen piet.nl in je beheer hebt.

[Feanathiel]

Gewoon een vraag omdat ik er niet veel vanaf weet: dat maakt toch niet uit? Dan ga je naar piet.nl en je krijgt een certificaat voor henk.nl terug. Rood kruis in de hoek, en dan zouden voor de bezoekers al genoeg alarmbellen moeten afgaan.

Dat je een certificaat (met private key) krijgt van LetsEncrypt, zou toch voldoende informatie moeten zijn dat je eigenaar bent?

@.oisyn Ah, bedankt voor de uitleg!

[Reactie gewijzigd door Feanathiel op 27 juli 2024 00:49]

[.oisyn]

Dat is niet hoe het werkt. LE's TLS-SNI-01 challenge werkt als volgt:

• De client zegt tegen de ACME server dat hij een cert wil valideren voor henk.nl
• De ACME server genereert een token, bijvoorbeeld: 1234.5678
• De client genereert een self-signed cert voor 1234.5678.acme.invalid en geeft deze aan de webserver
• De ACME server zoekt op waar henk.nl naar wijst, vraagt de server om het ceritificaat van 1234.5678.acme.invalid en kijkt of de boel klopt.

Als de client in staat is een willekeurig certificaat te serveren, dan moet om dit te laten werken de webserver dat certificaat ook serveren als er wordt gevraagd om het domein dat in het certificaat staat. Het is dus in die gevallen niet zo dat je het zelf gegenereerde certificaat van henk.nl krijgt als je die van piet.nl vraagt, je krijgt het zelf gegenereerde certificaat van henk.nl als je die van henk.nl vraagt.

[Reactie gewijzigd door .oisyn op 27 juli 2024 00:49]

[Opperpanter2]

Ik kan nergens echt goed leesbare uitleg vinden over hoe TLS-SNI-01 werkt. Maar essentieel onderdeel lijkt te zijn dat de website een certificate met een bepaalde domeinnaam moet genereren en daarna moet serveren op het ip dat toebehoort aan het domein dat ze willen valideren.
Dit betekent dan toch dat de website eigenaar op de een of andere manier "willekeurige" ssl certificaten moet kunnen configureren voor zijn domein? Dus die functionaliteit volledig uitzetten breekt dan toch heel TLS_SNI-01?

[.oisyn]

Dit betekent dan toch dat de website eigenaar op de een of andere manier "willekeurige" ssl certificaten moet kunnen configureren voor zijn domein

Exact, ik heb het essentiele onderdeel even dikgedrukt. Een certificaat beschrijft voor welk domein hij is bedoeld. Een hoster weet welke domein(en) jij in je beheer hebt. Als jij een certificaat uploadt dat niet aan jouw domein toebehoort, maar dat domein bestaat toevallig wel op de server (in beheer van een andere gebruiker), waarom is het dan toegestaan dat jij een certificaat van dat andere domein aanbiedt?

[Opperpanter2]

Voor ACME moet een certificaat geserveerd worden voor een domein in de trant van 773c7d.13445a.acme.invalid. Dit zal toch nooit een domein zijn dat aan mij toebehoort?

Het zal ongetwijfeld genuanceerder zijn, maar ik zie het nog niet.

[.oisyn]

Maar het is meestal ook niet de client zelf die de certbot draait. Er zal in de regel een webserver plugin draaien, die de boel gewoon voor je afhandelt. Die plugin kan dus gewoon een cert installeren voor 773c7d.13445a.acme.invalid als jij als client via een webinterface van de hoster een LE cert aanvraagt voor jouw domein.

[base_]

Moeten die hosters dan bestanden gaan filteren? Klanten kunnen toch van alles uploaden? Lijkt me niet moeilijk om dan een certificaataanvraag in te stellen van van een van de domeinen die op hetzelfde IP zit. Gaat het hier eigenlijk over aanvragen voor de domeinen die op hetzelfde ip zitten?

[.oisyn]

Hosters moeten weldegelijk de certificaten filteren die ze serveren via SNI, anders zijn de rapen gaar.

[tweaknico]

Ja, en omdat dit via een SSL sessie verloopt is SNI vereist omdat anders een voorliggende proxy of de webserver zelf niet het juiste certificaat kan kiezen voor een sessie.
Zonder SNI is er per IP-adres/TCP-Poort paar 1 certificaat mogelijk (al kunnen er Subject-Alternate-Names in staan. (De omvang van SAN een certificaat is overigens beperkt).

SNI is overigens een 2 snijdend zwaard, dankzij SNI is het nu ook mogelijk om in TLS data vast te stellen welke host gevraagd is.

[Reactie gewijzigd door tweaknico op 27 juli 2024 00:49]

[alienfruit]

Ja, ik heb zelf een VPS en kan ook wel een certificaat betalen maar Let's Encrypt is een stuk eenvoudiger in het gebruik!

[kramer65]

En met de 3-maandelijkse automatische vernieuwingen ook nog eens een stukje veiliger.

[Gbrandsma]

Let's Encrypt wordt niet alleen gebruikt vanwege de kosten. Ook transparantie en het gemak waarmee je zaken kunt automatiseren voor meerdere certificaten zijn belangrijke eigenschappen om voor Let's Encrypt te kiezen.

[Verwijderd]

Bij shared hosting ben je wel afhankelijk van ondersteuning van de hostingpartij voor LE.
Ik denk zelf dat LE vooral geinstalleerd is op VPS bakjes en hobby/persoonlijke servers want daar leent certbot zich toch prima voor...

Geld is overigens niet eens persé het excuus. Een simpel certrificaat kost immers maar een tientje per jaar, maar brengt wel gedoe met zich mee.
Let's Encypt kan je volledig geautomatiseerd implementeren en aansturen met cronjobs wat het ideaal maakt in omgevingen die je in de day to day wil kunnen vergeten, ad hoc omgevingen en omgevingen waar je allicht gewoon geen certificaatbeheer voor wil doen. Vind ik toch best wel een ding als een simpel (non-ev en non-wildcard) certificaat "adequaat" is voor je doel.

Let's Encrypt's meerwaarde zit al met al zeker niet puur in het "gratis" prijsmodel.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 00:49]

[Bardman01]

Ook hier op Tweaker's word Let's Encrypt gebruikt

[nils83]

En hoe verloopt bvb het aankopen van een abonnement dan? Geen EV of via externe site?

[JJ93]

Bij een EV certificaat wordt bij een B.V. de handelsnaam en daarachter tussen haakjes de statutaire naam getoond. In het geval van Tweakers is de statutaire naam "de Persgroep Online Services B.V." en de handelsnaam "Tweakers". Dan krijg je dus:

Tweakers (de Persgroep Online Services B.V.)

Volgens mij is de reden dat Tweakers geen EV certificaat gebruikt o.a. dat het door de lange naam een erg groot deel van de adresbalk inneemt en dat ze liever ook niet de statutaire naam er in wilden hebben. Daarnaast weten de meeste bezoekers hier vast ook wel dat security wise een EV certificaat of Lets Encrypt certificaat geen verschil maakt.

[sdk1985]

Daarnaast weten de meeste bezoekers hier vast ook wel dat security wise een EV certificaat of Lets Encrypt certificaat geen verschil maakt.

Waarmee deze meeste bezoekers er dus blijkbaar naast zitten. Immers blijkt in dit nieuwsbericht dat je blijkbaar deze DV's spoofen en dus een MITM aanval kunt doen, terwijl dat bij een EV niet gaat. Let's encrypt geeft immers geen EV's af.

[Reactie gewijzigd door sdk1985 op 27 juli 2024 00:49]

[EraYaN]

Nee de DV's worden niet gespoofed. Shared hosting providers doen hun werk gewoon niet goed. Je kunt altijd gewoon de webroot verifier gebruiken bijvoorbeeld, zolang jij jou domein naar een correct IP adres laat wijzen waar niet zo'n shared hoster z'n shit draait is er niets aan de hand. Je kon dus niet zomaar een cert voor google.com krijgen, maar bijvoorbeeld wel voor een andere tenant op hetzelfde IP adres (dus zelfde shared hosting server).

En bij EV's wordt er nog meer aangemodderd, en dat geeft dan ook nog eens een probleem dat het meer vertrouwen wekt terwijl dat eigenlijk vaak helemaal niet op zijn plaats is. Er hoeft maar 1 karige CA tussen te zitten en ze zijn al niets meer waard.

[kristofv]

Zou al raar zijn als ze het niet deden

[Opperpanter2]

"It applies equally to TLS-SNI-02."

Maar er is blijkbaar geen reden om die te disablen?

[Belgar]

SNI-02 is nog niet public. Het is een closed beta

[Opperpanter2]

Ik las het net ja. Thank!

[The Zep Man]

De meest simpele vorm van verificatie is via HTTP, en de meest complexe vorm is (dynamisch) via DNS. TLS-SNI zit daartussen.

Gewoon dus weer een HTTP servertje opstarten op het moment dat het nodig is voor verificatie.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 00:49]

[WhatsappHack]

Ik ben benieuwd of dit de LE-integratie van cPanel sloopt. Oo