> On Oct 11, 2018, at 9:23 AM, Steven R. Feltner <sfelt...@godaddy.com> wrote:
>
> 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?
If it can be done in a compatible way, seems like it could definitely go into
8.1.0. That might imply keeping both the old and the new settings though, and
default to the old behavior.
— Leif
>
> 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?
>
>
