To close up some loose ends/confusion; On Mon, Jan 16, 2017 at 6:42 PM, Jacob Champion <champio...@gmail.com> wrote: > On 01/16/2017 04:06 PM, William A Rowe Jr wrote: >> >> Before we push this at users.. is there a concern that brotoli >> compression has similar dictionary or simply size based vulnerabilities >> as deflate? > > If you mean HTTP compression oracles (BREACH et al), then I would expect > *any* compression technique to be vulnerable, brotli included.
Looking deeper into this class of vulnerability, one of two things must be true; the request headers are encoded (al la TLS compression, which has been dropped from the TLS 1.3 spec), *or* the response body is dynamic and can be abused to decipher the response contents. So there is no issue with serving pre-compressed content, ever (since that is - by definition - static :) There is no issue compressing on the fly any static content. There will be significant risk to some dynamic responses on some sites. >> If so, maybe we teach both to step out of the way when SSL encryption >> filters are in place? > > Current guidance to avoid BREACH is still, AFAIK, to avoid situations where > third-party data is being sent in the same response as first-party secrets. > I don't think we have a way to know when this is happening; it's up to the > server admin to disable compression in dangerous situations. (If anyone > knows of an update to this, please jump in.) > > Disabling compression whenever TLS is enabled (assuming I've understood your > suggestion correctly) is IMO too broad a stroke, and will de-optimize sites > that have been correctly designed to avoid compression oracle attacks. Agreed. Note that Google decided against using T-E: br for any http:// traffic due to frequent proxy misconfiguration. /shrug - Firefox is willing and we have no reason to explicitly disable it. I concur with Evgeny Kotkov that an ABI stable dependency is appropriate before adding this to httpd 2.4.x - so far as I've read none have suggested this as an experimental addition to 2.4. Between this and the lack of any example in docs/conf/ and a complete mess of an example here it's obvious that this proposal is premature; http://httpd.apache.org/docs/trunk/mod/mod_brotli.html#precompressed (Looks like copy-paste errors). My open questions; has this been entirely reviewed in conjunction with h2? Will A-E: br,gzip,deflate axe all others from that list when deciding to enable brotli? (I presume not-yet.) Will gzip filter work where A-E: gzip was given without br, or are we ceasing to encode half of the web if the user elects to serve brotli compression? Looking at that precompression example, it seems like mod_brotli can be patched to avoid double-brotli if the user elected to treat static .br files as either a content-type or a transfer-encoding. We need some way for mod_deflate and mod_brotli to avoid stepping on each other's toes, the toes of any third-party encoding module, and on the administrator's explicit configuration, IMO, before this would be ready for a stable branch.
