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>
In certain deployments it might be desirable to remove the User-Agent header from the SIP message.
Set the sofia profile parameter "user-agent-string" to "none" to suppress this header.
As an example of using mod_sofia's gateway parameter `contact-params`
we'd used the value `tport=tcp`. Looking around, it's clear this has
misled people into believing you can specify `tport=tcp` to make the
gateway use TCP or `tport=tls` to make the gateway use TLS. This does
not work.
The actual contact parameter is named `transport` rather than `tport`,
and you shouldn't use `transport` in `contact-params` because we
automatically add a `transport` to the Contact: based on the value of
`register-transport` (even if the gateway is set to not register).
It's clear why this would be confusing, so we'll just remove this as
an example.
In a sofia profile, you can now set the parameter tls-timeout to a
positive integer value which represents the maximum time in seconds
that OpenSSL will keep a TLS session (and its ephemeral keys) alive.
This value is passed to OpenSSL's SSL_CTX_set_timeout(3).
OpenSSL's default value is 300 seconds, but the relevant standard
(RFC 2246) suggests that much longer session lifetimes are
acceptable (it recommends values less than 24 hours).
Longer values can be useful for extending battery life on mobile
devices.
Signed-off-by: Travis Cross <tc@traviscross.com>
Sergey Safarov