This is a good story. How about requiring reverse proxies to automatically scrub all inbound HTTP headers that start with "Sec-"?
If a sec header has the format "Sec-[NAME]-[random-chars]" we get: * The "Sec-" prefix will cause new compliant reserve proxies to automatically scrub the inbound HTTP header. * The NAME part still makes the header easily identifiable (I think Rich Salz had this concern). * The random chars part, potentially optional, will provide a line of defence against config errors in old legacy reverse proxies. All concerns should then get covered. Vladimir On 31/10/2019 12:48, Hans Zandbelt wrote: > the way I see this is that stripping and setting the headers must be > part of the implementation of the protocol itself, it should not be > something left to a non-atomic piece of configuration by an > administrator; I implemented it like this in the Apache implementation > of Brian's TTRP spec [1] and have been doing this for the OIDC and > OAuth Apache modules that set headers for backends to consume [2]; and > yes, I have made mistakes [3], but IMHO it should not be a problem to > use a well known header and make the implementer (not the admin) get > it right by pointing this out in the spec, as is done for many other > pitfalls > > Hans. > > [1] > https://github.com/zmartzone/mod_token_binding/blob/master/src/mod_token_binding.c#L481-L483 > [2] > https://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_openidc.c#L164-L175 > [3] https://www.cvedetails.com/cve/CVE-2017-6413/ > > On Thu, Oct 31, 2019 at 11:37 AM Vladimir Dzhuvinov > <[email protected] <mailto:[email protected]>> wrote: > >> 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > [email protected] <mailto:[email protected]> > ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu> -- Vladimir Dzhuvinov
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
