Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Let's Encrypt trekt drie miljoen certificaten in vanwege bug

Let's Encrypt trekt woensdag drie miljoen tls/ssl-certificaten in vanwege een bug. Het gaat om 2,6 procent van de actieve certificaten. Gebruikers waarvan het bedrijf contactinformatie heeft krijgen een e-mail.

Door de bug die op 29 februari werd ontdekt, kan Let's Encrypt de authenticiteit van een groot aantal certificaten niet meer verifiëren. Het bedrijf beschrijft de fout op een pagina en meldt daar dat de bug waarschijnlijk sinds 25 juli vorig jaar actief was.

Let's Encrypt gaat de getroffen certificaten vanaf woensdag intrekken. Het gaat om ruim drie miljoen certificaten en volgens de organisatie is dat 2,6 procent van het totale aantal actieve certificaten, dat momenteel 116 miljoen bedraagt. Website-eigenaren moeten het certificaat vernieuwen. Als hun e-mailadres bekend is bij Let's Encrypt, krijgen ze daar een bericht over.

Het opgeven van een e-mailadres is echter optioneel bij het aanvragen van een Let's Encrypt-certificaat. Daarom heeft de organisatie een tool online gezet waarmee admins kunnen controleren of certificaten zijn getroffen door de bug. Ook staat er een volledige lijst online met alle serienummers van de certificaten die ingetrokken zullen worden.

Door Julian Huijbregts

Nieuwsredacteur

03-03-2020 • 18:18

71 Linkedin

Submitter: Kevin_J

Reacties (71)

Wijzig sortering
Een toffe, technische uitleg & tijdlijn van de bug is te vinden in het incident-report bij de Firefox root store: https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1
De mail;
We recently discovered a bug in the Let's Encrypt certificate authority code,
described here:

https://community.letsenc...caa-rechecking-bug/114591

Unfortunately, this means we need to revoke the certificates that were affected
by this bug, which includes one or more of your certificates. To avoid
disruption, you'll need to renew and replace your affected certificate(s) by
Wednesday, March 4, 2020. We sincerely apologize for the issue.

If you're not able to renew your certificate by March 4, the date we are
required to revoke these certificates, visitors to your site will see security
warnings until you do renew the certificate. Your ACME client documentation
should explain how to renew.

If you are using Certbot, the command to renew is:

certbot renew --force-renewal

If you need help, please visit our community support forum:
https://community.letsenc...ficates-on-march-4/114864

Please search thoroughly for a solution before you post a new question. Let's
Encrypt staff will help our community try to answer unresolved questions as
quickly as possible.


Your affected certificate(s), listed by serial number and domain names:

[Reactie gewijzigd door 0stone0 op 3 maart 2020 18:20]

Mooie om te controleren of jouw domein vernieuwd moet worden:

curl -XPOST -d 'fqdn=JOUWDOMEIN.COM' https://checkhost.unboundtest.com/checkhost
Ik heb even moeten zoeken hoe dit met mijn traefik/kubernetes setup te doen.

legos heeft deze tool in mekaar gedraaid https://github.com/containous/acme-fixer
die zet basically het certificate veld voor een certificate op null.
Als je dan traefik herstart worden je certs vernieuwd. In kubernetes door de pod(s) te deleten.

Bron: https://github.com/containous/traefik/issues/6418
Zojuist de mail ontvangen en meteen de certificaten die werden genoemd vernieuwd. Het is gelukkig niet veel werk, want alles is al ingericht om elke 2 maanden te vernieuwen. Wat dat betreft is dit toch wel weer een voordeel van die korte "houdbaarheidsdatum", want men richt het er gewoon op in.

Snel gehandeld, maar wel jammer dat dit zo snel opeens moet. De bug is namelijk een paar dagen geleden ontdekt en gefixt. Misschien was het toen niet snel mogelijk om mensen te verwittigen, maar had liever een kleine dag extra gehad.
Ze hadden toch gewoon de certificaat eigenaars kunnen verwittigen en hen eerst de certificaten laten vernieuwen.
Als je een halfjaar tot een jaar de tijd hebt, prima. Maar dan zit je al bijna op automatische vernieuwing gezien de looptijd van LE certificaten.

Voor CA's zoals LE gelden er formeel gesproken industriestandaarden die ze verplichten om het geheel tijdig in te trekken (zie de Baseline Requirements sectie 4.9.11).

Overigens, mocht je nog meer details willen weten over hoe deze bug precies heeft kunnen optreden, dan is de bug (incidentmelding) bij Mozilla nog wel interessant.

[Reactie gewijzigd door SleutelMan op 3 maart 2020 19:03]

die hebben allemaal een email gehad, als het email adres bekend is en krijgen 1 dag om het certificaat te vernieuwen.
1dag 8)7
Dan zit je maar ergens op een conferentie aan de andere kant van de planeet
Ja, vet vervelend. Weet je wat ook vervelend is? Als van de ene op de andere dag je CA niet meer bestaat (en dus al je certificaten ongeldig zijn), omdat ze niet adequaat handelden wanneer ze een mogelijke route voor misbruik van hun certificaten niet direct blokkeren en niemand ze meer vertrouwt ;)

"Vertrouwen komt te voet en gaat te paard!" O-)

[Reactie gewijzigd door Reptile209 op 3 maart 2020 19:16]

Deed me even denken aan diginotar. Bestond ook 'opeens' niet meer
Daar refereerde Reptile209 ook naar ;)
*the reference and me.. dankje
Als jij je omgeving hebt uitgerust met certificaten van Let's Encrypt heb je het vernieuwen ervan volledig geautomatiseerd, dat is met Let's Encrypt namelijk zo'n beetje vereist en ook zeer zeker de bedoeling gezien de relatief korte geldigheid van de certificaten. In dat geval is je omgeving zeer waarschijnlijk zo ingericht dat je zelfs vanaf de andere kant van de wereld wel even remote kan inloggen en het vernieuwingsscript een trap kan geven, of iemand anders kan vragen dit even te doen.
1dag 8)7
Dan zit je maar ergens op een conferentie aan de andere kant van de planeet
Mooi dat alles afgezegd wordt dan maar :+
1dag 8)7
Dan zit je maar ergens op een conferentie aan de andere kant van de planeet
Dan ben jij een SPOF, en heb je nog wel grotere problemen. ;)
Hoeveel KMO's hebben geen eigen IT-er en doen beroep op externen.
Ik blijf het onbegrijpelijk vinden.

Een autofabrikant roept toch ook hun auto's terug als er een defect gevonden wordt (zelfs al is dit potentieel een erg gevaarlijk defect) , die gaan toch ook van op afstand niet alle auto's aan de ketting leggen.
Volgens mij is er niks bij LE dat je dwingt om een geldig e-mailadres op te geven. Of dat adres ook daadwerkelijk te lezen. Zie trouwens de laatste alinea in het artikel: "Het opgeven van een e-mailadres is echter optioneel bij het aanvragen van een Let's Encrypt-certificaat."

Dit probleem verhelpt zichzelf sowieso binnen 3 maanden, als elk certificaat vernieuwd of verlopen is, maar mochten er toch mensen zijn die hier bewust misbruik van hebben gemaakt, dan worden die tenminste gestopt. Dat lijkt me als CA vrij essentieel om je vertrouwenspositie te behouden. :)

[Reactie gewijzigd door Reptile209 op 3 maart 2020 19:00]

Dat is dan jammer voor die mensen, maar het had wel zo leuk geweest voor zij die wel netjes een mailadres hadden opgegeven.

Iedereen zegt dat een ander CA geen toegevoegde waarde heeft , welnu bij deze is het tegendeel bewezen.
maar het had wel zo leuk geweest voor zij die wel netjes een mailadres hadden opgegeven.
Dat hebben ze toch ook gedaan? Wat is je punt nou precies?
Gebruikers waarvan het bedrijf contactinformatie heeft krijgen een e-mail.

[Reactie gewijzigd door .oisyn op 3 maart 2020 19:23]

Zij revoken de certificaten ipv ikzelf.
Heb maar een keer een paar 100 klanten waarvan je bij tientallen ter plaatse moet gaan om de certificaten te vervangen. Dat ga je niet echt redden op 24u zelfs niet in 1 week
|:(
Dan zit je business model niet handig in elkaar als je daardoor in de problemen komt. Gratis CA dienst doorverkopen? Dan - maar ook in principe met een grote betaalde CA - moet je een noodscenario hebben voor een situatie als deze. En die anders nu als een malle ontwikkelen :X
Business model is gewoon diensten leveren misschien ?!
Je gaat langs bij de klant en je zet vanalles en nog wat op waarvoor hijzelf niet het personeel of de kennis heeft.

Ik wil de mensen niet te eten geven, die op deze manier hun geld verdienen.
Klopt helemaal hoor. Maar dus ook - even kort door de bocht - zijn die dienstverleners geen "experts" als ze dit niet voorzien hebben. Als je dat niet op kan vangen via je voorwaarden (SLA) of door inzet van meer personeel, dan heb je nu een probleem. Idem als er een enorme crash is bij je hoster, een crypto-infectie, etc.
Wat is dan het probleem, nu kun je extra uren factureren.....
Ben je dan ieder kwartaal een 2-tal weken bezig met het manueel renewen van alle certificaten die door letsencrypt uitgegeven worden?
Nee, want die renewen zichzelf. Alleen nu moet je ze force-renewen, want ze verlopen niet, ze worden revoked.

Ik weet eerlijk gezegd niet of certbot een revoked certificate zelf force-renewed, of dat het er vanuit gaat dat het revoken niet voor niets is geweest (of mogelijk zelfs dat het helemaal geen CRL-check doet op 'zichzelf').
Ik weet eerlijk gezegd niet of certbot een revoked certificate zelf force-renewed
Nee, want de check is lokaal op expiration date.
Je zou dit op afstand en geautomatiseerd moeten kunnen doen met een simpel commando, dat is namelijk het hele idee achter Let's Encrypt. Als dat niet kan is Let's Encrypt niet de juiste CA keuze voor de omgeving in kwestie.
Door deze BUG is het mogelijk geweest certificaten uit te geven voor domeinen waar de CAA records dat niet toelieten. Daarom moeten al deze certificaten waar de bug optrad ongeldig verklaard worden. Tenminste zo begrijp ik het na het lezen.
Beter laat dan nooit. :)

Het nut van certificaten is op encryptie na wel een beetje aan het vervallen, tegenwoordig genoeg websites die voor phishing worden gebruikt die standaard een LE certificaat nemen. Niet iets waar zij schuldig in zijn (juist blij dat ze er zijn), maar kan dat niet op andere manieren of blijft een certificaat altijd wel een must veilige verificatie tussen client/server?

[Reactie gewijzigd door foxgamer2019 op 3 maart 2020 18:36]

Een certificaat is niet bedoeld om te zien of de site legitiem is of niet. het is bedoeld om het verkeer tussen de site en de gebruiker te beveiligen.
Nee, daar is encryptie voor. En encryptie kan prima zonder certificaat. De client zou gewoon zonder morren elke public key kunnen accepteren. De reden dat dat niet gebeurd is juist die validatie op basis van de certificaten. Dat dat niet werkt in de praktijk is een heel ander verhaal.
En encryptie kan prima zonder certificaat.
Hoe voorkomen je in dat geval man-in-the-middle aanvallen?
Encryptie is nutteloos zonder authenticatie.
.edit: sorry was bedoeld als reactie op @MadEgg

[Reactie gewijzigd door .oisyn op 3 maart 2020 19:35]

Dat maakt het niet minder encrypted. Certificaten zijn een zeer matige vorm van authenticatie. Het is beter dan niets, maar gezien de hoeveelheid phishing domains die zonder problemen certificaten krijgen helpt het weinig.
Certificaten zijn een prima vorm van authenticatie. Een certificaat hoort per definitie bij het domein waar het voor is uitgegeven, anders werkt het niet.

Dat dit domein vervolgens dingen doet waar jij het niet mee eens bent omdat het bijvoorbeeld malware verspreid, aan phishing doet of andere dingen die mogelijkerwijs illegaal zijn is niet een probleem van/met het certificaat noch de certificate authority. Een CA is geen internetpolitie.
Daar kun je over twisten. Sowieso is de centralisatie van CA's niet bevorderlijk. En de laagdrempeligheid van LE is aan de ene kant mooi omdat er nu geen enkel excuus voor legitieme websites is om géén encryptie te gebruiken, maar aan de andere kant is het nu voor kwaadwillenden net zo makkelijk om een website op te zetten die door browsers als veilig wordt aangemerkt, zonder daar enige investering voor te doen. Voorheen kostte dat op zijn minst een paar euro, zo niet tientallen.

Hoe het beter zou kunnen weet ik niet. Een web-of-trust achtige oplossing heeft wel wat, maar het nadeel is dan weer dat het lastiger wordt om een nieuwe website op te starten. En dat zal ongetwijfeld leiden tot mogelijkheden 'trust' te kopen. En anders moet je signatures valideren langs een andere bron.

In ieder geval, gezien elke website gratis een certificaat van LE kan krijgen hebben CA's geen rol van betekenis meer. Beter zou dan DANE zijn voor authenticatie: vertrouwen op DNSSEC voor de veiligheid en de server authenticeren via de DNS resolver.
Dat maakt het niet minder encrypted
Het maakt de encryptie zo goed als nutteloos omdat je geen zekerheid meer hebt dat de tegenpartij met wie je praat ook echt de partij is die je denkt dat het is. Het kan net zo goed een man in the middle zijn die dus *alsnog* al je verkeer kan afluisteren.
Het is beter dan niets, maar gezien de hoeveelheid phishing domains die zonder problemen certificaten krijgen helpt het weinig.
Die phishing domains zijn gewoon wie ze zijn. Dat certificaat is niet zozeer voor de mens om te controleren alswel voor de software om te verifieren dat de tegenpartij ook daadwerkelijk dat domein is.

[Reactie gewijzigd door .oisyn op 3 maart 2020 20:14]

Nutteloos, maar niet minder encrypted.

Als ik iets AES-256-CBC versleutel, uitprint en op een marktplein schilder met de sleutel eronder is het ook encrypted. Nutteloos, dat wel. Maar nog steeds encrypted.
Als je woordspelletjes wil spelen dan ben ik wel klaar hier
Het is geen woordspelletje. De statement was dat certificaten voor beveiliging zorgen. Beveiliging wordt voor het grootste deel verzorgt en een deel door authenticatie middels certificaten. Beide zijn nodig. Certificaten alleen is geen beveiliging.
Niet. Maar dat neemt niet weg dat er dan wel encryptie is.

SSH werkt ook met public keys, en zonder certificaten. Hoe je daar een MitM ontdekt is dat je erachter komt dat de signature van de server plotseling veranderd is. Als je van tevoren de signature van de server weet, weet je zeker dat je met de juiste server communiceert. Dat is wat certificaten proberen te automatiseren: validatie. Niet encryptie.
En op basis waarvan bepaal jij dan initieel of de aangereikte public key ook echt van de host is die je wil bereiken? Juist, omdat jij die server waarschijnlijk zelf ingericht hebt of direct contact hebt met de beheerder van die server.

Maar op het web en specifiek https waar deze certificaten voor bedoeld zijn, zijn de sites die je bezoekt van instanties die zich op basis van het certificaat juist moeten identificeren.

:+
Het punt is dat ik dan moet vertrouwen op een CA die veelvuldig hebben laten zien ook niet betrouwbaar te zijn. Diginotar anyone? StartSSL is er inmiddels ook uitgebonjourt. Ondertussen heeft de Nederlandse overheid een CA in beheer waarmee zij de handvatten hebben om alle verkeer te MitM'en zonder dat iemand het doorheeft. De VS ongetwijfeld ook.

De eerste validatie bij SSH is één ding, het mooie daarna is dat je ervan op de hoogte wordt gesteld als de signature veranderd. Dát is de red flag. Als het certificaat van laten we zeggen Tweakers.net morgen niet meer door LE wordt verstrekt maar in plaats daarvan door de 'Staat der Nederlanden Root CA - G2' geeft mijn browser geen enkele notificatie - hij zal de site net zo goed vertrouwen. Via het systeem bij SSH zal ik een grote waarschuwing krijgen met het verzoek om mij ervan te gewissen dat er geen hacker tussen is gekropen.
Nee, het echte punt is dat jouw systeem totaal niet geschikt is om een site te beveiligen die voor publiek bestemd is.

Self-Signed certificates hebben zeker hun nut, maar enkel binnen de private context: binnen de eigen instantie/het eigen netwerk.

Je reikt nu een alternatief aan dat in ieder geval geen oplossing is in het publieke domein. En laat dat nu precies het domein zijn waar Let's Encrypt en PKI in het algemeen voor bedacht is.

Uiteraard gaat het uiteindelijk om vertrouwen, en in dit geval op third-parties die zo'n PKI hebben ingericht. Het is wellicht niet ideaal (what is?) maar er is zoals blijkt wel controle op te zijn: DigiNotar wortd niet meer vertrouwd, StartSSL ook niet meer; en in dit geval acteert een Let's Encrypt naar behoren door al deze certificaten te revoken.
En je hebt als eindgebruiker overigens alle vrijheid om op eigen houtje je trusted store door te lopen en de public keys van CA's die je niet vertrouwd er uit te bonjouren.

Maar het alternatief dat jij aandraagt zou wel zo vervelend werken dat iedereen een fingerprint melding maar gewoon doorklikt.
Nee, een SSH-achtige oplossing zou waarschijnlijk ook niet goed werken voor deze toepassing. Maar CA's hebben gewoon geen toegevoegde waarde. DANE is al een veel betere oplossing. Je moet al vertrouwen hebben in DNS en DNS is de enige check die CA's als LE doen voor het verstrekken van een certificaat. Laten we dan gewoon die CA's eruit knippen en alles via DNS doen. Heb je gelijk het probleem opgelost dat CA's technisch gezien certificaten kunnen verstrekken voor elke willekeurige domeinnaam die ze maar willen.

[Reactie gewijzigd door MadEgg op 4 maart 2020 10:55]

Ehm, DANE is in principe geen directe replacement maar juist een aanvulling op certificaten...

Het lost bijvoorbeeld downgrade attacks op SMTP op.

Voor specifieke toepassingen zou DANE wellicht ingezet kunnen worden, maar m.i, verhuis je dan het probleem van de CA instanties naar de Registrars en DNS providers. Uiteindelijk zul je ook deze instanties moeten vertrouwen.

De kracht zit 'm juist in de combinatie (≥ two factor).
Beveiliging is een algemene term. Beveiliging van een verbinding is meer dan alleen encryptie. Afhankelijk van het soort certificaat en het vertrouwen dat je er in wenst te hebben krijgt de beveiliging van de verbinding een betekenis. In veel gevallen is dat minimaal dat je er vertrouwen in kan hebben dat de versleutelde verbinding alleen om verkeer tussen jou en de site gaat, omdat je er vanuit gaat dat niemand anders behalve de site toegang tot dat certificaat heeft en de uitgever ook te vertrouwen is. Als het om algemene termen gaat heeft @florisvdk gelijk dat het bedoeld is om het verkeer tussen de site en de gebruiker te beveiligen, al is die uitleg niet heel nauwkeurig.

[Reactie gewijzigd door kodak op 3 maart 2020 20:05]

Je hebt gelijk. Toch is encryptie een minstens net zo groot onderdeel van als certificaten.

Met een certificaat kun je ook prima een handtekening onder elk bericht zetten om te valideren dat het ongewijzigd afkomstig is van de server. Dan is het nog steeds wel openbaar te lezen maar beveilig je je tegen MitM.

Encryptie zonder certificaten kan ook veilig zijn, mits je de authenticatie langs een andere weg uitvoert. En certificaten doen wel een soort van authenticatie maar feilloos is dat ook zeker niet.
Bijna: waar encryptie inderdaad zonder certificaat ook prima werkt, verlies je de zekerheid dat het versleutelde verkeer inderdaad met de eigenlijke website is. Technieken zoals Certificate Transparency zorgen er vervolgens voor dat de browser weet of het certificaat te vertrouwen is, en niet ingetrokken is.

[Reactie gewijzigd door Peter op 3 maart 2020 19:02]

Een SSL Certificaat beschermd je ook niet tegen phishing, maar is grotendeels belangrijk voor de beveiligde verbinding tussen je browser en de server waar het certificaat voor dient.

Wat er over die beveiligde lijn gaat, kan van alles zijn.
Het nut van certificaten is op encryptie na wel een beetje aan het vervallen,
Ik heb juist het gevoel dat certificaten ontzettend veel nut hebben, behalve de encryptie zelf.

Beetje sterk gezegd natuurlijk, maar certificaten leveren nu juist veel op tegen allerhande zaken als phishing en MitM-aanvallen en privacy-tracking.

Maar er zijn weinig partijen die *echt* de moeite zouden besteden om zelfs 3DES te gaan kraken, laat staan AES-128.

Met gewone http kost het je als tussenpartij allemaal niks om iemand te te volgen en te tracken, als je bijvoorbeeld de router controleert (kan een advertentie-partij zijn), met https wordt het al snel een dure grap.

En ja, ik weet dat mensen gewoon op de "vertrouw deze site klikken", maar ik hoop toch niet dat ze dat doen op een rammelende wifi in een internetcafe in de rimboe.

[Reactie gewijzigd door Keypunchie op 3 maart 2020 19:09]

maar certificaten leveren nu juist veel op tegen allerhande zaken als phishing.
Certificaten doen helemaal niks tegen phishing, sterker nog, letsencrypt maakt het voor phishers alleen maar makkelijker om vertrouwd uitziende sites te maken.
Ook wat betreft privacy is het geen alomvattende oplossing, ook een "secure" https site kan met cookies en andere ongein je volgen.
Het beveiligt alleen tegen afluisteren van verkeer onderweg, meer niet.
Het beveiligt alleen tegen afluisteren van verkeer onderweg, meer niet.
En heel veel daarvan is met name privacy-gevoelig en dan gaat er niet om hoe sterk de encryptie is, maar puur *dat* hij er is.

Het punt hier is dat het versleutelen van de data zelf niet de kracht is, maar dat https ook afschermt welke pagina's je bezoekt.

Zo kan de host wel zien dat je en.wikipedia.org bezoekt, maar niet dat je bvb. en.wikipedia.org/wiki/1989_Tiananmen_Square_protests oproept.

De inhoud van die pagina zal bvb. de Chinese (of een andere autoritaire overheid) niet zo interesseren. Dat weten ze zelf ook wel.
Maar het feit dat je die pagina bezoekt, kunnen ze al iets van vinden over jou.
Certificaten doen helemaal niks tegen phishing,
Toegegeven., deze is iets minder sterk (en ligt ook aan je browser-implementatie) en ik zat meer met MitM-type aanvallen in mijn hoofd, maar een EV geeft in principe eigenaarschap informatie. Voor banksites wel zo prettig.

Al met al: HTTPS is zoveel meer dan alleen 'de gegevens moeten versleuteld zijn', zoals bvb. een password.

[Reactie gewijzigd door Keypunchie op 3 maart 2020 23:19]

Hoe zit dit bijvoorbeeld met Synology NAS apparatuur? Krijg je ook dan een mail? Of is dat te logisch? xD
Hoe zit dit bijvoorbeeld met Synology NAS apparatuur? Krijg je ook dan een mail? Of is dat te logisch? xD
Als je daar een adres heb achtergelaten, ja.
Maar wat let je om met de rechtermuisknop op een certificaat te klikken en renew te kiezen?
Da's erg handig in de Syno nassen.
Ah, je hebt helemaal gelijk. Is ook zo. Soms ga je zo op in een artikel dat je je opties vergeet xD
Een lastige kwestie. Aan de ene kant zijn het certificaten waarvan de geldigheid niet vast kan worden gesteld, aan de andere kant is het alleen maar een probleem voor domeinen die een CAA record hebben/hadden op het moment van aanvragen. Ook zijn een groot aantal van de getroffen certificaten niet meer geldig aangezien het probleem zich al sinds juni voordoet.

Nu zijn de eisen van het certificatenboerenforum natuurlijk hard; in zo'n geval moeten de certificaten worden ingetrokken. Aan de andere kant zijn er maar weinig websites die daadwerkelijk van een CAA-record hebben.

Het liefst had ik gezien dat alleen de certificaten waarvan nog een CAA record geldt zouden worden ingetrokken en dat de tooling niet alleen naar datum van verlopen kijkt, maar ook naar of het certificaat nog geldig is. Dit zal wellicht niet praktisch uitvoerbaar zijn.

Wel knap dat ze binnen 4 uur na het bevestigen van de bug hebben gereageerd, dat zouden meer certificaatboeren moeten doen!

[Reactie gewijzigd door GertMenkel op 3 maart 2020 19:04]

Men heeft tot vanavond de tijd in europa:

Q: When will the revocations start?
A: In order to complete revocations before the deadline of 2020-03-05 03:00 UTC, we are planning to start revoking affected certificates at 2020-03-04 20:00 UTC (3:00pm US EST). Please continue to renew and replace affected certificates in the meantime. If there are any changes to this start time, updates will be provided in this thread. Thank you all very much for your patience, understanding, and help as we work through this issue.
Vergeef men domheid maar ik vraag het alsnog.
Encryptie gebruiken we om een beveiligde verbinding op te zetten tussen client en server. bvb.

We kopen een certificaat van een Authorithy omdat zo en enkel zo alle browsers je website kunnen bezoeken waar die Authority ervoor zorgt dat je client vertrouwt dat de website die je bezoekt daadwerkelijk de site is die je dacht te bezoeken.

Plots komt er Let's encrypt. Geeft aan iedereen die interesse heeft een certificaat of die website nu te vertrouwen is of niet.

Wat is dan nog het nut van een website te beveiligen met encryptie? Neem nu tweakers en we hebben geen gebruikersnaam en wachtwoord om iets te posten( fictief ), dus we kunnen geen gegevens stelen. Wat is dan de meerwaarde van al die encryptie/decryptie handelingen? Om de provider en overheid geen inzicht te geven in de deelpagina's die bezocht worden?

En dan de hamvraag, hoe kan een organisatie al die kosten maken om certificaten gratis aan te bieden tot geautomatiseerd toe waar het eigenlijk om een erg lucratieve markt gaat.
In de raad van bestuur zitten alvast mensen van onder meer Facebook wat alvast mijn vertrouwen (daar ging het toch om) op de proef stelt.
En dan de hamvraag, hoe kan een organisatie al die kosten maken om certificaten gratis aan te bieden tot geautomatiseerd toe waar het eigenlijk om een erg lucratieve markt gaat.
Sponsors: https://www.abetterinternet.org/sponsors/ (ISRG is de moederorganisatie van Let's Encrypt. Let's Encrypt heeft volgens Wikipedia 13 mensen in dienst en een omzet van $3.6 miljoen. Dat zijn geen wereldschokkende bedragen.

Misschien bijzonder, maar zeker niet ongebruikelijk. Zeer, zeer veel open source software, open standaarden en andere open initiatieven wordt betaald door sponsoren. Linux (door Linux Foundation), Firefox (door Mozilla foundation), Unbound (door NLnet Labs), OpenSSL, ik bedenk er zo een paar. Ook Wikipedia (door Mediawiki foundation) is volledig betaald door sponsoren. Bij standardisatie soms ook: IETF (door ISOC), soms door membership fees, soms door een combinatie van beide (zoals bij W3C).
Inderdaad en laat dat nu net de kracht van het internet zijn: het volk geeft/heeft de macht door te sponseren...
"We do not charge a fee for our certificates. Let’s Encrypt is a nonprofit, our mission is to create a more secure and privacy-respecting Web by promoting the widespread adoption of HTTPS. Our services are free and easy to use so that every website can deploy HTTPS.

We require support from generous sponsors, grantmakers, and individuals in order to provide our services for free across the globe. If you’re interested in supporting us please consider donating or becoming a sponsor."

Daarnaast zegt een basis SSL certificaat niet of een website te vertrouwen is, maar dat de inhoud zeker niet veranderd is door een malafide persoon met een" man in the middle" aanval (voor bv. fake news, phising, virus injection etc) . Ze doen namelijk enkel aan domain validation (= is het iemand die toegang heeft tot het domein in kwestie, Ja? = OK). Ze doen geen extended of organization validation.

[Reactie gewijzigd door SmokingCrop op 3 maart 2020 22:14]

Wat is dan nog het nut van een website te beveiligen met encryptie? Neem nu tweakers en we hebben geen gebruikersnaam en wachtwoord om iets te posten( fictief ), dus we kunnen geen gegevens stelen. Wat is dan de meerwaarde van al die encryptie/decryptie handelingen? Om de provider en overheid geen inzicht te geven in de deelpagina's die bezocht worden?
Als je een website bezoekt om informatie te vergaren, dan wil je niet dat de data tussen de website en jou wordt aangepast en je dus verkeerde informatie tot je neemt.
Dat voorkom je door te weten met wie je communiceert en de data te versleutelen middels SSL/TLS.
Een certificaat doet eigenlijk twee dingen:

1. Het bewijst de identiteit van de website
2. Het versleutelt het verkeer tussen client en server

Punt 1 wordt ook bij Letsencrypt gegarandeerd. Het is niet zo dat iedereen een SSL certificaat voor bijvoorbeeld tweakers.net kan aanvragen bij Letsencrypt. Je kunt alleen certificaten krijgen voor domeinen die je of zelf host, of waarvan je de DNS zone beheert. Op die wijze controleert Letsencrypt of je de eirgenaar bent van het domein alsvorens het certificaat uit te geven.

Op dit item kan niet meer gereageerd worden.


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True