Potential issues with javax.crypto under StructuredTaskScope/JDK22

[Chris Marshall]

Thanks for this great suggestion. The answers are the same, so it looks like my original premise is incorrect, and there are no issues with javax.crypto classes running in JDK22 on virtual threads.

The remaining possibility is that the AWS client JAR, which is a thin layer atop a REST API backend, does not work properly with JDK22 when used via a StructuredTaskScope on a virtual thread.

Apologies for wasting go everyone’s time here.

Chris

> On 2 May 2024, at 21:50, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> Can you try recording the challenge and the answer in each round and then recalculate them in a plain single thread standalone program to verify if the answers are still the same? (Hopefully this calculation is deterministic).
> 
> --Weijun
> 
>> On May 2, 2024, at 4:18 PM, Chris Marshall <oxbow_lakes at hotmail.com> wrote:
>> 
>> 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
>>> 
>>> 
>