When a client application connects to TIBCO Data Virtualization (via ODBC, Power BI, etc.) one can see the enabled and disabled SSL protocols in the cs-server.log, however, the same is not the case with the cs_studio.log when the Studio connects to the TIBCO Data Virtualization Server. This is because the ExcludeProtocols and EnableProtocols entries only exist on the SSL Server side. So the below entries can only exist in cs_server.log when the Server is restarted, this entry is not present in the cs_studio.log.

-------------------------
INFO [DbChannel-RequestSelectThread] 2021-09-06 17:59:37.091 +0530 SecurityUtil - Setting enabled SSL protocols to [TLSv1.3, TLSv1.2]

INFO [main] 2021-09-06 18:02:32.212 +0530 CompositeServer - Setting excluded SSL protocols for Jetty HTTPS connector to [SSLv2Hello, SSLv2, SSLv3, TLSv1, TLSv1.1]
-------------------------

Also, one can see the TLS version negotiation between other clients and the TIBCO Data Virtualization Server in the cs_server.out or cs_monitor.out by enabling SSL tracing from the below path:

Studio > Administration > Configuration > Server > Communications > Generate SSL Diagnostics (On Server Restart) to True

Below is an example that illustrates how to check the TLS version when a client (CURL) connects to the TIBCO Data Virtualization Server:

- Publish a resource as a web service. For e.g. publish the view 'ViewOrder' which is found under the examples folder.
- Turn Studio > Administration > Configuration > Server > Communications > Generate SSL Diagnostics (On Server Restart) to True
- Restart the TDV Server.

(1) Open CMD and use the curl utility to consume the REST web services:
----------------------------
curl -k -X GET -u admin:<password> -H "Content-Type: application/json" https://<hostname>:9802/xml/SSL-Test/ViewOrder
----------------------------

- Open cs_monitor.out file and could see what TLS version the client is sending:
----------------------------
INFO   | jvm 1    |   "client version"      : "TLSv1.2",
INFO   | jvm 1    | javax.net.ssl|DEBUG|01 2B|jetty thread pool-299|2021-09-13 16:08:26.685 IST|ClientHello.java:836|Negotiated protocol version: TLSv1.2
----------------------------

- Open cs_server.log and could see that for TDV 8.4 the enabled entry is also there:
----------------------------
INFO [DbChannel-RequestSelectThread] 2021-09-13 13:38:28.840 +0530 SecurityUtil - Setting enabled SSL protocols to [TLSv1.3, TLSv1.2]
----------------------------

The client and the server negotiates to decide what TLS version will be used. In the below example the client sends the signal to the server to use different TLS versions, if the client and the server both support the TLS version then they agree to connect over the TLS version.

(2) Pass command-line flags to specify the TLS version (TLS v1.2)
----------------------------
curl --tlsv1.2 -k -X GET -u admin:<password> -H "Content-Type: application/json" https://<hostname>:9802/xml/SSL-Test/ViewOrder
-----------------------------

- Open cs_monitor.out file and see what TLS version the client is sending:
----------------------------
INFO   | jvm 1    |   "client version"      : "TLSv1.2",
INFO   | jvm 1    | javax.net.ssl|DEBUG|01 2B|jetty thread pool-299|2021-09-13 16:08:26.685 IST|ClientHello.java:836|Negotiated protocol version: TLSv1.2
----------------------------

Hence, TLS v1.2 is used as an SSL protocol.

(3) Pass command-line flags to specify the TLS version (TLS v1.3)
----------------------------
curl --tlsv1.3 -k -X GET -u admin:<password> -H "Content-Type: application/json" https://<hostname>:9802/xml/SSL-Test/ViewOrder
-----------------------------

Did not return the result and popped up the below message:
-----------------------------
curl: (35) Schannel: TLS 1.3 is not yet supported
-----------------------------

Since TLS 1.3 is not supported by the CURL. They both will negotiate on TLS 1.2 instead of TLS 1.3

However, these logs do not help to determine the TLS version negotiation between the TIBCO Data Virtualization Studio and the TIBCO Data Virtualization Server.

This article explains how to check the TLS version when the TIBCO Data Virtualization Studio communicates with the TIBCO Data Virtualization Server. This article also provides the steps to check the TLS version for other client tools as well.

All supported environment

To see the protocol negotiation between the Studio and the Server, one may follow the below steps:

1. Open a command line and go to <TDV_Studio_Installation>/bin 
2. Execute studio.bat -debugssl (or studio.sh -debugssl)
3. This would initiate the TDV Studio and will print out the SSL message, one can see the communication between studio and server.
4. The ClientHello message will contain the initial TLS version, however, the ServerHello message will respond server preferred TLS version.

----------------------------------------------
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "60 7A C3 9C 28 17 EF 32 2C DA DB 6A D3 B3 B7 C9 B6 71 2A 89 96 20 A7 5F 1A 3B 9F 7A 5D E3 A9 5E",
  "session id"          : "79 AF 47 B1 F5 C1 93 68 CC F3 B5 4F 0D B6 78 B9 36 2E AF 3F 50 6A 31 6F 57 C0 CA 0D 8E B1 2D 42",
  "cipher suites"       : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]"
----------------------------------------------

----------------------------------------------
"ServerHello": {
  "server version"      : "TLSv1.2",
  "random"              : "9F 7B 81 AC 8B 0F F4 5F E1 18 3C 70 8F 3F 6D 1F 70 A9 77 29 EB 43 A2 C4 76 17 99 AB 1D 67 63 AC",
  "session id"          : "79 AF 47 B1 F5 C1 93 68 CC F3 B5 4F 0D B6 78 B9 36 2E AF 3F 50 6A 31 6F 57 C0 CA 0D 8E B1 2D 42",
  "cipher suite"        : "TLS_AES_128_GCM_SHA256(0x1301)",
  "compression methods" : "00",
  "extensions"          : [
    "supported_versions (43)": {
      "selected version": [TLSv1.3]
    },
    "key_share (51)": {
      "server_share": {
        "named group": secp256r1
        "key_exchange": {
          0000: 04 DD D1 FB C7 7B 78 74   3D 0C C6 81 1F 34 32 98  ......xt=....42.
          0010: DB C4 8E 97 B6 4D 5C 83   0D CF EE EC B8 60 CB A4  .....M\......`..
          0020: CF 2B 4B B3 4C 46 D7 EB   D3 9E A6 7D 05 4C 5E 92  .+K.LF.......L^.
          0030: 82 7D F1 5E 57 A7 43 D0   1C AD 6B 1C 7D 97 6F 1C  ...^W.C...k...o.
          0040: 89
        }
      },
    }
  ]
}
----------------------------------------------

5. It will use TLS v1.2 first and then if the server responds by saying “I prefer TLS v1.3”, it will use TLS v1.3 later. ("selected version": [TLSv1.3])

NOTE:
1. The default TLS version will default to the highest supported version that is negotiated between TDV and Studio (Examples: Java 8 defaults to TLS v1.2 and Java 11 defaults to TLS v1.3).
2. TDV 8.2 and above now use Java 11 which defaults to TLS v1.3
3. In the above example, the TIBCO Data Virtualization v8.4 is used.