Page MenuHomePhabricator

Evaluate ATS TLS stack
Closed, ResolvedPublic


Our current cp nodes are using nginx for TLS termination. Over time several patches have been added to our custom packaging of nginx regarding TLS:

We need to check what's the current status of ATS regarding these matters and if it can it be brought up to speed to use it as our TLS terminator

Event Timeline

Vgutierrez triaged this task as Medium priority.Apr 8 2019, 1:36 PM
Vgutierrez created this task.
Vgutierrez moved this task from Triage to TLS on the Traffic board.
  • 0100-dynamic-tls-records.patch - I don't think we ever managed to prove a significant benefit from this on initial deploy, but it's just one of those things that seemed like a "good idea" so long as it remained simple to leave it in. I'd be happy with dropping this initially and putting the ideas behind that patch (or even more-generalized than that patch) on the back burner for the future when we have more time.
  • 0660-version-too-low.patch - This was a very nginx-specific thing about not having nginx spam error messages, shouldn't need to port it at all.

Buster has OpenSSL 1.1.1b, so this affects ATS as shipped in Buster? Should we file a bug or does this only affect some ATS setups?

so I guess it's affected but right now I'm working under the assumption that we will use stretch in the cp nodes, using our own ATS packaging.
@ema can confirm that :)

Change 528716 had a related patch set uploaded (by Vgutierrez; owner: Vgutierrez):
[operations/debs/trafficserver@master] Backport prefetched OCSP stapling responses

Change 528716 merged by Vgutierrez:
[operations/debs/trafficserver@master] Backport required OCSP commits

Mentioned in SAL (#wikimedia-operations) [2019-08-09T07:31:45Z] <vgutierrez> uploaded trafficserver-8.0.3wm3 to (stretch) - T220383 T228135