Implement opt-out for PQ TLS

[WillChilds-Klein]

Notes

Java CRT 0.39.3 enables and prefers PQ by default, so TLS_CIPHER_SYSTEM_DEFAULT now uses PQ cipher suites. The postQuantumTlsEnabled builder option in aws-sdk-java-v2 now becomes an opt-out mechanism; setting it to false explicitly disables PQ by using policy TLS_CIPHER_PREF_TLSv1_0_2023.

Testing

• updated unit test
• for "integration testing", i had Claude write a small test project that exercised three CRT client PQ configurations: default, enabled, disabled. i verified with wireshark that the expected keyshares were sent for each. i had to run this in a Linux container because the CRT doesn't yet support TLSv1.3 on MacOS, which is a prerequisite for PQ TLS.

$ ./run-docker.sh
...
========================================
   Post-Quantum TLS Configuration Test
========================================

----------------------------------------
Test: postQuantumTlsEnabled = DEFAULT (not set)
----------------------------------------
Creating AwsCrtHttpClient... ?
Creating KMS client... ?
Calling KMS ListKeys API... ?

Result: SUCCESS
  Keys returned: 4
  Expected cipher: TLS_CIPHER_SYSTEM_DEFAULT (PQ preferred by default since CRT 0.39.3)

----------------------------------------
Test: postQuantumTlsEnabled = ENABLED (true)
----------------------------------------
Creating AwsCrtHttpClient... ?
Creating KMS client... ?
Calling KMS ListKeys API... ?

Result: SUCCESS
  Keys returned: 4
  Expected cipher: TLS_CIPHER_SYSTEM_DEFAULT (PQ explicitly enabled)

----------------------------------------
Test: postQuantumTlsEnabled = DISABLED (false)
----------------------------------------
Creating AwsCrtHttpClient... ?
Creating KMS client... ?
Calling KMS ListKeys API... ?

Result: SUCCESS
  Keys returned: 4
  Expected cipher: TLS_CIPHER_PREF_TLSv1_0_2023 (PQ explicitly disabled/opted-out)


========================================
   ? ALL TESTS PASSED
========================================


===========================================
Test completed in Docker container

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[zoewangg]

Can we update the javadoc for postQuantumTlsEnabled? https://github.com/aws/aws-sdk-java-v2/blob/master/http-clients/aws-crt-client/src/main/java/software/amazon/awssdk/http/crt/AwsCrtAsyncHttpClient.java#L239

[zoewangg]

It seems this policy may get outdated in the future. Can we create a non-PQTLS default TLS policy that always uses the latest TLS versions?

[WillChilds-Klein]

Unfortunately we can't enforce a minimum TLS version higher than this due to some SDKs (IoT, some others) requiring TLS 1.0 support for the foreseeable future.

[zoewangg]

That's totally fine. I'm proposing creating a new TlsCipherPreference that always links to the recommended non-PQTLS preference, for now, it's TLS_CIPHER_PREF_TLSv1_0_2023, which may change in the future and when we change it, we just need to change CRT code and don't have to update the code in the SDK

[WillChilds-Klein]

understood, and i agree that's a useful abstraction. does this concern block the current PR? i'd be happy to take this up as a follow-on. it would require an upstream CRT change + release.