You may come across a situation where you have configured your 14.1.06 DSA with 'protocol=tlsv12' in order to communicate only in TLS 1.2 while in reality you have noticed that the 'test connection' and/or actual connection to DSA via an application is using TLS 1.3. Your organization is not prepared to use TLS 1.3 yet and you want to force the DSA to only accept TLS 1.2 protocol for communication.
Even if you attempt to control the TLS 1.3 related ciphers in the 'cipher' parameter list, it is still not being blocked.
e.g. You tried setting:
cipher = "kEDH:ALL:!aNULL:!eNULL:!ADH:!DES:!3DES:!LOW:!MEDIUM:!EXP:!EXPORT40:!RC4:!SSLv2:+HIGH:@STRENGTH:!SHA:!TLS_AES_256_GCM_SHA384:!TLS_CHACHA20_POLY1305_SHA256:!TLS_AES_128_GCM_SHA256"
While running 'get ciphers;' from the DXconsole, you still get (see the top three lines below):
> [20] get ciphers;
> [20] TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
> [20] TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
> [20] TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
> [20] ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
> [20] ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
> [20] DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
> [20] DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
....
....
What you are seeing is by design. Starting version 14.1.06, TLS 1.3 is the highest protocol that is being supported. This cannot avoided neither any of the TLS 1.3 related ciphers can be disabled.
The solution is to work on the application side so that it only sends TLS 1.2 protocol when communicating with the DSA.
e.g. if you are using Apache Studio version 2.0.0.v20210717-M17 along with latest JAVA/JRE version (e.g. 24.0.2).
In this combination, TLS 1.2 and 1.3 protocols are being sent to the server (as part of Client Hello) and your DSA by design supporting TLS 1.3, it honors that as the highest version of TLS supported.
What 'protocol=tlsv12' setting means is the fact that the DSA will accept minimum of TLS 1.2 protocol. If anything higher is presented, it will use that for communication.
In the above example, you have to modify the 'java.security' file for JAVA/JRE version that you are using to add TLSv1.3 in the disabledAlgorithms list.
i.e.
What you have is:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
Change that to:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, TLSv1.3, RC4, DES, MD5withRSA, \
Once done, from here on, Apache Directory Studio will not send TLS 1.3 protocol to DSA forcing it to use only TLS 1.2
Additional Google search will also give some useful information on this. Such as:
Apache Directory Studio, being an Eclipse RCP application and a tool for interacting with LDAP servers, inherently supports TLS 1.2 for secure connections. This support is generally provided by the underlying Java Runtime Environment (JRE) used by the application.
To ensure Apache Directory Studio utilizes TLS 1.2 when connecting to an LDAP server:
JRE Configuration:
Verify that the JRE used by Apache Directory Studio is configured to prioritize or exclusively use TLS 1.2. This often involves ensuring that older, less secure TLS versions (like TLS 1.0 or 1.1) are disabled or de-prioritized within the JRE's security settings.
LDAP Connection Settings:
When configuring an LDAP connection within Apache Directory Studio, ensure you are using the secure LDAP port (typically 636) and selecting the "SSL/TLS" or "StartTLS" option, depending on how the LDAP server is configured for secure communication.
Server Configuration:
The LDAP server itself must be configured to support and offer TLS 1.2 for secure connections. Apache Directory Studio will negotiate the highest common TLS version supported by both the client (Apache Directory Studio's JRE) and the server.