Idiomatic approach to dealing with TLS termination?
Gabriella439 opened this issue · comments
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:
Lines 130 to 134 in 7896a03
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