Steve92

[Steve92]

Yes, thanks, “–keyadd” works great !

It’s exactly what I was looking for: simple and supported by NoMachine.

🙂

[Steve92]

I’ve tested to add the public NX key of Cloud Server to Terminal Server to /var/NX/nx/.nx/config/autorized.crt (from memory).

“config” directory has to be created (with right permissions) if it’s the 1st node to be added. (Cat node..rsa.key.pub >>  /var/NX/nx/.nx/config/autorized.crt)

Please, could you confirm it’s OK ?

It seems to be OK but I want to be sure not to forget something.

Thanks !

Regards.

Steve

 

 

[Steve92]

Hello,

So, is it possible , with a profile , to propagate EnableDirectConnections=OFF to all nodes linked to a Cloud Cluster ?

If not, when will it be OK  ?

Thanks

Regards

Steve.

[Steve92]

Hello,

A few weeks ago, I had some problems too with ED25519 algorithm to generate keys and I thought it was not supported (hence my question https://forum.nomachine.com/topic/ed25519-algorithm-for-ssh-nx-keys ).

I’ve just done a test in full Linux environment, all is OK. (following https://kb.nomachine.com/AR02L00785)

On “!M Client” 8.14 side:

$ ssh-keygen -t ed25519               (-b is useless since fixed length key)

I kept default key names and added a passphrase.

The server is “!M Enterprise Cloud Server” 8.14.

FYI, ssh version :

$ ssh -V

OpenSSH_9.2p1
OpenSSL 3.0.14   4/6/2024

O/S:

Debian 12 Bookworm
Linux antix1 6.1.105
(super light Linux, perfect for testing !M in live VMs)

Good luck ! 🙂

NB: RSA 4096-bit key is still strong enough (even 3072-bit for common usage) !

Regards,

Steve.

[Steve92]

Hello,

Great news for the POC in progress !
It’s crucial for us to protect “!M Enterprise Desktops” settings.

An FR : (if I don’t need to change my glasses 😉 )

We need to give access to all Nodes only via Cloud Server.

I can’t see that “EnableDirectConnections” can be disabled by using a command line like :  nxserver --ruleadd --class propagation…

It is “ON” by default.

Could you confirm please ? Is this FR already registered ? How long will it take to add this FR ?

I guess we’ll have to deal with this need at firewall level… 🙁

Regards,

Steve.

[Steve92]

Hello,

“separating the web server host from the NoMachine server host ”

is a good thing but it is not enough for (very) sensitive environments.

“Protocol break” is a network protocol attack protection as described on this NCSC page :

Network protocol attack protection – NCSC.GOV.UK
https://www.ncsc.gov.uk/collection/cross-domain-solutions/using-the-principles/network-protocol-attack-protection

In our case the risk occurs if a user, from a low security domain, has a remote access to a server in a high level security domain.

We must have strong protection against an attacker who might use the components within NoMachine as a route to compromise the core network.

NCSC :”A protocol break will terminate one transmission path, extract the relevant information, and use this to initiate a new transmission path.”

So the question is : what happens in the black box “nxhtd & nxwebplayer” between the 2 components ?

Is there a network session break ?
Is there a “rewriting” of data or just an “as-is” forwarding ?

Please, could you forward these hard questions to a cybersecurity expert in your teams in labs ?

Thanks,

Regards,

Steve.

[Steve92]

Hello,

If multiple screens are used, only one UDP port is used ?

how can it happen ?

In our case, only one remote UDP port would be open instead of a range !

In what case can it bring problems ? Give examples please.

Thanks !

Regards,

Steve.

[Steve92]

Hello,

And what about server side (destination machine) ?

No way to cleanly uninstall  “NoMachine Service” ?

Manual start must not be allowed in our case.

Is there a dirty way like removing files (binary file… )? Which one ?

The aim would be to have only the admin console on “!M Cloud Server”.

Is it possible ?

Thanks.

Steve.

[Steve92]

Hello,

I read again the page “Use Your Own Apache Web Server…”.

If I well understand the chain of components is:
[ Browser ] <= HTTPS => [ nxhtd ] <= ? => [ nxwebplayer ] <= NX/SSH => [ nxserver ]
Is it correct ? If not, what is the right one ?

How [ nxhtd ], the web server, communicates (protocol, port) with [ nxwebplayer ], the web app. ?

Must [ nxhtd ] and [ nxwebplayer ] be on the same machine ?

Thanks,

Regards.

Steve.

[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.

[Steve92]

I found these 2 very interesting links :

NoMachine – How To Configure A NoMachine Server V. 6 Or Later To Connect Web Sessions On Localhost Or On Different Hosts – Knowledge Base

NoMachine – Use Your Own Apache Web Server To Run NoMachine Sessions On The Web – Knowledge Base

but I had a quick look (too quick?) at this guide

NoMachine – NoMachine Enterprise Desktop – Installation And Configuration Guide – Knowledge Base

and I didn’t find a way to install only nxhtd on VM_A and only nxd on VM_B.

How can we proceed ? Is there an installer allowing to choose what component we need to install on each machine ?

Thank!

 

Steve.

 

[Steve92]

Thank you for this quick answer.

Do you have an official document describing the differences between !M web player and native client ?

Is copy/paste possible in both directions ? For any content or only text ?

I can’t wait to have my test environment and begin the POC… 😉

[Steve92]

Hello

This link deals with reasons for new technical choice and performances but what about features and look and feal from the user side ?

Are there UI differences  depending on the used protocol (NX, SSH, HTTPS) ?

…or is it actually imperceptible ?

I’ve heard from a previous user of NoMachine v6 things like “Connecting from a browser to NoMachine Enterprise Desktop gives terrible performances ! Impossible to copy/paste… “.

I would like to have your opinion before I can test IRL.

Thanks !

Steve.

[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.

[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.

[Author]

Posts