3 ms·

I'm not convinced that BREACH is less useful than the original CRIME TLS exploit. With the original CRIME POC, you could just disable TLS compression. Pow, prob

I'm not convinced that BREACH is less useful than the original CRIME TLS exploit. With the original CRIME POC, you could just disable TLS compression. Pow, problem solved. BREACH is far more insidious, because there is no "easy" solution for many people. Disabling HTTP compression is a huge performance hit. The alternative is auditing every single endpoint to ensure that it won't leak attacker data into the response, which is practically an impossible proposition. Sure, attackers have to do a bit more work to identify a vulnerable endpoint. But developers have to do exponentially more work locking down all exposed parts of their application. Not really a good tradeoff IMO. EDIT: there's the added bonus that BREACH stomps all over the ideal "isolation" between crypto and application code. In fact, BREACH may indicate that such isolation is inherently impossible: you can't write safe application code without knowledge of the crypto you're running on. EDIT 2: s/daunting/impossible/

sdevlin 13y ago
> The alternative is auditing every single endpoint to ensure that it won't leak attacker data into the response, I think you're underestimating how common this is. For example, view source on https://www.google.com/search?q=pajamas https://www.google.com/search?q=pajamas and look at how many times "pajamas" appears on the page. This is a simple example, but query string parameters (and other attacker-controlled data) get reflected in server responses all the time. Eliminating this behavior is not a realistic goal.
- AnIrishDuck 13y ago
  You're absolutely right. Perhaps "impossible" would be a better word than "daunting" in my OP.
JshWright 13y ago
It's harder to mitigate than CRIME, but CRIME was leaps and bounds more useful. Since you were guaranteed to have control over some reflected plaintext in the request, life was much easier. With BREACH, you have to first find a plaintext reflection, and there are certainly many page where one simply does not exist.

sdevlin 13y ago

> The alternative is auditing every single endpoint to ensure that it won't leak attacker data into the response, I think you're underestimating how common this is. For example, view source on https://www.google.com/search?q=pajamas https://www.google.com/search?q=pajamas and look at how many times "pajamas" appears on the page. This is a simple example, but query string parameters (and other attacker-controlled data) get reflected in server responses all the time. Eliminating this behavior is not a realistic goal.

AnIrishDuck 13y ago
You're absolutely right. Perhaps "impossible" would be a better word than "daunting" in my OP.

JshWright 13y ago

It's harder to mitigate than CRIME, but CRIME was leaps and bounds more useful. Since you were guaranteed to have control over some reflected plaintext in the request, life was much easier. With BREACH, you have to first find a plaintext reflection, and there are certainly many page where one simply does not exist.