René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"webcrypto: valid AES-GCM decrypt aborts (errors->Empty()) after tls.connect() with an undeserializable session (v24.x)","articleBody":"**Version:** v24.22.2 (also v16–v24 tested); not reproducible on v26.13.0\n**Platform:** macOS arm64 (Darwin 25.6.0); OpenSSL 3.5.9\n\n**What steps will reproduce the bug?**\n\n```js\n// repro.mjs — run: node repro.mjs\nimport tls from 'node:tls';\nimport { webcrypto } from 'node:crypto';\nconst { subtle } = webcrypto;\nconst key = await subtle.importKey('raw', new Uint8Array(32), 'AES-GCM', false, ['encrypt', 'decrypt']);\nconst iv = new Uint8Array(12);\nconst ct = await subtle.encrypt({ name: 'AES-GCM', iv }, key, new Uint8Array([1, 2, 3]));\n// A session buffer in the v24 serialized format whose DER payload is not a valid SSL_SESSION.\nconst session = Buffer.from(\n  '006e6f64656a733a746c733a73657373696f6e3a31000014676174657761792e6578616d706c652e746573746d6f636b65642073657373696f6e',\n  'hex',\n);\nconst socket = tls.connect({ host: '127.0.0.1', port: 9, servername: 'gateway.example.test', session });\nsocket.on('error', () => {});\nsocket.destroy();\nawait subtle.decrypt({ name: 'AES-GCM', iv }, key, ct); // aborts here\nconsole.log('ok');\n```\n\n**What is the expected behavior?** `ok`. A failed session deserialization should not affect an unrelated, valid WebCrypto operation.\n\n**What do you see instead?**\n\n```\n# node[...]: v8::Maybe\u003cbool> node::crypto::CipherJob\u003cnode::crypto::AESCipherTraits>::ToResult(...)\n#  Assertion failed: errors->Empty()\n```\n\nThe process is terminated with `SIGABRT`.\n\n**Additional information**\n\n- `TLSWrap::SetSession` → `GetTLSSession` → `d2i_SSL_SESSION` fails and leaves the error on the JS thread's OpenSSL error queue. No `ClearErrorOnReturn` or `MarkPopErrorOnReturn` is used there (`// TODO(tniessen): figure out error handling`).\n- In `v24.x`, `CipherJob::ToResult` runs `if (errors->Empty()) errors->Capture();` on the JS thread and then `CHECK(errors->Empty())` on success. The stale error is captured into a successful job, and the process aborts.\n- In `v26.x`, `ToResult` no longer captures the queue, so the abort does not happen. Would that change be a candidate for a backport to v24.x (LTS)?\n- Separately, should `SetSession` clear or pop the error queue when deserialization fails?\n- In practice this was triggered by a test HTTP interceptor that emits fake TLS sessions, which undici then reuses (see the `mswjs/interceptors` report). Any stale OpenSSL error on the JS thread would have the same effect.\n","author":{"url":"https://github.com/webteamfrit","@type":"Person","name":"webteamfrit"},"datePublished":"2026-11-02T15:27:50Z","url":"https://github.com/nodejs/node/issues/67203"}