Potential issues with javax.crypto under StructuredTaskScope/JDK22

[Chris Marshall]

Hi Alan,

The code is completely unchanged between JDK21 and JDK22; it is using virtual threads and StructuredTaskScope in both cases (and also, via a different path, platform threads in both cases).

I should perhaps have given a bit more background about why I think that the crypto classes are at fault. The UserSRP auth class I linked to sends a message to AWS (via an AWS API, ultimately made as an HTTP call) which includes some information about the user. Amazon’s server responds (over HTTP) with a “challenge” which includes some pieces of information. Using those pieces of information plus knowledge of the password, the class I linked to derives an answer to the challenge, which is then sent (via HTTP) to AWS. AWS can verify that the response could only have been generated by someone with knowledge of the password, and they will respond with a valid bearer token, which can be used as an authorization header to HTTP calls (to our internal services, which can validate the bearer token). In this way, our services can communicate between themselves without any passwords ever being transmitted anywhere. In the following diagram, the arrows represent HTTP request/responses between us and AWS

  Us —-> (info) —> AWS

  Us <—- (challenge) <—- AWS

  Us —> (answer) —> AWS

  Us <— (bearer token | wrong user/pwd) <—- AWS

“Wrong username or password” indicates that the response calculated by the linked class is not correct.

I don’t believe (though I’m not an expert, so could be wrong) that this has anything to do with javax.security APIs

Chris

On 2 May 2024, at 19:59, Alan Bateman <Alan.Bateman at oracle.com> wrote:



On 02/05/2024 19:33, Chris Marshall wrote:
:

Last week I upgraded the application to be compiled by JDK22, and run on JDK22. Immediately, we started to see failures from within the User-SRP auth code only when it was run on a virtual thread from within a StructuredTaskScope. The failures are merely that the code appears to have calculated the wrong authentication response (i.e. AWS Cognito returns a message to the effect that we have the wrong username or password). It is not possible that this could be the case, because the same application, using the same username/password combo is able to successfully authenticate to AWS Cognito using User-SRP auth from a platform thread.

Thanks for reporting a potential issue.

You say that the code was running correctly on JDK 21. Was this in the context of virtual threads and using StructuredTaskScope? I'm trying to understand from your mail if you were using virtual threads with JDK 21 and whether you were using StructuredTaskScope in JDK 21 too.

"wrong username or password" hints that maybe this is some kinda of inheritance issue, I'm specifically thinking of the inherit access control context. Would it be possible to search the code and libraries that are in use here to see if they are using the javax.security.auth.Subject API? It's just a wild guess at this point but I think might give some clues as to where inheritance might be coming from.

-Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20240502/6d02ab3a/attachment.htm>