|
1 | 1 | :description: This section describes how to secure the cluster communication between server instances. |
2 | 2 | :page-aliases: clustering/intra-cluster-encryption.adoc |
| 3 | + |
3 | 4 | [role=enterprise-edition] |
4 | 5 | [[clustering-intra-cluster-encryption]] |
5 | 6 | = Intra-cluster encryption |
@@ -104,41 +105,62 @@ By default, cluster communication is unencrypted. |
104 | 105 | To configure a cluster to encrypt its intra-cluster communication, set `dbms.ssl.policy.cluster.enabled` to `true`. |
105 | 106 |
|
106 | 107 | An SSL policy utilizes the installed cryptographic objects and additionally allows parameters to be configured. |
107 | | -Use the following parameters in the configuration: |
108 | | - |
109 | | -.Example settings |
110 | | -[options="header"] |
111 | | -|=== |
112 | | -| Setting suffix | Value | Comment |
113 | | -| `client_auth` | `REQUIRE` | Setting this to `REQUIRE` effectively enables mutual authentication for servers. |
114 | | -| `ciphers` | `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384` | |
115 | | -A particular single strong cipher can be enforced and thus remove any doubt about which cipher gets negotiated and chosen. |
116 | | -The selected cipher offers Perfect Forward Secrecy (PFS) which is generally desirable. |
117 | | -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. |
118 | | -| `tls_versions` | `TLSv1.2` | |
119 | | -With control of the entire cluster, the latest TLS standard can be enforced without any concern for backwards compatibility. |
| 108 | +Use the parameters in one of the following configurations: |
| 109 | + |
| 110 | +[.tabbed-example] |
| 111 | +===== |
| 112 | +[.include-with-one-TLS-version] |
| 113 | +====== |
| 114 | + |
| 115 | +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. |
| 116 | + |
| 117 | +Add the following content to the _neo4j.conf_ file: |
| 118 | + |
| 119 | +[source, properties] |
| 120 | +---- |
| 121 | +dbms.ssl.policy.cluster.enabled=true |
| 122 | +dbms.ssl.policy.cluster.tls_versions=TLSv1.2 \ # <1> |
| 123 | +dbms.ssl.policy.cluster.ciphers=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 \ # <2> |
| 124 | +dbms.ssl.policy.cluster.client_auth=REQUIRE # <3> |
| 125 | +---- |
| 126 | + |
| 127 | +<1> With control of the entire cluster, the default TLS standard can be enforced without any concern for backwards compatibility. |
120 | 128 | It has no known security vulnerabilities and uses the most modern algorithms for key exchanges, etc. |
121 | | -|=== |
| 129 | +<2> A particular single strong cipher can be enforced and thus remove any doubt about which cipher gets negotiated and chosen. |
| 130 | +The selected cipher offers Perfect Forward Secrecy (PFS) and uses the Advanced Encryption Standard (AES) for symmetric encryption. |
| 131 | +AES has great support for hardware acceleration and thus allows performance to be generally negligibly affected. |
| 132 | +<3> Setting the cluster client authentication to `REQUIRE` enables mutual authentication, meaning both ends of a channel must authenticate. |
122 | 133 |
|
123 | | -In the following example, an SSL policy is created and configured that is used in the example cluster. |
124 | 134 |
|
125 | | -.Configure the cluster SSL policy |
126 | | -==== |
127 | | -This example assumes that the directory structure is created, and certificate files are installed, as per the previous example. |
| 135 | +====== |
| 136 | +[role=include-with-two-TLS-versions label--new-5.24] |
| 137 | +====== |
| 138 | + |
| 139 | +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. |
128 | 140 |
|
129 | 141 | Add the following content to the _neo4j.conf_ file: |
130 | 142 |
|
131 | 143 | [source, properties] |
132 | 144 | ---- |
133 | 145 | dbms.ssl.policy.cluster.enabled=true |
134 | | -dbms.ssl.policy.cluster.tls_versions=TLSv1.2 |
135 | | -dbms.ssl.policy.cluster.ciphers=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
136 | | -dbms.ssl.policy.cluster.client_auth=REQUIRE |
| 146 | +dbms.ssl.policy.cluster.tls_versions=TLSv1.3,TLSv1.2 \ # <1> |
| 147 | +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> |
| 148 | +dbms.ssl.policy.cluster.client_auth=REQUIRE \# <3> |
137 | 149 | ---- |
138 | 150 |
|
139 | | -Any user data communicated between instances is now secured. |
140 | | -Note that an instance that is not correctly setup is not able to communicate with the others. |
141 | | -==== |
| 151 | +<1> With control of the entire cluster, the default TLS standard can be enforced without any concern for backwards compatibility. |
| 152 | +It has no known security vulnerabilities and uses the most modern algorithms for key exchanges, etc. |
| 153 | +<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. |
| 154 | +The selected ciphers offer Perfect Forward Secrecy (PFS) and use the Advanced Encryption Standard (AES) for symmetric encryption. |
| 155 | +AES has great support for hardware acceleration and thus allows performance to be generally negligibly affected. |
| 156 | +<3> Setting the cluster client authentication to `REQUIRE` enables mutual authentication, meaning both ends of a channel must authenticate. |
| 157 | +They have no known security vulnerabilities and use the most modern algorithms for key exchanges, etc. |
| 158 | + |
| 159 | +====== |
| 160 | +===== |
| 161 | + |
| 162 | +Any user data communicated between servers is now secured. |
| 163 | +Note that a server that is not correctly setup is not able to communicate with the others. |
142 | 164 |
|
143 | 165 | The policy must be configured on every server with the same settings. |
144 | 166 | The actual cryptographic objects installed are mostly different since they do not share the same private keys and corresponding certificates. |
|
0 commit comments