4 ms·

gzip + ssl is still (and will always be) a risky choice, isn't it? Do any of the newer compression algorithms fix that problem?

• deathanatos 7y ago
  It depends. The problem was that SSL supported compression directly, so you could compress the encapsulated stream. What happens in HTTP is that, say the cookie header contained the user's session cookie, and the body was somewhat controllable by an attacker. (E.g., by making CORS requests in the background.) The attacker could repeat "Cookie: auth=a" many times; if your auth cookie started with "a", it would compress slightly better as both could get compressed together, things would be slightly faster, and an attacker could use timing information to discern that he'd gotten the first character correct, and move on to the second. See: https://en.wikipedia.org/wiki/CRIME https://en.wikipedia.org/wiki/CRIME HTTP compression being mentioned in the article only compresses the body. It's still possible to execute the same sort of attack situationally if there's some part of, say, a response body that an attacker can control and a part that response body that the attacker doesn't control and is sensitive and wants to know and somehow only has access to the timing information. While there is a Wikipedia article on this variant ("BREACH"), I think this is more informative: https://security.stackexchange.com/questions/20406/is-http-compression-safe https://security.stackexchange.com/questions/20406/is-http-c... ; it lists a decent example of trying to get at a CRSF token. But generally, JSON responses don't mix secret data + attacker controllable data, I feel, so compression should usually be okay. (And IME, it's typically done.) SSL/TLS compression should usually be left off, as that seems much easier to exploit.