[API] Proposal for cleaning up the TLS server verify options

[Susan Hinrichs]

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?

[Steven R. Feltner]

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" <***@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.

[Leif Hedstrom]

Post by Steven R. Feltner
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

Post by Steven R. Feltner
I like the policy vs properties breakout. Allows for a lot of extensibility as we go forward.
Thanks,
Steven
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?

[Susan Hinrichs]

Since we will want to pull this back sooner, I'll probably have to go
through the "backwards compatibility" pain in any case.

Post by Steven R. Feltner

Post by Steven R. Feltner
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

Post by Steven R. Feltner
I like the policy vs properties breakout. Allows for a lot of

extensibility as we go forward.

Post by Steven R. Feltner
Thanks,
Steven
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

Post by Steven R. Feltner
log).
This global setting can be overridden in the ssl_server_name.yaml

file

Post by Steven R. Feltner
using the verify_origin_server parameter which can be set to NONE (no
verify), MODERATE (check but only log), and STRICT (verify and

enforce).

Post by Steven R. Feltner
In PR #4013 CrendKing identified a need to allow for the openssl

signature

Post by Steven R. Feltner
checking but bypassing the Traffic Server verification that the

requested

Post by Steven R. Feltner
SNI is in the certificate. They have their own logic for verifying

the

Post by Steven R. Feltner
validity of the name in the cert and could implement that in a

callback on

Post by Steven R. Feltner
the TS_SSL_SERVER_VERIFY_HOOK.
With another option to our enumeration, I propose rearranging our

verify

Post by Steven R. Feltner
options as follows.
Break the configuration into a policy component and a properties

component.

Post by Steven R. Feltner
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

Post by Steven R. Feltner
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.

Post by Steven R. Feltner
What are your thoughts on this?

[Susan Hinrichs]

I put up a PR with the code changes, docs, and tests.
https://github.com/apache/trafficserver/pull/4414

Post by Susan Hinrichs
Since we will want to pull this back sooner, I'll probably have to go
through the "backwards compatibility" pain in any case.

Post by Steven R. Feltner

Post by Steven R. Feltner
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

Post by Steven R. Feltner
I like the policy vs properties breakout. Allows for a lot of

extensibility as we go forward.

Post by Steven R. Feltner
Thanks,
Steven
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

Post by Steven R. Feltner
log).
This global setting can be overridden in the ssl_server_name.yaml

file

Post by Steven R. Feltner
using the verify_origin_server parameter which can be set to NONE (no
verify), MODERATE (check but only log), and STRICT (verify and

enforce).

Post by Steven R. Feltner
In PR #4013 CrendKing identified a need to allow for the openssl

signature

Post by Steven R. Feltner
checking but bypassing the Traffic Server verification that the

requested

Post by Steven R. Feltner
SNI is in the certificate. They have their own logic for verifying

the

Post by Steven R. Feltner
validity of the name in the cert and could implement that in a

callback on

Post by Steven R. Feltner
the TS_SSL_SERVER_VERIFY_HOOK.
With another option to our enumeration, I propose rearranging our

verify

Post by Steven R. Feltner
options as follows.
Break the configuration into a policy component and a properties

component.

Post by Steven R. Feltner
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

Post by Steven R. Feltner
the selinux nomenclature). The properties entry is a list of the
following: SIGNATURE, NAME, or ALL. As we come across more things

to

Post by Steven R. Feltner
check in the future the properties list could be expanded.
A similar change would be made for the ssl_server_name.yaml

attributes.

Post by Steven R. Feltner
What are your thoughts on this?