Rocket Uniface upgrades secure TLS connections to a minimum of TLS v1.2
Rocket Uniface has made the conscious decision of upgrading the internal network security, all TLS connections between server and client are upgraded to use TLS v1.2 only. This is considered the industry standard. Uniface always attempted to use TLS v1.2 and, if unavailable, fall back to older versions. Older versions of TLS, v1.0 and v1.1, are now considered unsafe, and are being gradually deprecated and removed from commercial software. We have chosen to deprecate this functionality in Uniface, starting from 10.4.02.012.
If necessary you can still utilize these old protocols. There is also a new option to prevent TLS from renegotiating the connection. Read below to learn more.
Background: What it TLS?
TLS (Transport Layer Security) is a protocol that allows users to communicate privately. The goal of TLS is to encrypt the conversations between the client and server. By doing so, any malicious third parties are unable to eavesdrop into their conversation, or tamper the data while they're being transferred.
TLS versions
TLS is the successor of SSL (Secure Socket Layer). SSL 1.0, 2.0, and 3.0 have long been deprecated (2015) and the preferred protocols are now TLS.
TLS v1.0 was introduced in 1999, as an upgrade of SSL 3.0. TLS v1.1 was introduced in 2006, as an updated version of TLS v1.0.
Today, TLS v1.0 and v1.1 are considered unsafe. They are currently deprecated by multiple large scale organizations. Examples include Apple, Google, Microsoft, and Mozilla, who announced simultaneously that they will deprecate TLS 1.0 and 1.1 in March 2020 (1). The NSA agency also suggests that all secure connections with TLS 1.0 and 1.1 are considered unsafe, and should not be permitted (2).
TLS v1.2 was introduced in 2011. It is the most widely used protocol today with an adaptation well over 95%. The old MD5 and SHA1 hashes used by v1.0 and v1.1 were replaced with the more secure SHA256. Hashes encrypted with MD5 or SHA1 can often be decrypted, rendering TLS 1.0 and 1.1 unsafe.
The most recent TLS version is v1.3. It was introduced in 2018. This version is not widely implemented, and has a very low adaptation. Many browsers and operating systems are not yet equipped to use this protocol. Support for TLS v1.3 was first added to Schannel with Windows 11 and Windows Server 2022. Due to the above reasons, Rocket Uniface does not support this protocol yet.
Why are we updating our TLS policy?
We have chosen to deprecate TLS v1.0 and v1.1 on our TLS driver, starting with version 10.4.02.012, due to the reasons stated above. We have taken a conscious decision to keep older versions available if a legacy network or operating system cannot support TLS v1.2. The legacy TLS protocols are deprecated, but not removed.
What are the risks of using legacy TLS protocols?
The integrity of both TLS v1.0 and TLS v1.1 depend on a running SHA-1 hash of the exchanged messages. It is possible to break the handshake protocol by performing 2^77 operations, which is well below the acceptable modern security margin. Similarly, the authentication of the handshake depends on signatures made using a SHA-1 hash or a not appreciably stronger concatenation of MD5 and SHA1 hashes, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash. Neither TLS v1.0 nor TLS v1.1 allow the peers to select a stronger hash for signatures in the ServerKeyExchange or CertificateVerify messages, making the only upgrade path the use of a newer protocol version. (2)
What is the renegotiation vulnerability?
After the initial secure connection has been made, it is possible to renegotiate some of its parameters without dropping the connection.
The renegotiation can be client-initiated, which can be secure or insecure. The most problematic is the client-initiated insecure renegotiation. The safer option is that the renegotiation is server-initiated, which can be secure or insecure again, as the client-side renegotiation carries inherent risks. (3)
There are two potential cyber attack scenarios related to the SSL/TLS renegotiation (3):
- A Man-in-the-Middle (MITM) attack (injection vulnerability) that inserts malicious data (plain text can be inserted as a prefix to a TLS connection) into HTTPS sessions through an unauthenticated request (CVE-2009-3555). By doing this, the attacker may run commands with the credentials of an already authorized user and even gather other users’ credentials.
- A Denial of Service condition starts hundreds of handshakes from clients for the same TCP connection, abusing the fact that a secure SSL connection is 15 times more power-heavier for servers than for clients.
Does Uniface support insecure renegotiation?
Uniface does not support unsafe legacy renegotiation. Unsafe legacy Hello messages are not supported either. This means that any renegotiation happening in Uniface is secure from MITM attacks(4). Uniface only supports secure renegotiation. Some users like to turn off all kinds of renegotiation, both secure and insecure, so we're adding a new option for them.
New Uniface parameters
We have added 2 new parameters in our TLS Driver settings, as well as in the network profiles.
min_tls_version = {1.0 | 1.1 | 1.2} can be used to select the lowest supported TLS version. It has a default value of 1.2 - meaning that unless overridden with this setting, the application will only use TLS v1.2 or higher. Currently, TLS v1.2 is the highest available protocol.
Example: Setting this parameter to 1.1 will allow secure connections with TLS v1.1 or higher. TLS v1.1 will only be used when TLS v1.2 is not available, or when a cipher has been specified in the cipher_list that is incompatible with TLS v1.2.
renegotiation = {yes | no} can be used to disable all kinds of renegotiation. Uniface only supports secure renegotiation, and will keep using it by default. However, some security audits will still warn users about all renegotiation types - both secure or insecure. This option will allow users to turn off renegotiation and pass those security tests.
Example in ASN file
[DRIVER_SETTINGS]
;These are the default TLS parameters
USYS$TLS_PARAMS = verify_server=yes, ca_certificate=usys:certificate.crt
[NET_SETTINGS]
;This is a network profile, that overrides the minimum TLS version to support 1.0 or higher, and also disables renegotiation.
Profile_1 = verify_server=yes, ca_certificate=usys:certificate.crt, min_tls_version=1.0, renegotiation=no
Sources:
(1) https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/
(2) https://datatracker.ietf.org/doc/pdf/draft-ietf-tls-oldversions-deprecate-09.pdf
(3) https://crashtest-security.com/secure-client-initiated-ssl-renegotiation/
(4) https://www.ibm.com/docs/en/sdk-java-technology/8?topic=provider-transport-layer-security-tls-renegotiation-issue