Hide Exact Nature of Server-side Errors from Clients

[ocket8888]

I'm submitting an

• [x] improvement request (usability, performance, tech debt, etc.)

Traffic Control components affected ...

• Traffic Control Client (Possibly)
• Traffic Ops

Current behavior:

Traffic Ops returns a variety of 5XX server-side errors to clients based on conditions on the server. The actual number, location and scenarios wherein these occur are unknown - though a simple grep for http\.Status and manual filtering should reveal them - but the best-known case is when the Perl server is unavailable, in which case the Go server returns a 502 BAD GATEWAY response.

Expected / new behavior:

In order to expose as little as possible information about the underlying ATC infrastructure to potential attackers, Traffic Ops should instead log specific information but always return the most generic server-side response error code: 500 INTERNAL SERVER ERROR.

[mitchell852]

@ocket8888 to research if this is still an issue w/ the api.

[ocket8888]

This is still a problem. DSRCs have an "update" route that returns a 501: https://github.com/apache/trafficcontrol/blob/3564c9654d4cd5f27f72d591e9197c4882d953a3/traffic_ops/traffic_ops_golang/deliveryservice/deliveryservices_required_capabilities.go#L167-L170

There are multiple scenarios where OAuth login can return a 502 response

Local user authentication can return a 503 response if it fails to check if the user is allowed to sign in

User authentication can return a 503 response if database connection times out

When a route is disabled in the routing blacklist a 503 response will be returned

/dbdump can return a 503 response if no pg_dump executable is found on the TO system

Fetching URI Signing keys for a Delivery Service can return a 503 if configuration for Riak is not properly set up

And those are just the cases where an HTTP status code > 500 is returned using its constant name in the net/http package. More usages may exist using literal numeric codes.

[mitchell852]

When a route is disabled in the routing blacklist a 503 response will be returned

is there a routing blacklist anymore now that Perl is gone?

[mitchell852]

do you want to create separate issues for each and label them as tech debt or something and we can close this one?

[ocket8888]

is there a routing blacklist anymore now that Perl is gone?

"fall back to Perl" and "blacklist" are separate concepts. The latter still exists.

do you want to create separate issues for each and label them as tech debt or something and we can close this one?

I don't think it really matters how they're tracked. They would all be fairly small changes to fix, so it doesn't seem totally necessary to split the issue up. If someone did that I'd have no problem with it - and then this could be closed - or alternatively I could add a checklist to this Issue that tracks each of them with a separate checkbox. It's not automatic like closing an issue with a PR, but still provides separate tracking for each instance of the issue, if that's desired.