Wel netjes dat ze dit gewoon volgens de regels melden. Het lijkt onbetekend maar het versterkt het vertrouwen in de zorgvuldigheid van een CA

Weinig computers hebben een klok die zo nauwkeurig is.

(daarom ntpupdate installeren)

Slordig. En netjes gereageerd...

Mijn God! Hebben die certificaatverstrekkers niets nuttigers te doen als dit? Valt me mee dat ze niet het rootcertificaat waar ze op zitten hebben ingetrokken. Dit is immers zeer ernstig en brengt miljoenen websites in gevaar.

Het geeft inderdaad een goede indruk. En niet melden zou een slechte indruk gegeven hebben.

Er wordt soms wel misbruik gemaakt van die perceptie - hypercorrect de kleinste dingen melden , maar een grote zaak 'vergeten' (of die sneeuwt onder in de vloed van kleine frutsels ).

Op een ietwat andere manier : de term 'bike shedding' is waarschijnlijk bekend.
https://en.wiktionary.org/wiki/bikeshedding
(enorm lang discuzeuren over minimale details (materiaal/kleur van een fietsenstalling) en daarna in twee minuten een beslissing van 100M nemen ) .
Een ervaren vergaderaar zou bewust eerst enkele 'bikeshed' onderwerpen kunnen agenderen, waarna een heikel punt makkelijk erdoor geduwd kan worden .

Als ik https://bugzilla.mozilla.org/show_bug.cgi?id=1715672 lees, lijken er ook mensen te zijn die vinden dat alle letsencrypt certificaten gerevoked moeten worden. Dat zou wat zijn...

Zeikers hierop letten, maar stug doorgaan met die amazon cloud, zodat de vs lekker makkelijk illegale letsencrypt certificates kan gebruiken voor de mim.
En de domme massa is meteen weer verblindt/gemanipuleert met de schijn kwaliteit.

Vreemd, want dan zou je juist verwachten dat hij 1 seconde tekort was. Dat niemand hierboven daarover valt.

In het originele verhaal van Let's Encrypt staat dat deze begin en eindtijd niet meetellen.


De toevoeging 'inclusive' houdt in dat ook de exacte tijden uitgesloten moeten worden.

Denk dat het probleem van origine was begonnen bij de terminologie 'date', waar een programmeur misschien aannam dat een geldigheid van 1 dag dan 2x dezelfde datum krijgt. Om een nul-count te verhelpen werd bijvoorbaat één seconde bijgeteld.

De resolutie om 1 seconde minder dan 90 dagen te tellen is eigenlijk ook in principe incorrect.

De date-timestamps hebben voldoende precisie om exact op de seconde te evalueren.

(geneuzel in de marge)

ter verduidelijking met die laatste zin bedoel je: "not before 12:00 and not after 13:00, inclusive" -->

[12:00 <------->13:00] (inclusive) en dus niet [12:00 <----> 12:59] (exclusive).

Want dat betekenen de termen inclusive en exclusive namelijk. Inclusief de genoemde minuut. Of exclusief de genoemde minuut.

Ehh illegale certificates? Leg uit... Het staat er nogal zwaar. Dan is een verduidelijking wel op zijn plaats vind ik.

Moeilijk te lezen artikel, wat er nou precies bedoelt word.


Maar ze hebben het juist wel gedaan en dat is fout:

In hun definitie hebben ze gezegd geldigeheid van 2160 uur. (laten we even 1 uur zeggen voor de het gemak)

In omschrijving hebben ze ervolgens gezegd: niet voor 12 uur en niet na 13 uur, inclusive. Dat werd dus vervolgens berekend als:
[12:00, 12:01, 12:02, ... , 13:00] (inclusive).

Maar 1 uur is 60 minuten. En [12:00, 12:01, 12:02, ... , 13:00] (inclusive) is 61 minuten.

Wat ze hadden moeten doen is: [12:00, 12:01, 12:02, ..., 12:59] (inclusive) want dat zijn 60 minuten.

Het wordt trouwens nog wat "lastiger" omdat ze in hun RFC de komma vreemd hebben staan:


Het is namelijk inclusief de eerste seconde, en exclusief de laatste seconde. Dat is altijd weer lastig bij programmataal omschrijven in spreektaal. Omdat je van 0 tot 1 ook meetelt. Mensen tellen in spreektaal niet vanaf 0, maar vanaf 1. En da's weer gelijk aan de eeuwige array discussie. Moet je starten vanaf 0 of vanaf 1. Er zijn programeertalen die zeggen:

myArray = ["a","b","c"] lees je uit als myArray[1], myArray[2], myArray[3].

Maar de meeste programmeertalen zeggen:

myArray = ["a","b","c"] lees je uit als myArray[0], myArray[1], myArray[2]. (Waarom eindig ik op 2 als er 3 elementen in zitten? Redelijke vraag want in spreektaal niet logisch)

De impact van deze fout is trouwens nog minimaler dan wordt verteld. Als je Let's Encrypt instelt zoals wordt aangevolen, dan laat je certbot elke dag draaien. Certbot kijkt of certificaten vernieuwd moeten worden. De geldigheid van certificaten is 90 dagen. Maar certbot begint met het vernieuwen van certificaten na 60 dagen. Dus 30 dagen voor tijd.

Certbot documentatie https://certbot.eff.org/docs/using.html?highlight=renew :

Dus als mensen Let's Encypt installeren zoals dat wordt aanbevolen, dan krijgen ze nooit met deze fout te maken. En ook al zouden ze dat niet doen. Ik krijg van Let's Encrypt keurig ver voor het eindigen van de geldigheid van mijn certficaten een mailtje als dat nog niet in die 30 dagen voor tijd gebeurd is. Dus wil men last krijgen van deze fout moet met a) Let's Encrypt niet installeren zoals wordt aanbevolen. b) waarschuwingen negeren die Let's Encrypt geeft. c) zelf geen maatregelen hebben genomen die de geldigheid van je certificaten checkt.

Zelf heb ik een monitor-progje lopen die keurig dagelijks let's encrypt certificaten checkt die bij al onze klanten zijn geinstalleerd. Mocht er ergens iets falen (en een cerificaat 1 week voor eind nog niet vernieuwd is) omdat een of andere lokale sysadmin certbot uit de crontab heeft gegooid, krijg ik in ieder geval in een Slack channel een bericht.

En ja ik heb het meegemaakt: "Ik ken ik niet, ik ben te beroerd om op te zoeken wat het is, ik ben ook te beroerd om aan de installateur van de server te vragen wat het is, ik comment het gewoon uit of verwijder de regel, en ik zie wel wat er gebeurt" en een dag later denken: "zie je wel de server draait nog en piept niet, was dus niet nodig, laat ik het nu vergeten en verder gaan met mijn leven."

Die seconde is op zich totaal onbenullig. Toch zegt dit nieuwsbericht iets belangrijks.

Bij implementatie van encryptiesystemen doen alle details ertoe, kleine foutjes kunnen tot grote beveiligingslekken leiden. Voor CA's geldt dat nog eens in het kwadraat, omdat er ongelofelijk veel afhankelijk is van hoe goed zij hun werk doen. Daarom moet je van CA's verwachten dat ze extreem pietluttig zorgen dat alle details tot in de puntjes kloppen, en zich niet permitteren dat ze iets overslaan vanuit de inschatting dat een detail in de praktijk niet belangrijk is. Juist dat soort inschattingen kunnen enorme blunders opleveren in dit soort systemen. De houding die je van een CA wil is daarom niet dat ze pragmatisch om probleempjes heen navigeren maar dat ze principieel elke onvolkomenheid die zich aandient corrigeren, geen uitzonderingen maken en daar volkomen dogmatisch in zijn.

Dit bericht laat dat soort dogmatisme zien, en voor een CA is dat precies de houding die nodig is. Die fout van een seconde op zich is onbenullig, hoe ze ermee zijn omgegaan is juist in de verste verte niet onbenullig, en daarom is dit nieuws.

Nee. Dit is waar zij voor zijn. Hiertoe zijn zij op aard, om certificaten te verstrekken en daarin nauwkeurig te zijn. Dit is hun taak. Ze houden zich niet bezig met het bestrijden van ziekten of het oplossen van oorlog en geweld, daar zijn ze niet voor, dat kunnen ze niet, dat doen ze niet. Ze signen certificaten, punt, en te lang is te lang. De impact van 1s te lang is nihil, dus meer doen dan wat ze gedaan hebben lijkt me inderdaad overbodig, maar het is netjes en zorgvuldig dat ze het gemeld hebben, want te lang is te lang. Een paspoort met een geldigheidsduur van 10 jaar is 1 dag na het verlopen ook ineens ongeldig. Hetzelfde gaat op voor jouw creditcard, om maar eens wat te noemen.

Als je roept "hebben ze niets nuttigers te doen", wat bedoel je dan? Wat voor anders nuttigs zouden ze moeten doen? Wat verwacht je dat ze doen, wat zou je willen? Is het een oproep aan de mensen van LetsEncrypt om de toko op te doeken en zich om te scholen tot bejaardenverzorger of zo? Ze doen precies en exact datgene dat ze moeten zijn: nauwkeurig en precies zijn bij de uitgifte van certificaten.

@Reinder: Ik ben maar eens gaan kijken naar de RFC in het artikel. Om te kijken of er een verplichting was voor certificaatverstrekkers om alle certificaten 7775999 seconden geldig te laten zijn om ze te laten werken met andere computers. Maar ik kwam iets veel interessanters tegen.

Namelijk dat SSL 1.0 uit ~1995 niet millenniumproof was! En we zijn ondertussen al een paar versies verder dus misschien is het nuttig niet al te veel energie in kleinigheden te steken die de werking van encryptie niet aantasten. En ons te concentreren op echte fouten in de software die we gebruiken en die de werking wel aantasten en het internet onveilig maken.

Anoniem 19:05

Gezien de definitie van "validity period" in RFC 5280 zijn Let's Encrypt certificaten 90 dagen + 1 seconde geldig. Er is uiteraard geen enkele regel die dat verbiedt. Maar in v3.2 van hun CPS (Certification Practice Statement) stond bij DV-SSL End Entity Certificate Validity Period "90 days". Daardoor waren de uitgegeven certificaten strijdig met het CPS en was er formeel sprake van een incident. Dat heeft ISRG (de organisatie achter Let's Encrypt) netjes gemeld. Technisch is het uiteraard een totaal non issue.

Ze hebben het probleem opgelost door het CPS aan te passen. In v3.3 (geldig vanaf 8 juni 2021) staat er "Less than 100 days".

Dat is a) veel redelijker en bedachtzamer geformuleerd, zonder dat schreeuwerige "zomg wtf hebben ze niets beters te doen!!", waarvoor mijn dank en complimenten, en b) totaal niet relevant. Let's Encrypt gaf certificaten uit voor X + N seconden, terwijl ze volgens de specificaties waaronder ze die certificaten uitgaven slechts geldig mochten zijn voor X seconden. Of N nu 1 seconde is of 1 jaar is niet zo relevant: het was te lang, en dus hebben ze dat opgelost en gemeld. Het al of niet y2k compliant zijn van verouderde specificates waar Let's Encrpyt niets mee doet maakt verder niet uit.

Vraag: Als je het onzinnig acht om het te melden als de door hen uitgegeven certificaten 1 seconde te lang geldig waren, vanaf hoeveel seconden vind je dan dat ze het wel hadden moeten melden? Wat als ze 10s te lang geldig waren, wat had je dan gezegd? en 1 uur? 1 dag? 1 week? 1 maand? Als ze van de specificiaties die ze zelf zeggen te hanteren zouden moeten afwijken, wie bepaald dan op basis waarvan wat dan wel te lang is? Als je zegt "1 dag mag", waarom dan wel 24h en niet 24h plus 1s ? Of dan toch stiekem ook wel want het is maar 1s? Dit is waarom die specificaties er zijn, en daar hebben ze zich heel netjes aan gehouden, en dat sterkt het vertrouwen in die partij die vertrouwen als meest belangrijke dienst heeft.

Ik geloof dat dat is wat mijn leraar Nederlands een hyperbool noemde.


Wat als N 0 is? Of mag N alleen een natuurlijk getal van 1 en hoger zijn?


Van mij hoeft er helemaal geen verloopdatum te zijn. Dit was met PGP 2.x ook niet zo.

Dit is uit RFC 1991:
Volgens sommige hardcore cypherpunks, waaronder ikzelf, is PGP 2.6.3i nog steeds de veiligste versie van PGP. Alleen al omdat het zo weinig sourcecode betreft. De algoritmes die gebruikt worden zijn natuurlijk helemaal ruk en het is 16 bit, dus het draait niet op een 64 bit processor. Maar als je nog een 8086 computer met MS-DOS 6.22 hebt staan... Ik denk dat je Grapperhaus daar wel hoofdpijn mee zou kunnen bezorgen. De FBI vond deze versie ook niet leuk.

Anoniem 19:05