From 17c285349730db242fde3d4f7c64ec3e3b394f51 Mon Sep 17 00:00:00 2001 From: Gyuho Lee Date: Fri, 13 Apr 2018 14:06:49 -0700 Subject: [PATCH] Documentation/op-guide: explain TLS reload fix Signed-off-by: Gyuho Lee --- Documentation/op-guide/security.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Documentation/op-guide/security.md b/Documentation/op-guide/security.md index 38a0ace2f8ac..582fd1a6b48f 100644 --- a/Documentation/op-guide/security.md +++ b/Documentation/op-guide/security.md @@ -321,6 +321,22 @@ I | embed: serving client requests on 127.0.0.1:22379 I | embed: serving client requests on 127.0.0.1:2379 ``` +[v3.2.19](https://github.com/coreos/etcd/blob/master/CHANGELOG-3.2.md) and [v3.3.4](https://github.com/coreos/etcd/blob/master/CHANGELOG-3.3.md) fixes TLS reload when [certificate SAN field only includes IP addresses but no domain names](https://github.com/coreos/etcd/issues/9541). For example, a member is set up with CSRs (with `cfssl`) as below: + +```json +{ + "CN": "etcd.local", + "hosts": [ + "127.0.0.1" + ], +``` + +In Go, server calls `(*tls.Config).GetCertificate` for TLS reload if and only if server's `(*tls.Config).Certificates` field is not empty, or `(*tls.ClientHelloInfo).ServerName` is not empty with a valid SNI from the client. Previously, etcd always populates `(*tls.Config).Certificates` on the initial client TLS handshake, as non-empty. Thus, client was always expected to supply a matching SNI in order to pass the TLS verification and to trigger `(*tls.Config).GetCertificate` to reload TLS assets. + +However, a certificate whose SAN field does [not include any domain names but only IP addresses](https://github.com/coreos/etcd/issues/9541) would request `*tls.ClientHelloInfo` with an empty `ServerName` field, thus failing to trigger the TLS reload on initial TLS handshake; this becomes a problem when expired certificates need to be replaced online. + +Now, `(*tls.Config).Certificates` is created empty on initial TLS client handshake, first to trigger `(*tls.Config).GetCertificate`, and then to populate rest of the certificates on every new TLS connection, even when client SNI is empty (e.g. cert only includes IPs). + ## Notes for Host Whitelist `etcd --host-whitelist` flag specifies acceptable hostnames from HTTP client requests. Client origin policy protects against ["DNS Rebinding"](https://en.wikipedia.org/wiki/DNS_rebinding) attacks to insecure etcd servers. That is, any website can simply create an authorized DNS name, and direct DNS to `"localhost"` (or any other address). Then, all HTTP endpoints of etcd server listening on `"localhost"` becomes accessible, thus vulnerable to DNS rebinding attacks. See [CVE-2018-5702](https://bugs.chromium.org/p/project-zero/issues/detail?id=1447#c2) for more detail.