I put up a PR with the code changes, docs, and tests. https://github.com/apache/trafficserver/pull/4414
On Thu, Oct 11, 2018 at 1:16 PM Susan Hinrichs <shinr...@oath.com> wrote: > 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? >> > >> > >> >>
