Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion modules/ROOT/pages/backup-restore/online-backup.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -318,8 +318,12 @@ dbms.ssl.policy.backup.ciphers=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
dbms.ssl.policy.backup.client_auth=REQUIRE
----

[NOTE]
[TIP]
====
Neo4j 5.24 also supports TLSv1.3.
To use both TLSv1.2 and TLSv1.3 versions, you must specify which ciphers to be enforced for each version.
Otherwise, Neo4j could use every possible cipher in the JVM for those versions, leading to a less secure configuration.

For a detailed list of recommendations regarding security in Neo4j, see xref:security/checklist.adoc[Security checklist].
====

Expand Down
70 changes: 46 additions & 24 deletions modules/ROOT/pages/clustering/setup/encryption.adoc
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
:description: This section describes how to secure the cluster communication between server instances.
:page-aliases: clustering/intra-cluster-encryption.adoc

[role=enterprise-edition]
[[clustering-intra-cluster-encryption]]
= Intra-cluster encryption
Expand Down Expand Up @@ -104,41 +105,62 @@ By default, cluster communication is unencrypted.
To configure a cluster to encrypt its intra-cluster communication, set `dbms.ssl.policy.cluster.enabled` to `true`.

An SSL policy utilizes the installed cryptographic objects and additionally allows parameters to be configured.
Use the following parameters in the configuration:

.Example settings
[options="header"]
|===
| Setting suffix | Value | Comment
| `client_auth` | `REQUIRE` | Setting this to `REQUIRE` effectively enables mutual authentication for servers.
| `ciphers` | `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384` |
A particular single strong cipher can be enforced and thus remove any doubt about which cipher gets negotiated and chosen.
The selected cipher offers Perfect Forward Secrecy (PFS) which is generally desirable.
It also uses Advanced Encryption Standard (AES) for symmetric encryption which has great support for acceleration in hardware and thus allows performance to generally be negligibly affected.
| `tls_versions` | `TLSv1.2` |
With control of the entire cluster, the latest TLS standard can be enforced without any concern for backwards compatibility.
Use the parameters in one of the following configurations:

[.tabbed-example]
=====
[.include-with-one-TLS-version]
======

The following example assumes that an SSL policy is created and configured as per the <<clustering-intra-cluster-encryption-example-deployment, example deployment>> and uses the default TLSv1.2.

Add the following content to the _neo4j.conf_ file:

[source, properties]
----
dbms.ssl.policy.cluster.enabled=true
dbms.ssl.policy.cluster.tls_versions=TLSv1.2 \ # <1>
dbms.ssl.policy.cluster.ciphers=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 \ # <2>
dbms.ssl.policy.cluster.client_auth=REQUIRE # <3>
----

<1> With control of the entire cluster, the default TLS standard can be enforced without any concern for backwards compatibility.
It has no known security vulnerabilities and uses the most modern algorithms for key exchanges, etc.
|===
<2> A particular single strong cipher can be enforced and thus remove any doubt about which cipher gets negotiated and chosen.
The selected cipher offers Perfect Forward Secrecy (PFS) and uses the Advanced Encryption Standard (AES) for symmetric encryption.
AES has great support for hardware acceleration and thus allows performance to be generally negligibly affected.
<3> Setting the cluster client authentication to `REQUIRE` enables mutual authentication, meaning both ends of a channel must authenticate.

In the following example, an SSL policy is created and configured that is used in the example cluster.

.Configure the cluster SSL policy
====
This example assumes that the directory structure is created, and certificate files are installed, as per the previous example.
======
[role=include-with-two-TLS-versions label--new-5.24]
======

The following example assumes that an SSL policy is created and configured as per the <<clustering-intra-cluster-encryption-example-deployment, example deployment>> and uses both TLSv1.2 and TLSv1.3.

Add the following content to the _neo4j.conf_ file:

[source, properties]
----
dbms.ssl.policy.cluster.enabled=true
dbms.ssl.policy.cluster.tls_versions=TLSv1.2
dbms.ssl.policy.cluster.ciphers=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
dbms.ssl.policy.cluster.client_auth=REQUIRE
dbms.ssl.policy.cluster.tls_versions=TLSv1.3,TLSv1.2 \ # <1>
dbms.ssl.policy.cluster.ciphers=TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA \ # <2>
dbms.ssl.policy.cluster.client_auth=REQUIRE \# <3>
----

Any user data communicated between instances is now secured.
Note that an instance that is not correctly setup is not able to communicate with the others.
====
<1> With control of the entire cluster, the default TLS standard can be enforced without any concern for backwards compatibility.
It has no known security vulnerabilities and uses the most modern algorithms for key exchanges, etc.
<2> If you want to specify ciphers for both supported TLS versions, you must specify ciphers for each TLS version not to get more ciphers than expected.
The selected ciphers offer Perfect Forward Secrecy (PFS) and use the Advanced Encryption Standard (AES) for symmetric encryption.
AES has great support for hardware acceleration and thus allows performance to be generally negligibly affected.
<3> Setting the cluster client authentication to `REQUIRE` enables mutual authentication, meaning both ends of a channel must authenticate.
They have no known security vulnerabilities and use the most modern algorithms for key exchanges, etc.

======
=====

Any user data communicated between servers is now secured.
Note that a server that is not correctly setup is not able to communicate with the others.

The policy must be configured on every server with the same settings.
The actual cryptographic objects installed are mostly different since they do not share the same private keys and corresponding certificates.
Expand Down
6 changes: 4 additions & 2 deletions modules/ROOT/pages/security/ssl-framework.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -284,10 +284,12 @@ The SSL policies are configured by assigning values to parameters of the followi
Names (SAN) fields.
If the address does not match those fields, the client disconnects. | `false`
| `ciphers` | A comma-separated list of ciphers suites allowed during cipher negotiation.
Valid values depend on the current JRE and SSL provider.
Valid values depend on the current JRE, SSL provider, and TLS version.
For Ciphers supported by the Oracle JRE, see the link:https://docs.oracle.com/en/java/javase/17/docs/specs/security/standard-names.html#jsse-cipher-suite-names[Oracle official documentation].
| Java platform default allowed cipher suites.
| `tls_versions` | A comma-separated list of allowed TLS versions. By default only TLSv1.2 and TLSv1.3 are allowed. | `TLSv1.2` +
| `tls_versions` | A comma-separated list of allowed TLS versions. By default only TLSv1.2 and TLSv1.3 are allowed.
To use both TLSv1.2 and TLSv1.3 versions, you must specify which ciphers to be enforced for each version.
Otherwise, Neo4j could use every possible cipher in the JVM for those versions, leading to a less secure configuration. | `TLSv1.2` +
`TLSv1.3` label:new[Supported from Neo4j 5.24]
| `client_auth` | Whether or not clients must be authenticated.
Setting this to `REQUIRE` enables mutual authentication for servers.
Expand Down