diff --git a/source/core/replication.txt b/source/core/replication.txt
index 0c918be3169..cee2e304ff0 100644
--- a/source/core/replication.txt
+++ b/source/core/replication.txt
@@ -164,6 +164,21 @@ participate in :term:`elections <election>`.
    Do not run arbiter processes on a system that is an active
    :term:`primary` or :term:`secondary` of its replica set.
 
+Arbiters never receive the contents of any collection but do have the
+following interactions with the ret of the replica set:
+
+- Credential exchanges, which are used to authenticate the arbiter with
+  the replica set. All MongoDB processes within a replica set use
+  keyfiles. These exchanges are encrypted.
+
+- Only the authentication step is encrypted. Replica set configuration
+  data and voting are not encrypted.
+
+If your MongoDB deployment uses SSL, then all communications between
+arbiters and the other members of the replica set are secure. See the
+documentation for :doc:`/administration/ssl` for more information. Run
+all arbiters on secure networks, as with all MongoDB components.
+
 .. index:: replica set members; non-voting
 .. _replica-set-non-voting-members:
 
@@ -308,7 +323,8 @@ apply or decide to ignore the rollback data.
 
 The best strategy for avoiding all rollbacks is to ensure :ref:`write
 propagation <replica-set-write-concern>` to all or some of the
-nodes in the set. Using these kinds of policies prevents situations
+nodes in the set. Using /bin/bash: Using: command not found
+these kinds of policies prevents situations
 that might create rollbacks.
 
 .. warning::
diff --git a/source/faq/replica-sets.txt b/source/faq/replica-sets.txt
index bd064843476..b9cbfe53cb2 100644
--- a/source/faq/replica-sets.txt
+++ b/source/faq/replica-sets.txt
@@ -181,6 +181,24 @@ primary.
 
 .. seealso:: :doc:`/administration/replication-architectures`
 
+What information do arbiters exchange with replica sets?
+--------------------------------------------------------
+
+Arbiters never receive the contents of a collection but do exchange the
+following data with the rest of the replica set:
+
+- Credentials used to authenticate the arbiter with the replica set. All
+  MongoDB processes within a replica set use keyfiles. These exchanges
+  are encrypted.
+
+- Replica set configuration data and voting data. This information is
+  not encrypted. Only credential exchanges are encrypted.
+
+If your MongoDB deployment uses SSL, then all communications between
+arbiters and the other members of the replica set are secure. See the
+documentation for :doc:`/administration/ssl` for more information. Run
+all arbiters on secure networks, as with all MongoDB components.
+
 Which members of a replica set vote in elections?
 -------------------------------------------------