From 979c94de3724ac38bf79ecc3da55368bbe8e9ad0 Mon Sep 17 00:00:00 2001
From: Travis Cross <tc@traviscross.com>
Date: Tue, 26 May 2015 14:01:31 +0000
Subject: [PATCH] FS-7708: Fix docs on enabling cert CN/SAN validation

The correct incantations to enable certification common name / subject
alternative name verification, per our code, are `subjects_all`,
`subjects_in`, and `subjects_out` in a Sofia profile's
`tls-verify-policy`.  What we've had in our examples and documentation
for years are `all_subjects`, `in_subjects`, and `out_subjects`.

The result of this is that we've almost certainly confused people into
using the incorrect forms.  Those poor people will believe that they
are verifying the CN/SAN of the received host certificate against the
list in `tls-verify-in-subjects` when in fact they are not.

One clear issue in this case was that the incorrect forms failed to
have any effect without providing any warning or error.  This issue
could not have persisted if we had made more noise about incorrect
input.

Given how long this has been broken, it's tempting to alias the
incorrect forms to the correct ones.  However this would certainly
break many existing installations that have, because of this error,
never actually tested their setup with CN/SAN validation enabled.

In this commit, we fix the examples and documentation, and add an
error-level log output when unknown values are passed to
`tls-verify-policy`.

Thanks-to: Andrew Patrikalakis <anrp+freeswitch@anrp.net>
---
 conf/rayo/sip_profiles/external.xml             | 2 +-
 conf/vanilla/sip_profiles/external-ipv6.xml     | 2 +-
 conf/vanilla/sip_profiles/external.xml          | 2 +-
 conf/vanilla/sip_profiles/internal.xml          | 2 +-
 src/mod/endpoints/mod_sofia/conf/sofia.conf.xml | 2 +-
 src/mod/endpoints/mod_sofia/sofia_glue.c        | 4 ++++
 6 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/conf/rayo/sip_profiles/external.xml b/conf/rayo/sip_profiles/external.xml
index 60266004a4..952e6c7848 100644
--- a/conf/rayo/sip_profiles/external.xml
+++ b/conf/rayo/sip_profiles/external.xml
@@ -84,7 +84,7 @@
     <!-- Verify the date on TLS certificates -->
     <param name="tls-verify-date" value="true"/>
     <!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate -->
-    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'in_subjects', 'out_subjects' and 'all_subjects' for subject validation. Multiple policies can be split with a '|' pipe -->
+    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe -->
     <param name="tls-verify-policy" value="none"/>
     <!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none -->
     <param name="tls-verify-depth" value="2"/>
diff --git a/conf/vanilla/sip_profiles/external-ipv6.xml b/conf/vanilla/sip_profiles/external-ipv6.xml
index 7dc5906c5f..be70ff3b1e 100644
--- a/conf/vanilla/sip_profiles/external-ipv6.xml
+++ b/conf/vanilla/sip_profiles/external-ipv6.xml
@@ -84,7 +84,7 @@
     <!-- Verify the date on TLS certificates -->
     <param name="tls-verify-date" value="true"/>
     <!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate -->
-    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'in_subjects', 'out_subjects' and 'all_subjects' for subject validation. Multiple policies can be split with a '|' pipe -->
+    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe -->
     <param name="tls-verify-policy" value="none"/>
     <!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none -->
     <param name="tls-verify-depth" value="2"/>
diff --git a/conf/vanilla/sip_profiles/external.xml b/conf/vanilla/sip_profiles/external.xml
index 6edc878c06..dfc9504bcb 100644
--- a/conf/vanilla/sip_profiles/external.xml
+++ b/conf/vanilla/sip_profiles/external.xml
@@ -84,7 +84,7 @@
     <!-- Verify the date on TLS certificates -->
     <param name="tls-verify-date" value="true"/>
     <!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate -->
-    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'in_subjects', 'out_subjects' and 'all_subjects' for subject validation. Multiple policies can be split with a '|' pipe -->
+    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe -->
     <param name="tls-verify-policy" value="none"/>
     <!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none -->
     <param name="tls-verify-depth" value="2"/>
diff --git a/conf/vanilla/sip_profiles/internal.xml b/conf/vanilla/sip_profiles/internal.xml
index 1788780601..ccc9893eb4 100644
--- a/conf/vanilla/sip_profiles/internal.xml
+++ b/conf/vanilla/sip_profiles/internal.xml
@@ -204,7 +204,7 @@
     <!-- Verify the date on TLS certificates -->
     <param name="tls-verify-date" value="true"/>
     <!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate -->
-    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'in_subjects', 'out_subjects' and 'all_subjects' for subject validation. Multiple policies can be split with a '|' pipe -->
+    <!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe -->
     <param name="tls-verify-policy" value="none"/>
     <!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none -->
     <param name="tls-verify-depth" value="2"/>
diff --git a/src/mod/endpoints/mod_sofia/conf/sofia.conf.xml b/src/mod/endpoints/mod_sofia/conf/sofia.conf.xml
index 2e1a849e41..46095e9a6d 100644
--- a/src/mod/endpoints/mod_sofia/conf/sofia.conf.xml
+++ b/src/mod/endpoints/mod_sofia/conf/sofia.conf.xml
@@ -242,7 +242,7 @@
              how should we verify their certificate -->
         <!-- set to 'in' to only verify incoming connections, 'out' to only
              verify outgoing connections, 'all' to verify all connections, also
-             'in_subjects', 'out_subjects' and 'all_subjects' for subject
+             'subjects_in', 'subjects_out' and 'subjects_all' for subject
              validation. Multiple policies can be split with a '|' pipe -->
         <param name="tls-verify-policy" value="none"/>
         <!-- Certificate max verify depth to use for validating peer TLS
diff --git a/src/mod/endpoints/mod_sofia/sofia_glue.c b/src/mod/endpoints/mod_sofia/sofia_glue.c
index cfa01c34f2..bd77f6f5e6 100644
--- a/src/mod/endpoints/mod_sofia/sofia_glue.c
+++ b/src/mod/endpoints/mod_sofia/sofia_glue.c
@@ -307,6 +307,10 @@ enum tport_tls_verify_policy sofia_glue_str2tls_verify_policy(const char * str){
 			ret |= TPTLS_VERIFY_SUBJECTS_OUT;
 		} else if (!strncasecmp(ptr_cur, "subjects_all",len)) {
 			ret |= TPTLS_VERIFY_SUBJECTS_ALL;
+		} else {
+			char el[32] = {0};
+			strncpy(el, ptr_cur, len < sizeof(el) ? len : sizeof(el) - 1);
+			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Invalid tls-verify-policy value: %s\n", el);
 		}
 		ptr_cur = ptr_next;
 	}