Changeset 58cad21 in Klonkt for test

Timestamp:

08/19/2026 07:44:50 PM (3 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

598f090

Parents:

5869b1f

git-author:

Robin <roboburr@…> (08/19/2026 07:30:37 PM)

git-committer:

Robin <roboburr@…> (08/19/2026 07:44:50 PM)

Message:

OpenWebAuth: PKCS#1 v1.5 zelf uitpakken, met een grens op het aantal pogingen

Node weigert privateDecrypt met RSA_PKCS1_PADDING sinds de mitigatie voor
CVE-2023-46809 (Marvin). Daarmee was gastlogin stuk: vier tests rood, en
in bedrijf een geworpen TypeError midden in de inlogstroom.

De revert-vlag was geen uitweg. Die bestaat alleen op de lijnen 18/20/21
-- Node voegt een security-revert alleen toe aan wat ondersteund was toen
de fix kwam -- en 20 is sinds 30 april 2026 EOL. Node 22+ heeft hem nooit
gehad. FEP-61cf schrijft v1.5 voor, dus OAEP repareert de test en breekt
de interop met Hubzilla. Blijft over: het omhulsel zelf afhalen via
RSA_NO_PADDING.

Dat is precies het stuk dat de CVE veroorzaakte, dus met de zorg erbij:

• Geen vroege uitgang en geen worp. De scan loopt altijd het hele blok af. Dat is geen echte constant-time -- die krijg je in JavaScript met JIT en GC niet -- maar het haalt het waarneembare verschil weg.
• Implicit rejection: bij een ongeldig omhulsel een afgeleide waarde in plaats van een fout. DETERMINISTISCH, uit sleutel + ciphertext. Vers willekeurig zou slechter zijn: dezelfde ciphertext twee keer aanbieden gaf dan twee antwoorden, en juist dat verschil wilden we verbergen.
• Een teller van 20/uur op POST /magic, per SITE-SLUG want daar hangt het sleutelpaar aan. Hij telt ALLE pogingen, niet alleen de mislukte: een teller die alleen faalt meetelt is zelf weer een orakel, en dan staat de vertakking die we bij de ontsleuteling weghaalden aan de achterdeur terug. Een orakel heeft honderdduizenden pogingen nodig; twintig per uur is voor een mens onzichtbaar.

Onderweg bleek een aanname in de bestaande code niet te kloppen: het
commentaar bij decryptToken en bij de test leunden op OpenSSL's eigen
implicit rejection. Die kwam pas in 3.2; Node 20 brengt 3.0.19 mee en
daar WERPT hij. Die meting was dus op een andere machine gedaan dan waar
het draait. Nu maken we het zelf, dus de eigenschap staat vast ongeacht
de OpenSSL eronder.

Suite 1160/1160. Van de drie eigenschappen bijten er twee bij een
controleproef (de PS-ondergrens en het determinisme); de nep-uitkomst
niet, want de andere tak geeft dan een lege string die net zo goed
sneuvelt. Dat staat zo in het commentaar in plaats van dat ik doe alsof
alle drie dragend zijn.

Co-Authored-By: Claude Opus 5 <noreply@…>

Location:

test

Files:

• openwebauth.test.js (modified) (2 diffs)
• owa-decrypt-v15.test.js (added)

test/openwebauth.test.js

@@ -74 +74 @@
   assert.ok(!/[+/]/.test(versleuteld), 'en URL-veilig');
 
-  const terug = crypto.privateDecrypt(
-    { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING },
-    Buffer.from(versleuteld.replace(/-/g, '+').replace(/_/g, '/'), 'base64'),
-  ).toString('utf8');
+  // Door ONZE eigen uitpakker, niet rechtstreeks door crypto.privateDecrypt:
+  // die weigert PKCS#1 v1.5 sinds de mitigatie voor CVE-2023-46809, en de
+  // revert-vlag bestaat alleen op Node 18/20/21 -- allemaal EOL. decryptToken
+  // haalt het omhulsel zelf af en werkt dus op een Node die nog leeft.
+  const terug = OWA.decryptToken(versleuteld, privateKey.export({ type: 'pkcs8', format: 'pem' }));
   assert.equal(terug, token);
 
@@ -83 +84 @@
   // de voor de hand liggende toets (assert.throws) is hier fout.
   //
-  // PKCS#1 v1.5 gooit bij een verkeerde sleutel geen fout: OpenSSL 3 doet aan
-  // "implicit rejection" en geeft afgeleide onzin terug in plaats van te falen,
-  // juist zodat een aanvaller niet aan het foutgedrag kan aflezen of zijn gok
-  // klopte (Bleichenbacher/Marvin). Gemeten: 200 vreemde sleutels, 0 fouten,
-  // 200 keer bytes -- en 0 keer het token.
+  // Bij een verkeerde sleutel hoort er geen FOUT te komen maar afgeleide onzin:
+  // implicit rejection. Anders leest een aanvaller aan het foutgedrag af of zijn
+  // gok klopte (Bleichenbacher/Marvin).
+  //
+  // LET OP waar dat vandaan komt. OpenSSL doet dit pas zelf vanaf 3.2; op 3.0.19
+  // -- wat Node 20 meebrengt en wat wij draaien -- WERPT hij gewoon. Gemeten op
+  // 19-8-2026. Een eerdere versie van deze test ging uit van OpenSSL's gedrag en
+  // was daarmee afhankelijk van welke Node de meting toevallig deed. Nu maakt
+  // decryptToken de implicit rejection ZELF, dus de eigenschap staat vast
+  // ongeacht de OpenSSL eronder.
   //
   // De eigenschap die telt is dus niet "het knalt" maar "er komt iets anders
   // uit". Wat de home instance daarna terugstuurt matcht geen enkel opgeslagen
   // token, en de inlog mislukt gewoon.
-  const ruw = Buffer.from(versleuteld.replace(/-/g, '+').replace(/_/g, '/'), 'base64');
   for (let i = 0; i < 5; i++) {
-    const vreemde = crypto.generateKeyPairSync('rsa', { modulusLength: 2048 }).privateKey;
+    const vreemde = crypto.generateKeyPairSync('rsa', { modulusLength: 2048 })
+      .privateKey.export({ type: 'pkcs8', format: 'pem' });
     let uit = null;
-    try {
-      uit = crypto.privateDecrypt({ key: vreemde, padding: crypto.constants.RSA_PKCS1_PADDING }, ruw).toString('utf8');
-    } catch { uit = null; }                     // een fout mag, maar is niet de regel
+    assert.doesNotThrow(() => { uit = OWA.decryptToken(versleuteld, vreemde); },
+      'werpen is het signaal waar Bleichenbacher op draait');
     assert.notEqual(uit, token, 'andermans sleutel levert nooit het token');
   }