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>
We use the transport of the Contact header of the remote UAC to decide
which of our own Contact addresses we should use when replying to a
SUBSCRIBE or sending a presence NOTIFY.
If TLS is not enabled on a Sofia profile, then the TLS Contacts for
that profile are NULL. Unfortunately we were using these NULL values
uncritically when the remote UAC sent us a Contact header with a TLS
transport and our own Sofia profile did not have TLS enabled.
With this commit we fall back to our TCP Contact address when the
remote Contact is TLS and our Sofia profile does not have TLS enabled.
When all-reg-options-ping is enabled, this adds a new custom event to mod_sofia
(sofia::sip_user_state), which is fired when a client stops responding to such
ping packets (or when it is reachable again).
Add two needed new columns to the sip_registrations table:
- ping_status, which is "Reachable" or "Unreachable" depending on the client
status;
- ping_count, which tracks the number of ping responses received and is used
to provide some kind of hysteresis to avoid firing the event in case of
transitory network failures.
Then ping_count is checked against two threshold values, sip-user-ping-min
and sip-user-ping-max in a similar fashion as the ping-{max,min} options for
the gateways. These two values are configurable in the profile's xml
configuration file.
Also, if unregister-on-options-fail is enabled, the client is unregistered
based on the number of OPTIONS failure which is also checked against the
sip-user-ping-{min,max} values.
These all were set before but now are disabled by default because they are not proper to have enabled without a good reason.
tcp-unreg-on-socket-close
If registration is TCP or TLS and socket connection is interrupted, unregister the client.
tcp-always-nat
Treat all TCP connections as NATTED, this causes all traffic back to the phone to reuse the existing TCP socket but may
cause problems when not used with TCP keepalive.
tls-always-nat
Same as tcp-always-nat but only for TLS connections.
Travis Cross