sayotte
commented
3 years ago @rishabhpoddar as noted in Discord, a workaround for encryption would be putting an nginx or some other proxy in the middle. This doesn't necessarily cover server-authN, since the backend-SDKs don't have an explicit way to configure what CAs to trust (I imagine some of them would use the system store of trusted CAs, but that might not be consistent from one SDK/language to another).
In fairness, this whole issue can be completely sidestepped by more complex setups such as (minimally) stunnel on both ends or (maximally) a service mesh using something like Envoy+Istio. But for ease of adoption, it'd be better if this were solvable without the engineer having to learn an additional system.
🚀 Feature
As a security architect / person answerable for the security posture of a service, I want supertokens-core to support TLS for inbound connections, so that it can be deployed in a multi-host environment without sacrificing defense-in-depth should an attacker compromise any host inside the datacenter.
This is not a far-fetched concern: ARP spoofing is a trivial attack to intercept all traffic bound for a given host, or all traffic into/out of a subnet.
Acceptance criteria should be:
Implementation details
Encryption must be accomplished using TLS, with any certificate (including self-signed auto-generated).
Verifying authenticity of the server should be accomplished using a configurable TLS server certificate. The user can provide a certificate signed by a trusted CA, which the client can then verify. There would be a burden of adding support to the backend SDKs for enabling TLS connections (trivial to no work), and for configuring a trusted CA to verify certs against (perhaps a bit more work).
Verifying authenticity of the client may be accomplished using a client-certificate. At minimum the server should verify the certificate was signed by a trusted CA. For authorization the server could also compare the CN or SANs of the client-cert against a list of permitted clients; the user would need to configure this list and distribution of the corresponding certs. mTLS with client-certs would have very little impact on the API since the HTTP exchange would remain unchanged, although there would still be a burden of adding client-cert support to the backend SDKs.
Verifying authenticity of the client could instead be accomplished using some other mechanism such as a shared secret. This would have a larger impact on the API since this mechanism would need to be in-band in the HTTP exchange.