Idiomatic approach to dealing with TLS termination?

[Gabriella439]

We ran into an interesting corner case at Awake Security and while we have an immediate internal work-around we wanted to discuss here what is the more idiomatic solution

The specific problem we ran into was the following scenario:

• An API service sitting behind an nghttpx proxy that is terminating TLS, meaning:
  • The proxy exposes a TLS-protected port
  • The proxy forwards requests to an unprotected API service port not guarded by TLS
• Users set up an SSH tunnel from localhost:somePort to the server
• The content security policy from this library blocks secure websockets of the form
  wss://localhost:somePort

They reason why is that the content-security middleware from this library is based on whether or not the request is using TLS. If the request doesn't use TLS then the connect-src field of the content-security policy is set to:

connect-src 'self' ws://localhost:somePort

... and if the request does use TLS then the content-security policy is set to:

connect-src 'self' wss://localhost:somePort

The relevant code is here:

csp/csp.go

Lines 130 to 134 in 7896a03

	proto := "ws"
	if r.TLS != nil {
	proto = "wss"
	}
	connectPolicy = fmt.Sprintf("%s %s://%s", connectPolicy, proto, r.Host)

When users create an SSH tunnel to localhost the 'self' whitelist doesn't apply and if the server receives a request that does not use TLS (because the proxy terminates TLS) then the content-security policy rejects secure websocket connections

The immediate workaround we have is to disable the conditional switch and always add both ws://localhost:somePort and wss://localhost:somePort to the content-security policy for all requests. However, that seems like overkill and we weren't sure if we should open up a pull request to do that. Is there a more robust way to support this use case?

Another possibility is to not handle this in the middleware layer at all and instead handle this in the proxy. In other words, since the proxy TLS terminates TLS then perhaps it should also rewrite the content-security policy to replace whitelisted insecure protocols with their secure counterparts