Forum / General Discussions / Cipher suite update: TLS 1.2 to 1.3 ?
Tagged: cipher suite TLS
- This topic has 7 replies, 3 voices, and was last updated 3 months ago by Britgirl.
-
AuthorPosts
-
August 20, 2024 at 14:18 #49269Steve92Participant
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 authenticationThanks.
Regards,
Steve.
August 21, 2024 at 15:16 #49277Steve92ParticipantHello,
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.
August 22, 2024 at 12:14 #49289BritgirlKeymasterHello, 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.
August 22, 2024 at 15:51 #49303Steve92ParticipantHello,
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.
August 23, 2024 at 16:14 #49341BritgirlKeymasterAt 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)August 26, 2024 at 13:16 #49359Steve92ParticipantHello,
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.
August 27, 2024 at 10:59 #49386BilbotineParticipantHello Steve92,
Thank you for your input !
August 30, 2024 at 16:21 #49475Steve92ParticipantHello,
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.
September 2, 2024 at 12:49 #49506BritgirlKeymasterThanks Steve, we’ve made a note of your feedback.
-
AuthorPosts
This topic was marked as solved, you can't post.