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.
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.
--Jacob
