The NoMachine Security Statement is intended to provide information for redacting Privacy Impact Assessment documents in accordance to GDPR rules.

NoMachine client-server architecture
NoMachine adopts a client-server architecture where clients (either NoMachine client or browsers) connect to the server. There's no-man-in-the-middle of any kind.

Data traffic protection, communication protocols and encryption protection
Data transmission is always encrypted using end-to-end encryption. NoMachine supports three types of connection protocol:

NX protocol (default)
The NX protocol is proprietary and closed source. Traffic is protected using Public Key Cryptography provided by OpenSSL TLS/SSL, default cipher suite is ECDHE-RSA-AES128-GCM-SHA256, TLS 1.2. All data traffic between the connecting user and the remote desktop is transmitted via the NX protocol using TCP or TCP and UDP. UDP traffic for multimedia communication (video, audio) is based on and encrypted using Blowfish cyphers negotiated through the secure TCP connection. The NX protocol uses by default port 4000. This port can be changed.

SSH industry standard protocol (available only with commercial servers)
The SSH protocol uses default port 22 on Linux and macOS and relies on the SSHD system server. NoMachine can be configured to use an alternative port according to SSHD settings. On Windows, NoMachine provides a SSH server (nxsshd) which uses by default port 4022. This port can be changed.

HTTPS protocol (available only with commercial servers)
NoMachine provides its own web server, which is a minimal version of Apache, pre-configured to deploy sessions on the web. Web sessions are encrypted by Apache mod_ssl using OpenSSL TLS/SSL, all ciphers are supported from TLS 1.2. By default web connections use port 443 for HTTPS (up to version 8, by default web connections use port 4080 and are redirected to HTTPS on port 4043). Port can be changed. It's also possible to use a system Apache web server instead than the NoMachine one. For a complete list of ports used by NoMachine, please refer to: https://kb.nomachine.com/AR01L00770. You can check which host and ports of the network are used by any TCP/IP network-analysis tool,and verify that no other ports are used, except those for the client and the server connection.

No man-in-the-middle
There's no man-in-the-middle in NoMachine's client-server communication and there are no extra calls. By extra calls we also include even anonymous automatic debug data or logs collection. All debug data and log collections are stored only locally to the NoMachine installation and never transferred to any third party. When requested by the NoMachine Support Team for investigating an issue, it's the users' decision and responsibility to clean and collect logs and send them to the NoMachine Staff.

The automatic software updates relies on NoMachine's repository servers, but the only information that the "software update" infrastructure provides to NoMachine is the current version of NoMachine on the user's device, to be able to define if the user needs an update or not. No other information is provided. The service of automatic updates can be disabled by the user on each NoMachine host. NoMachine update servers are physically located in multiple datacenters.

The new NoMachine Network service release in NoMachine 9 aims at making it possible for the client and server to communicate without the need to connect using the IP address, and adopts an external server (relay server) but it is still peer-to-peer communication. This relay server is effectively not able to decrypt the end-to-end traffic between the client and the server, since it doesn't have access to the users' cryptographic keys. It only makes it possible for client and server to "exchange packets" and communicate. It is possible to disable the NoMachine Network service and connect the IP addresses of the two ends, therefore using the standard client-to-server architecture explained above.

Supported authentication methods

Supported key types in NX and SSH connections are RSA, DSA, ECDSA and ED25519. For web connections, the RSA key type is supported.

Additionally, NoMachine supports:

Smart cards
By default, NoMachine uses its built-in interface module to read PKCS #11 smart cards. It’s also possible to configure the client to use an alternative security module. This is available for connections by NX and SSH protocol, but key forwarding is available only for connections by SSH and system login.

Authentication forwarding
An authentication agent (SSH agent) can be used to forward user’s credentials inside the NoMachine session. This is available for: – Connection by NX protocol and Kerberos ticket-base authentication – Connection by SSH protocol and SSH key based authentication – Connection by SSH protocol and Kerberos ticket-based authentication Kerberos-ticket based authentication
Kerberos tickets can be generated on: i) client side or on ii) server host i) Kerberos ticket-based authentication with tickets generated on client side is supported for both the NX and the SSH protocols. NoMachine client uses MIT Kerberos libraries by default to read Kerberos tickets. On Windows systems, Microsoft SSPI libraries are also supported. ii) In this case, PAM is configured to obtain a ticket for password-based authentication. Kerberos tickets generated on server side are supported on Windows only for connections by NX protocol. They are not supported when connecting by SSH protocol. iii) Kerberos ticket on Windows AD client is generated for user on system login, including smartcard authentication login.

Two-factor authentication
Two-factor authentication can only be achieved through combinig of Linux PAM modules, either for SSH or NX protocol. It's possible to use modules with different authentication types, such as: password, PIN, time based one-time passcode, security-key etc.

Access to remote desktops (desktop sharing) and authorizations By default, the desktop owner must always authorize the connection: clicking 'Accept' means that the incoming user will have full control on the computer (mouse, keyboard, complete access to file system and settings etc ...). Accepting the connection in 'View only' mode will prevent the incoming user from interacting with the computer or desktop. For unattended access it's possible to disable the request for authorization.

Disabling and enabling desktop sharing access
The desktop owner can disable and re-enable access to his/her desktop by means of the 'Desktop shared/Desktop not shared' toggle in the NoMachine menu. 

Hardening NoMachine server products
Please refer to https://kb.nomachine.com/AR06Q01036.

NoMachine messages, data storage and protection
Details about collection, processing, and use of personal data by NoMachine are described in the Privacy Policy here:  https://kb.nomachine.com/AR05P00977

NoMachine compliance and best practices
The installation of a NoMachine package must be done in accordance with your Company's security policies and IT requirements. Access to your computer should be granted only to people you know and trust.

Best self-protection practices for desktop sharing

Be aware that users connected to your desktop have full control and view every action performed on your desktop, unless you accepted the connection in view-only mode. When somebody is connected to your desktop: 1) Do not share sensitive data on your computer or keep it protected (e.g. use password-protected files and folders). 2) Do not perform operations which may reveal sensitive data, e.g. online purchases by credit card. NoMachine staff will never request access to your computer or desktop, unless a remote assistance session has been exceptionally agreed between the parties and through our standard support channels.