Documentation/op-guide: document "--cipher-suites"
@@ -38,6 +38,8 @@ The peer options work the same way as the client-to-server options:
If either a client-to-server or peer certificate is supplied the key must also be set. All of these configuration options are also available through the environment variables, `ETCD_CA_FILE`, `ETCD_PEER_CA_FILE` and so on.
+`--cipher-suites`: Comma-separated list of supported TLS cipher suites between server/client and peers (empty will be auto-populated by Go). Available from v3.2.22+, v3.3.7+, and v3.4+.
+
## Example 1: Client-to-server transport security with HTTPS
For this, have a CA certificate (`ca.crt`) and signed key pair (`server.crt`, `server.key`) ready.
@@ -122,6 +124,49 @@ And also the response from the server:
}
```
+Specify cipher suites to block [weak TLS cipher suites](https://github.com/coreos/etcd/issues/8320).
+
+TLS handshake would fail when client hello is requested with invalid cipher suites.
+
+For instance:
+
+```bash
+$ etcd \
+ --cert-file ./server.crt \
+ --key-file ./server.key \
+ --trusted-ca-file ./ca.crt \
+ --cipher-suites TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+```
+
+Then, client requests must specify one of the cipher suites specified in the server:
+
+```bash
+# valid cipher suite
+$ curl \
+ --cacert ./ca.crt \
+ --cert ./server.crt \
+ --key ./server.key \
+ -L [CLIENT-URL]/metrics \
+ --ciphers ECDHE-RSA-AES128-GCM-SHA256
+
+# request succeeds
+etcd_server_version{server_version="3.2.22"} 1
+...
+```
+
+```bash
+# invalid cipher suite
+$ curl \
+ --cacert ./ca.crt \
+ --cert ./server.crt \
+ --key ./server.key \
+ -L [CLIENT-URL]/metrics \
+ --ciphers ECDHE-RSA-DES-CBC3-SHA
+
+# request fails with
+(35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
+```
+
## Example 3: Transport security & client certificates in a cluster
etcd supports the same model as above for **peer communication**, that means the communication between etcd members in a cluster.
