[JAVA] Client is able to connect to GRPC_TLS flight server with GRPC_INSECURE

[Thanzeel-Hassan-IBM]

Describe the bug, including details regarding any error messages, version, and platform.

Client is able to connect to GRPC_TLS flight server with GRPC_INSECURE

Even though the flight server was created with GRPC_TLS the client is able to connect with GRPC_INSECURE

Is this by design or is it a defect ?

Note that the Client is passing the correct client certificates.

The server is created like this :

Location location = Location.forGrpcTls("localhost", serverPort);
server = FlightServer.builder(allocator, location, new TestingArrowProducer(allocator))
        .useTls(certChainFile, privateKeyFile)
        .useMTlsClientVerification(caCertFile)
        .build();

server.start()

https://github.com/prestodb/presto/blob/f19fee9c66cc984b8b2cf09d610c0f212dc55713/presto-base-arrow-flight/src/test/java/com/facebook/plugin/arrow/TestArrowFlightMtls.java#L69

In this test case file, if we change this line from

.put("arrow-flight.server-ssl-enabled", "true")
to
.put("arrow-flight.server-ssl-enabled", "false")

the test cases still pass.

command to just run the test case : ./mvnw clean install test -pl presto-base-arrow-flight -Dtest=TestArrowFlightMtls
(this requires building presto before hand)

Component(s)

Java

[lidavidm]

Can you validate this with an http2 client like cURL? I think grpc-java may be negotiating TLS regardless

[haneel-kumar]

Hey @lidavidm, you are absolutely right. I've run the tests based on your suggestion, and it confirms that grpc-java is indeed negotiating a secure TLS connection regardless of the client-side arrow-flight.server-ssl-enabled=false flag.

Here is a summary of the test scenarios:

1. arrow-flight.server-ssl-enabled=true with valid certificates – ✅ Pass: Connection is secure and encrypted.

2. arrow-flight.server-ssl-enabled=true with tampered certificates – ❌ Fail: Connection is correctly rejected on certificate validation.

3. arrow-flight.server-ssl-enabled=false with valid certificates – ✅ Pass: Connection is secure and encrypted. The .useTls() call in the client builder overrides the insecure Location.

4. arrow-flight.server-ssl-enabled=false with tampered certificates – ❌ Fail: Connection is correctly rejected during the TLS handshake.

This confirms that Location.forGrpcInsecure has lower precedence, and the explicit .useTls() configuration on the builder forces a secure connection.

[lidavidm]

Can we close this then?

[elbinpallimalilibm]

Why is Flight client using a secure connection even if it uses Location.forGrpcInsecure? Isn't that misleading?

[lidavidm]

From what @haneel-kumar says, the client explicitly configures a certificate. So I'm not as surprised that TLS is being used as a result.

It's hard to tell what is going on here, because it sounds like a lot of this is actually Presto's configuration options. If there's an issue with the Arrow or gRPC code, it would help to provide a self-contained example using the Arrow APIs directly.

Also, since Arrow Flight is based on gRPC (which in turn is based on HTTP/2), we are likely just inheriting the behavior of gRPC which isn't necessarily fully under our control (and also why I've been recommending people use the APIs that directly expose gRPC to reduce confusion over what is being set).

[haneel-kumar]

So @lidavidm just to confirm, you're saying that even if Presto's config flag arrow-flight.server-ssl-enabled=false is set, it doesn't prevent the client from using TLS if it's explicitly configured via .useTls()

And this is likely the default behavior of gRPC, not something Arrow-specific. Is that right?

[elbinpallimalilibm]

@haneel-kumar

Can you provide a self contained example using just Arrow API's without any Presto code or configs involved?

[haneel-kumar]

Sure, @elbinpallimalilibm

I’ll put together a minimal, self-contained example using just Arrow Flight APIs (no Presto configs) to reproduce this behavior. Will share it here shortly.

[haneel-kumar]

Also @elbinpallimalilibm, just to confirm

I'm planning to preparing a minimal test using only Arrow Flight APIs, where:

• The server is started with .useTls() and Location.forGrpcTls(...), using self-signed certs.
• The client uses Location.forGrpcInsecure(...), but explicitly calls .useTls().

I hope this setup will demonstrates that a TLS connection is still be established, even with an "insecure" location, due to the explicit TLS configuration.

Is this the correct approach for testing the self-contained behavior you're referring to?

[elbinpallimalilibm]

Yes

[lidavidm]

Basically, it sounds to me like Presto is both using forGrpcInsecure and still providing a certificate via useTls. Is that correct?

In that case, you get whatever gRPC's behavior is (which apparently is to enable TLS). I'm not too keen on trying to override gRPC.

[haneel-kumar]

Yes, that’s right

Presto is using Location.forGrpcInsecure(...) and still calling .useTls() with the certificate.