Backport of update serf links into release/1.20.x (#21800)

* no-op commit due to failed cherry-picking

* update serf links (#21797)

* update serf links

* add .markdown file extension

* update serf links to use /blob/master/

* fix broken links

---------

Co-authored-by: github-team-consul-core <github-team-consul-core@hashicorp.com>

---------

Co-authored-by: temp <temp@hashicorp.com>
Co-authored-by: John Murret <john.murret@hashicorp.com>

internal/gossip/libserf/serf.go

@@ -29,7 +29,7 @@ func DefaultConfig() *serf.Config {
 	// This gives leaves some time to propagate through the cluster before
 	// we shut down. The value was chosen to be reasonably short, but to
 	// allow a leave to get to over 99.99% of the cluster with 100k nodes
-	// (using https://www.serf.io/docs/internals/simulator.html).
+	// (using https://github.com/hashicorp/serf/blob/master/docs/internals/simulator.html.erb).
 	base.LeavePropagateDelay = 3 * time.Second
 
 	return base

website/content/docs/architecture/coordinates.mdx

@@ -14,10 +14,10 @@ very simple calculation. This allows for many useful applications, such as findi
 the service node nearest a requesting node, or failing over to services in the next
 closest datacenter.
 
-All of this is provided through the use of the [Serf library](https://www.serf.io/).
+All of this is provided through the use of the [Serf library](https://github.com/hashicorp/serf/).
 Serf's network tomography is based on ["Vivaldi: A Decentralized Network Coordinate System"](http://www.cs.ucsb.edu/~ravenben/classes/276/papers/vivaldi-sigcomm04.pdf),
 with some enhancements based on other research. There are more details about
-[Serf's network coordinates here](https://www.serf.io/docs/internals/coordinates.html).
+[Serf's network coordinates here](https://github.com/hashicorp/serf/blob/master/docs/internals/coordinates.html.markdown).
 
 ## Network Coordinates in Consul
 

website/content/docs/architecture/gossip.mdx

@@ -9,15 +9,15 @@ description: >-
 
 Consul uses a [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol)
 to manage membership and broadcast messages to the cluster. The protocol, membership management, and message broadcasting is provided
-through the [Serf library](https://www.serf.io/). The gossip protocol
+through the [Serf library](https://github.com/hashicorp/serf/). The gossip protocol
 used by Serf is based on a modified version of the
 [SWIM (Scalable Weakly-consistent Infection-style Process Group Membership)](https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/SWIM.pdf) protocol.
-Refer to the [Serf documentation](https://www.serf.io/docs/internals/gossip.html) for additional information about the gossip protocol.
+Refer to the [Serf documentation](https://github.com/hashicorp/serf/blob/master/docs/internals/gossip.html.markdown) for additional information about the gossip protocol.
 
 ## Gossip in Consul
 
 Consul uses a LAN gossip pool and a WAN gossip pool to perform different functions. The pools
-are able to perform their functions by leveraging an embedded [Serf](https://www.serf.io/)
+are able to perform their functions by leveraging an embedded [Serf](https://github.com/hashicorp/serf/)
 library. The library is abstracted and masked by Consul to simplify the user experience,
 but developers may find it useful to understand how the library is leveraged.
 
@@ -52,5 +52,5 @@ For more details about Lifeguard, please see the
 [Making Gossip More Robust with Lifeguard](https://www.hashicorp.com/blog/making-gossip-more-robust-with-lifeguard/)
 blog post, which provides a high level overview of the HashiCorp Research paper
 [Lifeguard : SWIM-ing with Situational Awareness](https://arxiv.org/abs/1707.00788). The
-[Serf gossip protocol guide](https://www.serf.io/docs/internals/gossip.html#lifeguard)
+[Serf gossip protocol guide](https://github.com/hashicorp/serf/blob/master/docs/internals/gossip.html.markdown#lifeguard-enhancements)
 also provides some lower-level details about the gossip protocol and Lifeguard.

website/content/docs/install/glossary.mdx

@@ -51,7 +51,7 @@ and our implementation is described [here](/consul/docs/architecture/consensus).
 
 ## Gossip
 
-Consul is built on top of [Serf](https://www.serf.io/) which provides a full
+Consul is built on top of [Serf](https://github.com/hashicorp/serf/) which provides a full
 [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) that is used for multiple purposes.
 Serf provides membership, failure detection, and event broadcast. Our use of these
 is described more in the [gossip documentation](/consul/docs/architecture/gossip). It is enough to know

website/content/docs/security/encryption/index.mdx

@@ -0,0 +1,55 @@
+---
+layout: docs
+page_title: Encrypted communication between Consul agents
+description: >-
+  Consul supports encrypting all of its network traffic. Remote Procedure Calls (RPCs) between client and server agents can be encrypted with TLS and authenticated with certificates. Gossip communication between all agents can also be encrypted.
+---
+
+# Encrypted communication between Consul agents
+
+This topic provides an overview of the two distinct encryption systems available in Consul. [Gossip encryption](/consul/docs/security/encryption#gossip-encryption) and [Mutual TLS encryption](/consul/docs/security/encryption#mutual-tls-mtls-encryption) are the foundations of a secure Consul datacenter.
+
+The guidelines in the [Consul security model](/consul/docs/security/security-models/core) for operating a secure Consul deployment recommends using both encryption systems.
+
+## Gossip Encryption
+
+Consul uses a [gossip protocol](/consul/docs/architecture/gossip) to perform the following cluster operations:
+
+- Identify datacenter members.
+- Quickly detect failed members and notify the rest of the cluster.
+- Broadcast events and queries that can trigger custom workflows.
+
+The gossip protocol, as well as its membership management and message broadcasting features, use the [Serf library](https://github.com/hashicorp/serf/).
+
+In a default Consul configuration, the gossip protocol uses [port `8301`](/consul/docs/install/ports#lan-serf) for LAN communications and [port `8302`](/consul/docs/install/ports#lan-serf) for WAN communications between federated datacenters. Enabling gossip encryption on a Consul datacenter is required to secure traffic on these two ports.
+
+Gossip encryption is symmetric and based on a single key that is shared across all members of the datacenter. You can configure gossip encryption in Consul using the following parameters:
+
+- [`encrypt`](/consul/docs/agent/config/config-files#encrypt).
+- [`encrypt_verify_incoming`](/consul/docs/agent/config/config-files#encrypt_verify_incoming). Only used when upshifting from unencrypted to encrypted gossip on a running cluster.
+- [`encrypt_verify_outgoing`](/consul/docs/agent/config/config-files#encrypt_verify_outgoing). Only used when upshifting from unencrypted to encrypted gossip on a running cluster.
+
+To learn more about enabling gossip encryption on your Consul datacenter and rotating gossip keys, refer to [manage gossip encryption](/consul/docs/security/encryption/gossip).
+
+## Mutual TLS (mTLS) Encryption
+
+Consul uses several communication protocols over different ports that you can secure using mTLS:
+
+- A [consensus protocol](/consul/docs/architecture/consensus) provides data consistency between Consul servers. It typically uses [port `8300`](/consul/docs/install/ports#server-rpc).
+- Remote Procedure Calls (RPC) forward requests from client agents to server agents. They use the same port the consensus protocol uses.
+- An HTTP or HTTPS interface permits client communication with the Consul API, CLI, and UI. It typically uses [port `8500`](/consul/docs/install/ports#http) and [port `8501`](/consul/docs/install/ports#https).
+- A gRPC interface receives incoming traffic from the gateways and Envoy proxies registered to the agent node. It typically uses [port `8502`](/consul/docs/install/ports#client-grpc) and [port `8503`](/consul/docs/install/ports#client-grpc-tls).
+
+Consul uses mTLS to verify the authenticity of server and client agents. It requires that all clients and servers have key pairs that are generated by a single Certification Authority (CA). We recommend using a private CA that is not shared with other applications.
+
+You can configure mTLS in Consul using the [`tls` stanza in agent configuration files](/consul/docs/agent/config/config-files#tls-1).
+
+You can configure mTLS encryption for each protocol separately using the following parameters in the agent configuration file:
+
+- [`tls.defaults`](/consul/docs/agent/config/config-files#tls_defaults) provides default settings that Consul applies to every interface unless explicitly overridden by protocol-specific configurations.
+- [`tls.internal_rpc`](/consul/docs/agent/config/config-files#tls_internal_rpc) provides settings for the internal server RPC interface.
+- [`tls.https`](/consul/docs/agent/config/config-files#tls_https) provides settings for the HTTP/HTTPS interface.
+- [`tls.grpc`](/consul/docs/agent/config/config-files#tls_grpc) provides settings for the gRPC/xDS interface.
+
+To learn more about enabling mTLS on your Consul datacenter, refer to [Manage mTLS encryption](/consul/docs/security/encryption/mTLS).
+

website/content/docs/troubleshoot/faq.mdx

@@ -69,7 +69,7 @@ and [`disable_update_check`](/consul/docs/agent/config/config-files#disable_upda
 
 ### Q: Does Consul rely on UDP Broadcast or Multicast?
 
-Consul uses the [Serf](https://www.serf.io) gossip protocol which relies on
+Consul uses the [Serf](https://github.com/hashicorp/serf/) gossip protocol which relies on
 TCP and UDP unicast. Broadcast and Multicast are rarely available in a
 multi-tenant or cloud network environment. For that reason, Consul and Serf
 were both designed to avoid any dependence on those capabilities.