What version of TLS is supported by the Ledger API?

It seems if I configure the SslContext to use TLS v1.3 I cannot connect to the Ledger API, at least not the Sandbox.

I used the following Java code to create the context:

GrpcSslContexts.forClient()
            .protocols("TLSv1.3")
            .trustManager(caCrt.toFile())
            .keyManager(clientCrt.toFile(), clientKey.toFile())
            .clientAuth(ClientAuth.REQUIRE)
            .build();

The exact same configuration works if I set the protocol to "TLSv1.2".

Am I right assuming we only support TLS v1.2?

I’ve never seen this to be honest, what is the error exactly?

It’s simply a connection refused on my end:

Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/0:0:0:0:0:0:0:1:6865
Caused by: java.net.ConnectException: Connection refused

And if you just change the argument of .protocols() to "TLSv1.2" or remove it completely it works, right?

Exactly. This is my test code:

import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;

import com.daml.ledger.rxjava.DamlLedgerClient;
import io.grpc.netty.GrpcSslContexts;
import io.netty.handler.ssl.ClientAuth;
import io.netty.handler.ssl.SslContext;
import java.nio.file.Path;
import java.nio.file.Paths;
import javax.net.ssl.SSLException;
import org.junit.jupiter.api.Test;

public class TlsTest {
  private static final Path EXAMPLES = Paths.get("examples", "tls");

  @Test
  void tls3() throws SSLException {
    Path caCrt = EXAMPLES.resolve("ca.crt");
    Path clientCrt = EXAMPLES.resolve("client.crt");
    Path clientKey = EXAMPLES.resolve("client.key");
    SslContext sslContext =
        GrpcSslContexts.forClient()
            .protocols("TLSv1.3")
            .trustManager(caCrt.toFile())
            .keyManager(clientCrt.toFile(), clientKey.toFile())
            .clientAuth(ClientAuth.REQUIRE)
            .build();
    DamlLedgerClient ledgerClient =
        DamlLedgerClient.newBuilder("localhost", 6865).withSslContext(sslContext).build();
    assertDoesNotThrow(ledgerClient::connect);
  }
}

So, the Ledger API per se of course is not bound to any limitation in terms of TLS (I’m sure you know this, I’m mostly leaving this here for other readers).

Our implementation uses Netty underneath, that as @cocreature made me notice recently added TLS 1.3 to the list of recommended ciphers for HTTP2 (which is the transport protocol ultimately used by gRPC).

@cocreature actually upgraded Netty in a PR today, so this should no longer be a problem, I’ll quickly run a test to see whether that’s the case.

I agree, the question is misleading. Would it be better to say: “Does current version of daml-on-postgresql support TLSv1.3”? Still ambiguous?

It’s not really a problem, I’m sure the vast majority of readers can easily pick up the difference, I was writing for a few less technical readers who might want to follow along.

The short answer is that this is no longer a problem, the longer answer is that I’m making sure we have a test case for this. Thanks for raising the issue!

And here it is.

To sum it up: current implementation of daml-on-postgres does not support TLSv1.3, it will come in a future (probably the next) release. Is this correct @stefanobaghino-da?

Exactly.