0

In a recent pentest (Java thick client), it was discovered by the pentesters that TLS version 1.3 is not supported. I'm investigating why it is not supported, so I was looking in the Java code for where TLS 1.3 is defined. However, someone told me that the TLS version is related to OpenSSL on the server itself, so it is not related to the Java code. But in Java code they only exclude old versions of TLS like 1.0 and 1.1 but they don't define which version of TLS. Is that true?

schroeder
  • 125,553
  • 55
  • 289
  • 326
ethicalhacker
  • 47
  • 6
  • 2
    The TLS versions usable by the client depend both on what is supported by the client and what is supported by the server. If the server can do TLS 1.3 but the client at most TLS 1.2 then at most TLS 1.2 is what you get. If the server side library is OpenSSL, SChannel, gnutls, SecureTransport, NSS, ... and what TLS versions are supported depends on the specific server implementation and configuration - there are many many options. – Steffen Ullrich May 26 '22 at 16:04
  • 2
    See [What exactly determines what version of SSL/TLS is used when accessing a site?](/questions/59367/), [How is the TLS version selected between client and server?](/questions/168390/) and other similar questions. – Steffen Ullrich May 26 '22 at 16:07

2 Answers2

2

is tls version related to server?

Yes, it is related to the server as well as the client. The client makes the first move in establishing the TLS connection.

If the client is trying to use TLS1.3, but the server does not support TLS 1.3 it will inform that client of this during the TLS handshake and the connection will proceed via TLS 1.2.

As suggested on this website, you can try connecting the client to tls13.akamai.io to see what version of TLS the client wants to use.

but in java code they only exclude old versions of tls like 1.0 and 1.1 but they don't define which version of tls, is that true?

There's lots of different "java code" out there. We don't know what code you are referring to.

On the client side, when you setup the TLS (or "SSL") socket, you can likely pass parameters, or if not you accept the default. You may need to figure out what version of Java you are using and whether that version even supports TLS1.3. If you are using Java 11 you have TLS1.3 support as do some versions of Java 8, but not Java 7.

The TLS connection starts with the ClientHello. If you need to treat the client as a "blackbox" you can tell if the client is attempting to use TLS1.2 or TLS1.3 by looking at the ClientHello, e.g., in Wireshark. Unfortunately, both TLS1.2 and TLS1.3 use the same "version number" (0x0303 indicating TLS1.2) for compatibility reasons. So, you have to look at the Supported Version Extension to see whether 0x0304 (TLS1.3) is listed. But, Wireshark will do this analysis for you.

In addition, you can use Wireshark to observer a connection between a modern client and your web server. You will likely see that the client tries a TLS 1.3 handshake, but the server forces TLS 1.2. Wireshark will label some packets of the TCP stream of the connection with TLS1.2 labels rather than TLS1.3 labels. Another way to see if TLS 1.2 is in use it to see if you can observe the Server Certificate during the handshake. If TLS 1.2 is in use you will be able to see the plaintext certificate, if TLS 1.3 is in use you will not be able to see the plaintext certificate.

Update:

In the above answer, I have been discussing client and server as if these are the only two computers involved in the data transmission process.

A commentator has requested a few words about TLS termination endpoints. This is a device that might, for example, sit in between a client and an HTTP server and perform decryption of HTTPS traffic before passing it on to the HTTP server.

The commentator suggests that if OP's Java server application is not a TLS termination point then the TLS configuration in Java on the server side is irrelevant. In this case OP should look at configuration of the TLS termination endpoint rather than the server application.

In general, there may be lots of different devices in between the client and the server. For example, a TLS termination device, or a load balancer, or a MITM proxy (used, e.g., by corporations to inspect work computer traffic) not to mention lots of switches and routers.

Devices that manipulate TLS such as TLS termination devices or TLS-MITM proxy devices can also cause TLS downgrade (e.g., from TLS1.3 to TLS1.2) and so if both the client and the server ostensibly want to use TLS1.3, but TLS 1.2 is still in use, the culprit might be one of these devices.

hft
  • 4,940
  • 17
  • 32
  • 3
    Nit: in 1.3 you won't be able to read the cert in wireshark _unless_ like me you have configured your browser to write SSLKEYLOGFILE and your wireshark to read it :-)) More seriously, recent JVMs (since last year) disable 1.0 and 1.1 _at the JVM level_ regardless of your application code (and SSL3 similarly since 2014). – dave_thompson_085 May 27 '22 at 00:13
  • The question is about **Java thick client**. Why are you writing about browsers? Your answer is not helpful. – mentallurg May 28 '22 at 00:33
  • Then I guess I don't understand the question. How about you write an answer? @mentallurg – hft May 28 '22 at 04:46
  • The OP says *"Java thick client"*. Means, it is not browser. In your answer, just remove the part related to browser. Focus on Java specifics. Explain, how TLS can be configured. – mentallurg May 28 '22 at 18:47
  • 1
    It is not an *abstract* question about how it TLS in general works. It is a question about *specific* case when both client and server are in Java. That's why your statement about what Chrome will try regarding TLS is *irrelevant* and *not helpful*. Instead, please focus on how *Java client* and *Java server* work with TLS. – mentallurg May 29 '22 at 13:53
  • @mentallurg I updated the answer. – hft Jun 01 '22 at 20:20
  • @hft: Looks good. Could you add a few words about TLS termination endpoint? – mentallurg Jun 01 '22 at 20:44
  • @mentallurg I added a bit about TLS termination. Basically just indicated that these can also be the culprit of TLS downgrade. – hft Jun 01 '22 at 20:55
  • @hft: I mean that the author seems not to understand that the Java server application is not a TLS termination point. That's why TLS configuration in Java on the server side is irrelevant. One should look at configuration of the TLS termination point. – mentallurg Jun 01 '22 at 21:07
0

You first have to understand the TLS-Handshake.

Video: TLS-Handshake - Youtube

Then you understand that both sides have an affect on which TLS Version is used for the connection.

The Client send the server a List of which TLS Versions it supports.

The Server decides which TLS Version will be used for the connection. It chooses the newest Version of the Clients List, which the Server itself supports.

In most cases the Server will support not only TLSv1.3 to support clients that aren't able to use TLSv1.3.

Example 1:

Server Supports       Client Supports
TLSv1.3               TLSv1.2
TLSv1.2               TLSv1.0

The Server selects TLSv1.2

Example 2:

Server Supports       Client Supports
TLSv1.3               TLSv1.2
                      TLSv1.0

A connection between the Client and the Server is not possible.

Example 3:

Server Supports       Client Supports
TLSv1.3               TLSv1.3
TLSv1.2               TLSv1.2

The Server selects TLSv1.2

Conclusion: You can influence the used TLS Version on both sides. But the Server is the decision maker. A malicious person could trick the server to use a lower Version of TLS by pretend it only supports TLSv1.0 even if it is capable of using a higher version. For this reason it is important to always stay up to date and disable older TLS Version on the Server side from time to time.

At this point of time (May 2022) it is pretty normal to have Servers support TLSv1.2 and TLSv1.3 side by side.

foshyboy
  • 11
  • 2
  • Is this applicable to Java thick clients? This appears to be general info on how web browsers go through this process. – schroeder May 28 '22 at 11:38
  • good question @schroeder. Actually my question is related to yours, in case of java thick client communicating with a server, for the encryption of communication, data is encrypted using tls, however what I have doubts about is, is the tls verison related to java? is it implemented with the java code? or it something purely related to the openssl installed on the server and java only uses it? – ethicalhacker May 30 '22 at 09:15
  • @ethicalhacker I edited your question to focus everyone on the Java aspect. I am not a Java expert, so I can't weigh in. But I am seeing people talk about browsers. – schroeder May 30 '22 at 09:46
  • I found this link: https://java.com/en/configure_crypto.html I think that java jdk has an embeded openssl which already has default tls configurations, so in this case it not dependent on the openssl installed on server but on the jdk installed on the server, right? – ethicalhacker May 31 '22 at 09:47
  • @ethicalhacker: no, JDK absolutely does not have 'embedded openssl' nor does Java-as-distributed ever use OpenSSL for anything, and what Java (JSSE) implements does depend on the Java version _and_ configuration/coding. However, _some_ otherwise Java-based servers notably Tomcat and things based on it like Wildfly DO have an option to use OpenSSL _instead of_ JSSE, via the Apache 'APR' library. I'm not aware of any client library that does, although it would be possible to create one. – dave_thompson_085 Jun 01 '22 at 23:53
  • but when using java to encrypt cummunications in tls for example I can see in a code how to exclude certain versions: supportedProtocols.remove("TLSv1.1"); so this excludes tls 1.1 from the default versions defined, but I'm still confused where are those default versions defined?! As far as I know, openssl on linux defines which tls versions the server can support, maybe there's something that I'm missing – ethicalhacker Jun 02 '22 at 08:04