]> git.ipfire.org Git - thirdparty/freeswitch.git/commitdiff
FS-7708: Fix docs on enabling cert CN/SAN validation
authorTravis Cross <tc@traviscross.com>
Tue, 26 May 2015 14:01:31 +0000 (14:01 +0000)
committerMichael Jerris <mike@jerris.com>
Fri, 26 Jun 2015 19:47:01 +0000 (15:47 -0400)
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
conf/vanilla/sip_profiles/external-ipv6.xml
conf/vanilla/sip_profiles/external.xml
conf/vanilla/sip_profiles/internal.xml
src/mod/endpoints/mod_sofia/conf/sofia.conf.xml
src/mod/endpoints/mod_sofia/sofia_glue.c

index 60266004a4e61803f3e78baeeef0dc13fb966c0f..952e6c78485b6d26434c6d8bceecf709f5addbbd 100644 (file)
@@ -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"/>
index 7dc5906c5f1eeba918080c04654bfa35bb9e6ee7..be70ff3b1e3e889b04285ed10baebe4a09d53567 100644 (file)
@@ -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"/>
index 6edc878c06687a4fc262fccd9bb0f50e09c2c6e0..dfc9504bcb6a22ac34bab35c6375652ad608586e 100644 (file)
@@ -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"/>
index 17887806011bd5645d3812d4c0d71c1680adcabc..ccc9893eb4f28800adb507739b71a8692e87d28b 100644 (file)
     <!-- 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"/>
index 2e1a849e41329f5602dbe24a7c0c0861425e8ce6..46095e9a6d2bf38287e2d0c9d718f35b58584c4e 100644 (file)
              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
index cfa01c34f2ca1c744d9f2f9c917511a2ba56e08f..bd77f6f5e61d5d067d190b8ce94f6ec82a5656fc 100644 (file)
@@ -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;
        }