Describe the feature
I'd like to be able to the MinTlsVersion parameter for the AWS CRT HTTP client when creating service clients (Sync/Async).
something like
AwsCrtHttpClient.builder().minTlsVersion(TlsContextOptions.TlsVersions.TLSv1_3).build()
Use Case
Following requirements from https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography to use the latest version of TLS:
Control: ISM-1139; Revision: 6; Updated: Mar-22; Applicability: All; Essential Eight: N/A
Only the latest version of TLS is used for TLS connections.
We are in the process of restricting all our S3 buckets Resource policy with the s3:TlsVersion condition to enforce 1.3 on the server side (S3). We also want to start enforcing all egress TLS conections from our clients so that, in the unlikely event of a MITM attack, the protocol cannot be downgraded by the attacker between the client and the attacker and will only work with TLS v1.3.
Proposed Solution
effectively, we could add a new options to the Client Builder to pass the TLS Version, which will be used in https://github.com/aws/aws-sdk-java-v2/blob/master/http-clients/aws-crt-client/src/main/java/software/amazon/awssdk/http/crt/AwsCrtHttpClientBase.java#L79-L83 to set the TLSContext object used in the connection.
Other Information
For now, we are comparing the risk/benefits of using the Apache HTTP Client which supports TLS v1.3 but is slower than CRT.
Local tests environments:
- Java17 (17.0.12)
- AWS-SDK-Java v2 (2.27.6) (transitive dependency to aws-crt-java 0.30.6)
Reported User-Agent in CloudTrail with the CRT Client:
[aws-sdk-java/2.27.6 Mac_OS_X/15.0 OpenJDK_64-Bit_Server_VM/17.0.10+7-LTS Java/17.0.10 vendor/Amazon.com_Inc. io/sync http/AwsCommonRuntime cfg/retry-mode/legacy cfg/auth-source#sso ft/s3-transfer]
This negotiated TLSv1.2 with S3 (CloudTrail report tlsdetails.tlsverison field), while the exact same test using the Apache HTTP Client reported TLS 1.3.
I am slightly surprised that even with the SYSTEM default TLS negotitation, it only negotiated TLS v1.2 with S3.
Acknowledgements
AWS Java SDK version used
2.27.6
JDK version used
17.0.12
Operating System and version
Mac_OS_X/15.0
Describe the feature
I'd like to be able to the MinTlsVersion parameter for the AWS CRT HTTP client when creating service clients (Sync/Async).
something like
Use Case
Following requirements from https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography to use the latest version of TLS:
We are in the process of restricting all our S3 buckets Resource policy with the
s3:TlsVersioncondition to enforce 1.3 on the server side (S3). We also want to start enforcing all egress TLS conections from our clients so that, in the unlikely event of a MITM attack, the protocol cannot be downgraded by the attacker between the client and the attacker and will only work with TLS v1.3.Proposed Solution
effectively, we could add a new options to the Client Builder to pass the TLS Version, which will be used in https://github.com/aws/aws-sdk-java-v2/blob/master/http-clients/aws-crt-client/src/main/java/software/amazon/awssdk/http/crt/AwsCrtHttpClientBase.java#L79-L83 to set the TLSContext object used in the connection.
Other Information
For now, we are comparing the risk/benefits of using the Apache HTTP Client which supports TLS v1.3 but is slower than CRT.
Local tests environments:
Reported User-Agent in CloudTrail with the CRT Client:
This negotiated TLSv1.2 with S3 (CloudTrail report tlsdetails.tlsverison field), while the exact same test using the Apache HTTP Client reported TLS 1.3.
I am slightly surprised that even with the SYSTEM default TLS negotitation, it only negotiated TLS v1.2 with S3.
Acknowledgements
AWS Java SDK version used
2.27.6
JDK version used
17.0.12
Operating System and version
Mac_OS_X/15.0