Since we will want to pull this back sooner, I'll probably have to go through the "backwards compatibility" pain in any case.
On Thu, Oct 11, 2018 at 11:52 AM Leif Hedstrom <zw...@apache.org> wrote: > > > > 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? > > > > > >
