Cipher suite update: TLS 1.2 to 1.3 ?

[Steve92]

Hello,

Is ‘ECDHE-RSA-AES128-GCM-SHA256’ (TLS 1.2) still the default cipher suite used by NoMachine 8.13.x ?

It is quite old (8/2008).

When do you plan to update it to TLS v1.3 that mainly provides :

– Stronger encryption
– Faster connections
– Improved privacy
– Stronger authentication

Thanks.

Regards,

Steve.

[Steve92]

Hello,

I read the last releases of NoMachine (>=8.12.12,  July 2024) includes OpenSSL v3.0 that supports TLS 1.3 (in fact supported since OpenSSL v1.1.1).

Why TLS 1.3 could not be used ?

This page seems to be out of date:

NoMachine – Encryption In NoMachine – Knowledge Base

Could you clarify this ?

Thanks !

Steve.

[Britgirl]

Hello, thanks for pointing out the articles, we’ll be checking them to make sure they are updated. About TLS, version 1.2 still is a reliable and widely used standard in the corporate world, Of course, whilst it’s obviously favourable to use the latest version, the move to TLS 1.3 is something we are already working on, as low priority.

[Steve92]

Hello,

Thanks for this quick answer.

So the the article is up-to-date until you validate TLS 1.3.

“…the move to TLS 1.3 is something we are already working on, as low priority” means it could be available in about 6, 12 months, …more?

According to our National Cyber Security Agency, TLS 1.3 is highly recommended but TLS 1.2 is still acceptable, only if right extensions are contained in ClientHello at the beginning of a session.

Please could you give me the list of TLS extensions used in ClientHello by NoMachine ?

Thanks !

Steve.

[Britgirl]

At the moment it’s not possible for us to indicate a time-frame. Right now our priority is NoMachine 9.

We can tell you the Client Hello Extensions, though we would be interested in knowing why you are asking. We use the very minimum to support our case. It’s not the purpose of NoMachine to implement an extensible TLS system, but to implement NoMachine. If there is an extension that is not included, and which you consider a requirement, please tell us what it is and we can evaluate whether to add it.

Extension Type: 0x000A (supported_groups)
Extension Type: 0x000B (ec_point_formats)
Extension Type: 0x000D (signature_algorithms)
Extension Type: 0x0016 (encrypt_then_mac)
Extension Type: 0x0017 (extended_master_secret)

[Steve92]

Hello,

Thanks a lot for these precise infos.

I have to make a RFI (before POC) on 2 or 3 solutions of remote desktop for sensitive and complex environments.

Security is indeed a major point of the evaluation.

So ANSSI (French  National Cyber Security Agency) recommendations must be taken into account in our case.

Sources: in compliance with IETF publications

2020 FRENCH https://cyber.gouv.fr/publications/recommandations-de-securite-relatives-tls

2017 ENGLISH (quite old!) https://cyber.gouv.fr/en/publications/security-recommendations-tls

In a nutshell :

*** NOT RECOMMENDED ***

ec_point_formats (0x000B) [57]

This extension reports the elliptic curve point formats supported by the client or server (if any). It is indeed possible to represent elliptic curve points in a compressed form. In the absence of this extension, it is expected that the point coordinates are transmitted in their entirety. The use of this extension has been made obsolete by the IETF, indicating that only the uncompressed format should be supported [73].

[57] S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk et B. Moeller, « Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) », RFC 4492, IETF, May 2006.

[73] Y. Nir, S. Josefsson et M. Pegourie-Gonnard, « Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier », RFC 8422, IETF, August 2018.

*** GENERAL RECOMMENDATION ***

signed_certificate_timestamp, ou sct (0x0012) [23]

Only if SCT.

[23] B. Laurie, A. Langley et E. Kasper, « Certificate Transparency », RFC 6962, IETF, June 2013.

*** RECOMMENDATIONS for  TLS  V1.2 ***

renegotiation_info (0xFF01) [60]

The renegotiation mechanism originally designed for TLS versions less than or equal to 1.2 exposes the client to a protocol vulnerability. It is indeed possible for an attacker to pass off a client’s first negotiation as a renegotiation. The attacker is thus in a position to inject application data that the server attributes to the legitimate client. The renegotiation_info extension was defined in order to perform secure renegotiations. Using this extension requires preserving the protected content of the Finished messages used to authenticate the last handshake.

[60] E. Rescorla, M. Ray, S. Dispensa et N. Oskov, « Transport Layer Security (TLS) Renegotiation Indication Extension », RFC 5746, IETF, February 2010.

 

Other specific cases are considered in the document (the more recent one is in French only).

Regards,

Steve.

[Bilbotine]

Hello Steve92,

Thank you for your input !

[Steve92]

Hello,

To summarize, according to ANSSI (French National Cyber Security Agency) and IETF, for TLS 1.2, only the following extensions should/must be used:

Extension Type: 0x000A (supported_groups)
Extension Type: 0x000B (ec_point_formats)
Extension Type: 0x000D (signature_algorithms)
Extension Type: 0x0016 (encrypt_then_mac)
Extension Type: 0x0017 (extended_master_secret)

PLUS

signed_certificate_timestamp (0x0012) …. if SCT used
renegotiation_info (0xFF01)

Regards,

Steve.

[Britgirl]

Thanks Steve, we’ve made a note of your feedback.

[Author]

Posts