Would this fall into the new "small, safe feature additions" policy in the
Slightly Modified Release Process for LTS Support, and be released in a
forthcoming 8.x release? Or, will this have to wait for 9.0?
I like the policy vs properties breakout. Allows for a lot of extensibility as
we go forward.
Thanks,
Steven
On 10/10/18, 3:30 PM, "Susan Hinrichs" <shinr...@apache.org> wrote:
Currently there is a records.config entry,
proxy.config.ssl.client.verify.server,
which can be set to 0 (no verify), 1 (strict verify), or 2 (check but only
log).
This global setting can be overridden in the ssl_server_name.yaml file
using the verify_origin_server parameter which can be set to NONE (no
verify), MODERATE (check but only log), and STRICT (verify and enforce).
In PR #4013 CrendKing identified a need to allow for the openssl signature
checking but bypassing the Traffic Server verification that the requested
SNI is in the certificate. They have their own logic for verifying the
validity of the name in the cert and could implement that in a callback on
the TS_SSL_SERVER_VERIFY_HOOK.
With another option to our enumeration, I propose rearranging our verify
options as follows.
Break the configuration into a policy component and a properties component.
In records.config have proxy.config.ssl.client.verify.server.policy
and proxy.config.ssl.client.verify.server.properties.
The policy entry is one of DISABLED, PERMISSIVE, and ENFORCING (following
the selinux nomenclature). The properties entry is a list of the
following: SIGNATURE, NAME, or ALL. As we come across more things to
check in the future the properties list could be expanded.
A similar change would be made for the ssl_server_name.yaml attributes.
What are your thoughts on this?
