]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
Update TLS-related warnings within ARM
authorArtem Boldariev <artem@boldariev.com>
Tue, 3 May 2022 10:19:26 +0000 (13:19 +0300)
committerArtem Boldariev <artem@boldariev.com>
Tue, 3 May 2022 10:55:07 +0000 (13:55 +0300)
This commit updates TLS-related warnings so that the fact that Strict
and Mutual TLS are implemented is taken into consideration.

doc/arm/reference.rst

index 2807f01d0a3b75e451197ee3e442a0cddc842fea..25ddd999eb76789585378600855bea65019c0c6e 100644 (file)
@@ -892,9 +892,14 @@ where ``tls-configuration-name`` refers to a previously defined
 
 .. warning::
 
-   Please note that TLS connections to primaries are currently
-   **not authenticated**. This mode provides protection from passive observers
-   but does not protect from man-in-the-middle attacks on zone transfers.
+   Please note that TLS connections to primaries are **not
+   authenticated** unless ``hostname`` or ``ca-file`` are specified
+   within the :ref:`tls statement <tls>` in use (see information on
+   :ref:`Strict TLS <strict-tls>` and :ref:`Mutual TLS <mutual-tls>`
+   for more details).  **Not authenticated mode** (:ref:`Opportunistic
+   TLS <opportunistic-tls>`) provides protection from passive
+   observers but does not protect from man-in-the-middle attacks on
+   zone transfers.
 
 
 .. _options_grammar:
@@ -2476,9 +2481,11 @@ for details on how to specify IP address lists.
 
 .. warning::
 
-   Please note that incoming TLS connections are currently
-   **not authenticated at the TLS level**.
-   Please use :ref:`tsig` to authenticate requestors.
+   Please note that incoming TLS connections are
+   **not authenticated at the TLS level by default**.
+   Please use :ref:`tsig` to authenticate requestors
+   or consider implementing :ref:`Mutual TLS <mutual-tls>`
+   authentication.
 
 ``blackhole``
    This specifies a list of addresses which the server does not accept queries
@@ -4922,6 +4929,8 @@ BIND supports the following TLS authentication mechanisms described in
 the RFC 9103, Section 9.3: Opportunistic TLS, Strict TLS, and Mutual
 TLS.
 
+.. _opportunistic-tls:
+
 Opportunistic TLS provides encryption for data but does not provide
 any authentication for the channel. This mode is the default one and
 it is used whenever ``hostname`` and ``ca-file`` options are not set
@@ -4933,6 +4942,8 @@ complementary tools either successfully establish a secure channel via
 TLS when instructed to do so or fail to establish a connection
 otherwise.
 
+.. _strict-tls:
+
 Strict TLS provides server authentication via a pre-configured
 hostname for outgoing connections. This mechanism offers both channel
 confidentiality and channel authentication (of the server). In order
@@ -4947,6 +4958,8 @@ used by WEB-browsers to authenticate HTTPS hosts. On the other hand,
 if ``ca-file`` is provided but ``hostname`` is missing, then the
 remote side's IP address is used instead.
 
+.. _mutual-tls:
+
 Mutual TLS is an extension to Strict TLS that provides channel
 confidentiality and mutual channel authentication. It builds up upon
 the clients offering client certificates when establishing connections