4. Security Considerations

4. Security Considerations

The header fields described herein enable a TTRP and backend or origin server to function together as though, from the client's perspective, they are a single logical server-side deployment of HTTPS over a mutually authenticated TLS connection. However, use of the header fields outside that intended use case may undermine the protections afforded by TLS client certificate authentication. Therefore, steps such as those described below need to be taken to prevent unintended use, both in sending the header field and in relying on its value.

Producing and consuming the Client-Cert and Client-Cert-Chain header fields SHOULD be configurable options, respectively, in a TTRP and backend server (or in an individual application in that server). The default configuration for both should be to not use the header fields, thus requiring an "opt-in" to the functionality.

In order to prevent field injection, backend servers MUST only accept the Client-Cert and Client-Cert-Chain header fields from a trusted TTRP (or other proxy in a trusted path from the TTRP). A TTRP MUST sanitize the incoming request before forwarding it on by removing or overwriting any existing instances of the fields. Otherwise, arbitrary clients can control the field values as seen and used by the backend server. It is important to note that neglecting to prevent field injection does not "fail safe" in that the nominal functionality will still work as expected even when malicious actions are possible. As such, extra care is recommended in ensuring that proper field sanitation is in place.

The communication between a TTRP and backend server needs to be secured against eavesdropping and modification by unintended parties.

The configuration options and request sanitization are necessary functionalities of the respective servers. The other requirements can be met in a number of ways, which will vary based on specific deployments. The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the Client-Cert and Client-Cert-Chain header fields occurring only on that connection. Appendix B.3 of [HTTPSIG] gives one example of this with an application of HTTP Message Signatures. Alternatively, the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server. Other deployments that meet the requirements set forth herein are also possible.