[MRESOLVER-579] Fix overwrite of SSLParameters in JDK HTTP transport when securityMode is "insecure" #529
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have been experimenting with Maven 4.0.0-beta-3, specifically testing its HTTP/2 support. During my tests, I used a self-signed certificate for the testing repository and disabled TLS validation. This approach produced unexpected behavior. While TLS certificate validation was indeed disabled as expected, it also caused the ALPN extension to be omitted from the Client Hello message.
To further investigate, I added the self-signed certificate to the JDK's cacerts keystore and removed the insecure option. With this configuration, ALPN support was restored, and HTTP/2 worked correctly again. This behavior can lead to problems if the server prioritizes HTTP/2 or does not support HTTP/1.1.
This change addresses an issue where SSLParameters were being overwritten (introduced in 08f102a), causing the loss of multiple TLS extensions, including ALPN and SNI. Setting the
aether.transport.https.securityMode=insecure
property disables TLS validation but also inadvertently disabled ALPN and SNI.Now, SSLParameters are derived from SSLContext defaults to ensure proper handling of these extensions, even when TLS validation is disabled in JDK HTTP transport.
TODOs:
https://issues.apache.org/jira/browse/MRESOLVER-579