Validate tls connections to controller and worker

Boundary
1

For auditing reasons, I’m trying to prove that my controller and worker connections are using tls1.3.

According to the Boundary docs, the controller and worker don’t use standard PKI.

When I attempt to determine what tls it’s using, I run:

nmap --script ssl-enum-ciphers -p 9201 internal.url -PnsV
Starting Nmap 7.92 ( https://nmap.org ) at 2024-03-14 18:30 UTC
Nmap scan report for internal.url (10.10.0.10)
Host is up (0.0018s latency).
rDNS record for 10.10.0.10: ip-10.10.0.10.us-gov-east-1.compute.internal

PORT     STATE SERVICE
9201/tcp open  wap-wsp-wtp

Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds

I would expect to see something like the following in the output:

PORT    STATE SERVICE
9201/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

So, my question is, is there a way to prove tls versions being use by the controller and worker?

2

We use standard TLS; it’s the certificates and private keys that are per-session.

If you wanted to do it manually you’d need to pass in the ALPN/NextProtos value of a valid session ID, because that value is used to look up the per-session cert chain to use. Alternately I can point you to the client code specifying TLS 1.3 only (if you use our clients) and the worker code specifying TLS 1.3 only.