> All in all, I am in favor of this being defined in one standard way, > in addition to secure communication between proxies and backends being > standardized — but this latter bit really seems like a separate problem. > > — Justin
-1 for devising a well known header +1 for a simple way to authenticate a reverse proxy with a web server With a well known name, in a attack this will get probed first. The well known header name doesn't guarantee a correct config. And if we have a new standard for sec headers that must be stripped automatically from inbound HTTP requests, we cannot expect that will get implemented in all reverse proxy software overnight. Because a correct config is not practical as the only line of defense, when we implemented mTLS we decided to add a length (>= 32 chars) and randomness check to the header config. I saw some concerns that this may cause deployment issues. Nobody has complained about that so far. https://connect2id.com/products/server/docs/config/core#op-tls-clientX509CertHeader Regarding mistyping, this can be an issue, but has little to no effect if a long random header gets misstyped (from the inbound strip directive). With a well known header this will result in a immediate security hole, which can theoretically go unnoticed. Here is an example Apache httpd config, to illustrate my point: RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "" RequestHeader set Sec-Client-X509-Cert-liede5vaePeeMiYie0xu2jaudauleing "%{SSL_CLIENT_CERT}s" (the first line strips the inbound headers) Vladimir -- Vladimir Dzhuvinov
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
