AlinsRan opened a new pull request, #13889: URL: https://github.com/apache/apisix/pull/13889
### Description `jwe-decrypt` decrypts the token with no additional authenticated data: ```lua local decrypted, err = aes_default:decrypt(dec(o.ciphertext), dec(o.tag)) ``` [RFC 7516 §5.1](https://datatracker.ietf.org/doc/html/rfc7516#section-5.1) makes the encoded protected header the AES-GCM AAD for compact serialization, so every JWE library computes the tag over it. A token from a compliant producer therefore never authenticates and is rejected with `400 failed to decrypt JWE token`, even though the key, IV and ciphertext are all correct. Reproduced against master with a token generated by python `cryptography` (`AESGCM(key).encrypt(iv, payload, aad=protected_header)`): the identical token with the tag computed without AAD is accepted, the compliant one is rejected. This PR tries the RFC 7516 form first and falls back to decrypting without AAD, so tokens generated the way APISIX itself used to generate them — including the one in the plugin documentation and everything produced by the `/apisix/plugin/jwe/encrypt` endpoint removed in #13464 — keep working. Authenticating the header also makes `kid` tamper-proof for compliant tokens: swapping it breaks the tag even when the two Consumers share a secret. It also rejects a header that asks for an `alg` or `enc` the plugin does not implement (only `dir` / `A256GCM` are), instead of letting it fail later as a decryption error. Tokens that omit either field keep working, and a token that names another algorithm cannot decrypt today anyway, so no working configuration changes. Trade-off worth naming: a legacy token now costs two GCM operations instead of one, since the AAD attempt runs first. ### Checklist - [x] I have explained the need for this PR and the problem it solves - [x] I have explained the changes or the new features added to this PR - [x] I have added tests corresponding to this change - [x] I have updated the documentation to reflect this change - [x] I have verified that this change is backward compatible Tests: TEST 26 accepts an RFC 7516 token produced by an independent library, TEST 27 pins the legacy no-AAD token, TEST 28 shows a `kid` swap on a compliant token is rejected across Consumers sharing a secret, TEST 29/30 cover the unsupported `alg` / `enc`. TEST 26, 29 and 30 fail on master. Note: this touches `jwe_decrypt_with_obj()`, the same function as #13844; whichever lands first, I will rebase the other. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
