Custom SSLParameters break HTTP/2 over HTTPS

[laeubi]

Custom SSLParameters break HTTP/2 over HTTPS

Setting .sslParameters() overrides HttpClient's internal ALPN configuration, forcing HTTP/1.1 fallback even when explicitly setting application protocols:

// This does NOT work - still falls back to HTTP/1.1
SSLParameters params = new SSLParameters();
params.setApplicationProtocols(new String[] {"h2", "http/1.1"});

HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .sslParameters(params)  // Overrides ALPN, breaks HTTP/2
    .build();

// Workaround: only set sslContext
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .sslContext(customSslContext)  // OK
    .build();

Demonstrated with this testcase:

java-http-client/src/test/java/io/github/laeubi/httpclient/JavaHttpClientUpgradeTest.java

Lines 75 to 116 in 16f7312

	@Test
	@DisplayName("HTTP/2 with Custom SSLParameters (attempting ALPN)")
	public void testHttp2WithCustomSSLParametersALPNAttempt() throws Exception {
	logger.info("\n=== Testing HTTP/2 with Custom SSLParameters (attempting ALPN) ===");
	// Create custom SSLParameters that attempt to preserve ALPN protocols
	SSLParameters sslParameters = new SSLParameters();
	// Disable hostname verification for testing with self-signed certificates
	sslParameters.setEndpointIdentificationAlgorithm(null);
	// Explicitly set ALPN protocols to support HTTP/2
	// NOTE: This demonstrates a limitation - setting custom SSLParameters
	// overrides HttpClient's internal ALPN configuration
	sslParameters.setApplicationProtocols(new String[] {"h2", "http/1.1"});
	HttpClient client = HttpClient.newBuilder()
	.version(HttpClient.Version.HTTP_2)
	.connectTimeout(Duration.ofSeconds(10))
	.sslContext(createTrustAllSslContext())
	.sslParameters(sslParameters)
	.build();
	HttpRequest request = HttpRequest.newBuilder()
	.uri(getHttpsUrl())
	.GET()
	.build();
	logger.info("Sending HTTPS request with custom SSLParameters to {}", getHttpsUrl());
	HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
	logger.info("Response status: {}", response.statusCode());
	logger.info("Response version: {}", response.version());
	logger.info("Response body: {}", response.body());
	assertEquals(200, response.statusCode(), "Expected 200 OK response");
	// This currently documents a bug in the JDK see
	// https://github.com/laeubi/java-http-client/issues/6
	assertEquals(HttpClient.Version.HTTP_2, response.version(),
	"Custom SSLParameters override HttpClient's ALPN configuration, " +
	"causing fallback to HTTP/1.1 even when protocols are explicitly set");
	assertNotNull(response.body(), "Response body should not be null");
	logger.info("=== Custom SSLParameters test completed - demonstrates ALPN limitation ===\n");
	}

the test fails with:

JAVA Version: 21.0.9+10-LTS
expected: <HTTP_2> but was: <HTTP_1_1>

[vy]

@laeubi, thanks so much for the report. @djelinski was kind enough to investigate the issue – see JDK-8371887.

[djelinski]

Thanks @laeubi for a great write-up, The problem here was that the HttpClient is expecting TLS protocol versions in the SSLParameters object to be set. I'll try to remove the expectation. Meanwhile you can replace new SSLParameters() with sslContext.getDefaultSSLParameters() (substitute your own sslContext) to work around the issue.

Note that this will not solve your other problem: any null value in SSLParameters means "not set", not "remove this value", so using setEndpointIdentificationAlgorithm(null) will not do what you expect it to do.

Disabling hostname verification is not needed to work with self-signed certificates. A better alternative involves setting the SubjectAltName extension in the self-signed certificate. If you create your own self-signed certificates using a recent-enough openSSL version, it's as easy as adding -addext "subjectAltName = DNS:localhost, IP:127.0.0.1" to your openssl req or openssl x509 command.

HttpClient ignores the application protocols configured in SSLParameters.

[laeubi]

@djelinski thanks for looking into this. I think we can see this as an example to show the issue rather than a real world usage and i just came across this while looking into a completely different topic but though it would be good to report.