feat(gax-httpjson): Add Post Quantum Cryptography (PQC) Support by default via Conscrypt - #13853
feat(gax-httpjson): Add Post Quantum Cryptography (PQC) Support by default via Conscrypt#13853lqiu96 wants to merge 69 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces Post-Quantum Cryptography (PQC) TLS negotiation for HTTP/JSON clients by integrating Conscrypt as a security provider and adding corresponding integration tests. The reviewer feedback focuses on improving the robustness and architecture of this implementation. Specifically, the reviewer recommends removing the undesirable coupling from the core HTTP module to the transport-specific module by defining the PQC groups locally. Additionally, the reviewer suggests wrapping the Conscrypt named groups configuration in a defensive try-catch block and separating the builder creation from the build calls to prevent genuine configuration or mTLS errors from being incorrectly swallowed as Conscrypt loading failures.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces Post-Quantum Cryptography (PQC) TLS negotiation support for HTTP/JSON clients by registering Conscrypt as the security provider and configuring default PQC named groups. The feedback suggests utilizing lazy initialization and caching for the Conscrypt security provider in both InstantiatingHttpJsonChannelProvider and HttpTransportOptions to prevent the performance and memory overhead of instantiating a new provider on every transport creation.
| private static final String[] PQC_GROUPS = | ||
| new String[] {"X25519MLKEM768", "SecP256r1MLKEM768", "X25519"}; | ||
| private static final HttpTransportFactory INSTANCE = new DefaultHttpTransportFactory(); |
There was a problem hiding this comment.
Prefer lazy initialization and caching for resource-intensive objects like the Conscrypt security provider. Creating a new Provider instance on every transport creation can lead to significant performance overhead and high memory usage.
We can introduce a static lazy holder class to cache the Conscrypt provider instance safely, ensuring it is only initialized once and does not cause class-loading issues if Conscrypt is not present on the classpath.
private static final String[] PQC_GROUPS =
new String[] {"X25519MLKEM768", "SecP256r1MLKEM768", "X25519"};
private static final HttpTransportFactory INSTANCE = new DefaultHttpTransportFactory();
private static class ConscryptProviderHolder {
private static final java.security.Provider INSTANCE = createProvider();
private static java.security.Provider createProvider() {
try {
return Conscrypt.newProvider();
} catch (Throwable t) {
LOG.log(
Level.FINE,
"Conscrypt native libraries not available. Falling back to JDK TLS.",
t);
return null;
}
}
}References
- Prefer lazy initialization over eager initialization for resource-intensive objects (such as CharsetEncoder) if they are not guaranteed to be used in all execution paths, to avoid unnecessary performance and memory overhead.
218f3e6 to
1a08829
Compare
| } | ||
| try { | ||
| Conscrypt.setNamedGroups(socket, DEFAULT_PQC_GROUPS); | ||
| } catch (Throwable t) { |
There was a problem hiding this comment.
Are there known checked exceptions? If not, catching Exception is fine but catching Throwable might hide larger problems. e.g. Even if a version mismatch is ignored here, it might blow up in other places.
There was a problem hiding this comment.
It doesn't throw any CheckExceptions. I'll change this so that it catches Exceptions instead. Online suggests the possibility of wrapped SSLSockets or proxied ones failing the Conscrypt check, but that seems to throw an Exception instead.
If there is a version mismatch of a JNI issue, that should be caught in the Conscrypt initializaiton logic and would be caught by the conscryptProvider == null check above.
| * | ||
| * <p>Returns {@code null} on failure so that transport creation can fall back to default JDK TLS, | ||
| * ensuring that setting Conscrypt as the default security provider does not cause breaking | ||
| * failures for customers running on environments where Conscrypt is unsupported or unavailable. |
There was a problem hiding this comment.
where Conscrypt is unsupported
What error would we run into?
There was a problem hiding this comment.
I'm not too sure. I think it's a linkage error but i'm not too familiar with native API logic as to which error message is thrown
There was a problem hiding this comment.
Do we want to catch linkage error though? Unless we know this could cause incompatible issues, I think catching Exception below makes more sense.
…qc-verification sample module
…streamline Conscrypt try-fallback
…rator in try block and remove draft Javadoc
…h blocks in GAX and Core HTTP
…pt is unavailable
…annelProviderTest
…n GAX and Core HTTP
…lProviderTest and HttpTransportOptionsTest
…t exception and restore HttpTransportOptionsTest to main
…ryptPqcConfiguratorHelper
…t classical non-PQC test case
…socket configurator
…Conscrypt log level to WARNING
…scrypt PQC fallback
…rHolder and comment catch block
…tProviderHolder Javadoc
…rypt to dependencies.properties
…core-http/pom.xml
…va/pom.xml properties
…gHttpJsonChannelProviderTest
…tQuantumCryptography
…eserve default SSLContext
…nsport.Builder without modifying global Security providers
…loud-java into pqc-httpjson-support
…_PQC_GROUP in header string
…Kyber768Draft00, MLKEM1024, and X25519
| public static final String[] DEFAULT_PQC_GROUPS = | ||
| new String[] {"X25519MLKEM768", "X25519Kyber768Draft00", "MLKEM1024", "X25519"}; |
There was a problem hiding this comment.
@blakeli0 Update the groups as I found out these are the MKLEM groups that Conscrypt supports: https://github.com/google/conscrypt/blob/44a36308a64e3f872192baabd7c3b5819dc618a2/CAPABILITIES.md?plain=1#L94-L96
| } | ||
|
|
||
| @Test | ||
| void testDefaultPqcGroups_containsExpectedGroups() { |
There was a problem hiding this comment.
This test is a duplicate of the same test in HttpJsonConscryptUtilsTest.
There was a problem hiding this comment.
Removing this test. I don't think it needs to be tested. Jetski added this in for coverage
|
|
||
| @Test | ||
| void testDefaultPqcGroups_containsExpectedGroups() { | ||
| assertThat(HttpJsonConscryptUtils.DEFAULT_PQC_GROUPS) |
There was a problem hiding this comment.
This test would always pass if we change a value in the group. We should use String literals for assertion.
There was a problem hiding this comment.
I don't think we need to test this. I'm going to remove this
| HttpJsonMetadata capturedHeaders = interceptor.metadata; | ||
| assertThat(capturedHeaders).isNotNull(); | ||
|
|
||
| String negotiatedGroup = getSingleHeaderString(capturedHeaders, TLS_GROUP_HEADER); |
There was a problem hiding this comment.
Cool, I don't see this showcase test reference it yet though. Also I don't think we should expose a field as public just for testing.
| * </ul> | ||
| */ | ||
| public static final String[] DEFAULT_PQC_GROUPS = | ||
| new String[] {"X25519MLKEM768", "X25519Kyber768Draft00", "MLKEM1024", "X25519"}; |
There was a problem hiding this comment.
I see this list is different from last time I reviewed. Is there a definitive list we can reference?
There was a problem hiding this comment.
Found after additional showcase testing. Conscrypt's list of supported algos
… matching for supported groups
…r future-proof JDK 27+ compatibility
… configuration is required for future JDK 27+ compatibility
…or supported groups containment and reduce DEFAULT_PQC_GROUPS visibility
…uantumCryptography comment
|
|




No description provided.