From 84a345324cd78d4a2b8576bd27c912e7712858cd Mon Sep 17 00:00:00 2001 From: Kent 'picat' Gruber Date: Thu, 5 Nov 2020 16:09:07 -0500 Subject: [PATCH] Fix inline links + format in mTLS requirements section --- .../docs/security/security-models/core.mdx | 39 ++++++++++--------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/website/pages/docs/security/security-models/core.mdx b/website/pages/docs/security/security-models/core.mdx index d7776d71d0..2895a0547f 100644 --- a/website/pages/docs/security/security-models/core.mdx +++ b/website/pages/docs/security/security-models/core.mdx @@ -83,25 +83,26 @@ environment and adapt these configurations accordingly. - [`verifing_incoming_rpc`](/docs/agent/options#verify_incoming_rpc) - By default this is false, and should almost always be set to true to require clients to provide a valid TLS certificate for Consul agent RPCs. - - [`verify_outgoing` - By default this is false, and should be set to true to require TLS for outgoing connections from - server or client agents. Servers that specify `verify_outgoing = true` will always talk to other servers over TLS, - but they still accept non-TLS connections to allow for a transition of all clients to TLS. Currently the only way to - enforce that no client can communicate with a server unencrypted is to also enable `verify_incoming` which requires - client certificates too. - - - `enable_agent_tls_for_checks`](/docs/agent/options#verify_outgoing) - By default this is false, and should almost - always be set to true to require mTLS to set up the client for HTTP or gRPC health checks. This was added in - Consul 1.0.1. - - - `verify_server_hostname` - By default this is false, and should be set to true to require for outgoing TLS - connections that the TLS certificate presented by the servers matches `server.. hostname`. The - default configuration does not verify the hostname of the certificate, only that it is signed by a trusted CA. This - setting is critical to prevent a compromised client agent from being restarted as a server and having all cluster - state including all ACL tokens and Connect CA root keys replicated to it, and introduced in 0.5.1. From version - 0.5.1 to 1.4.0 we documented that `verify_server_hostname` being true implied verify_outgoing however due to a bug - this was not the case so setting only `verify_server_hostname` results in plaintext communication between client - and server. See [CVE-2018-19653](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19653) for more details. - This is fixed in 1.4.1. + - [`verify_outgoing`](/docs/agent/options#verify_outgoing) - By default this is false, and should be set to true to + require TLS for outgoing connections from server or client agents. Servers that specify `verify_outgoing = true` + will always talk to other servers over TLS, but they still accept non-TLS connections to allow for a transition of + all clients to TLS. Currently the only way to enforce that no client can communicate with a server unencrypted is + to also enable `verify_incoming` which requires client certificates too. + + - [`enable_agent_tls_for_checks`](/docs/agent/options#enable_agent_tls_for_checks) - By default this is false, and + should almost always be set to true to require mTLS to set up the client for HTTP or gRPC health checks. This was + added in Consul 1.0.1. + + - [`verify_server_hostname`](/docs/agent/options#verify_server_hostname) - By default this is false, and should be + set to true to require for outgoing TLS connections that the TLS certificate presented by the servers matches + `server.. hostname`. The default configuration does not verify the hostname of the certificate, + only that it is signed by a trusted CA. This setting is critical to prevent a compromised client agent from being + restarted as a server and having all cluster state including all ACL tokens and Connect CA root keys replicated to + it, and introduced in 0.5.1. From version 0.5.1 to 1.4.0 we documented that `verify_server_hostname` being true + implied verify_outgoing however due to a bug this was not the case so setting only `verify_server_hostname` results + in plaintext communication between client and server. + See [CVE-2018-19653](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19653) for more details. This is fixed + in 1.4.1. **Example Server Agent TLS Configuration**