[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #5851: Delivery Service Supported TLS Versions Blueprint

[GitBox <gi...@apache.org>]

ocket8888 commented on a change in pull request #5851:
URL: https://github.com/apache/trafficcontrol/pull/5851#discussion_r635598069



##########
File path: blueprints/delivery.service.tls.versions.md
##########
@@ -0,0 +1,351 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Delivery Service TLS Versions
+
+## Problem Description
+Currently, supprted TLS versions cannot be configured. This means that a
+Delivery Service can have clients requesting its content over old, insecure
+versions of TLS, and Tenants controlling that Delivery Service have no way to
+force clients to use more recent versions.
+
+## Proposed Changes
+Changes to ATS in version 8.1 allow cache server configuration generation to
+produce configuration files that can effectively control the TLS versions
+allowed by a Delivery Service, causing clients using other versions to result
+in request failure. Currently, (in unreleased behavior on the master branch),
+this is implemented using a Delivery Service Profile Parameter. However,
+Parameters are notorious for being unvalidated, unstructured data that can be
+just obscure enough to escape notice, even when properly documented. For the
+best possible user, operator, and developer experiences, the data should be
+formally added to Delivery Service objects.
+
+## Data Model Impact
+Delivery Service objects will be augmented to include a set of allowed TLS
+versions for the Delivery Service's content. Specifically, They will be
+expanded to implement this interface:
+
+```typescript
+interface TLSVersionSpecifier {
+	tlsVersions: [string, ...Array<string>] | null;
+}
+```
+
+For those not super familiar with Typescript, this interface specifies a
+`tlsVersions` property that can be either null, or an array of N strings,
+where N is *at least one*. In other words, this can be null, but cannot be an
+empty array.
+
+The reason for this is best understood by first understanding what `null` means
+for this field. If `tlsVersions` is `null`, it means that no TLS version
+restrictions in place; the behavior is the same as today without the field, all
+TLS versions are implicitly supported.
+
+An empty array would seem to signify that no TLS versions are supported, which
+is an invalid configuration because then HTTPS content cannot be served - and
+if that's the intention, the Delivery Service's Protocol should be modified
+such that it doesn't serve HTTPs content.
+
+Speaking of which, the only valid value for the `tlsVersions` of a Delivery
+Service with a Protocol set to `0` (which is called "HTTP" in Traffic Portal)
+is `null`.
+
+## Component Impact
+This change primarily concerns Traffic Ops, Traffic Portal, and
+ORT/T3C/atstccfg.
+
+Traffic Router should not concern itself with validating the TLS versions used
+by routing requests for HTTP-routed and STEERING/CLIENT STEERING Delivery
+Services. Doing so wouldn't significantly increase content security since that
+would all be enforced by the caching layers anyway (even in the case of an
+`HTTP_NO_CACHE`-Type Delivery Service) and would reqire invasive, complex
+changes as well as a headache-inducing web of edge cases to handle for STEERING
+and CLIENT STEERING routing.
+
+### Traffic Portal Impact
+Traffic Portal's Delivery Services forms (all types) will need to add two
+controls. First, a checkbox that controls whether TLS Version settings will
+exist on the Delivery Service. Secondly, a list of TLS Versions to be permitted
+for the Delivery Service - shown if and only if the aforementioned checkbox is
+checked. Below is a sample of what this would look like while the box is
+unchecked:
+
+![](img/ds-tls-versions-sample.unchecked.png "Mockup of proposed TLS Version controls when restrictions are not placed")
+
+... and while the box *is* checked:
+
+![](img/ds-tls-versions-sample.checked.png "Mockup of proposed TLS Version controls when restrictions are placed")
+
+If desired, the markup used for that sample may be found in
+[Appendix A](#appendix-a).
+
+Traffic Portal should disallow the addition of a TLS version that is not a
+"whole match" of the regular expression `\d+\.\d+`, and should issue a warning
+if and when a TLS version is entered that is not known to exist (at the time of
+this writing, that would be any version besides 1.0, 1.1, 1.2, and 1.3). In
+keeping with the API restrictions, it MUST NOT disallow the addition of unknown
+protocol versions, to facilitate the ability of system administrators to
+quickly upgrade to a new protocol as it's released.
+
+A warning should also be issued if any Delivery Service is found to be a target
+of the Delivery Service being edited that does not support all of the TLS
+versions that the Delivery Service being edited itself does support, or if the
+Delivery Service being edited does not support all of the TLS versions supported
+by a Delivery Service of which it is a target, or if the Delivery Service being
+edited is the target of a Delivery Service which has other targets that support
+TLS versions not supported by the Delivery Service being edited.

Review comment:
       So should it be possible to set `tlsVersions` to not `null` on STEERING/CLIENT_STEERING, or should the API just disallow it?




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org