-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 8/9/13 11:10 AM, Mark Thomas wrote: > On 09/08/2013 15:28, Christopher Schultz wrote: >> Mark, >> >> On 8/9/13 9:14 AM, Mark Thomas wrote: >>> On 09/08/2013 14:50, Christopher Schultz wrote: >> >>>> It's too bad it took a researcher a year to figure out that >>>> compression of any kind makes encryption (where the attacker >>>> can force random probing attacks) weak. It's not like >>>> SSL+compression and SSL-compression+compression is that >>>> different. >> >>> It didn't. The original CRIME presentation covered this topic. >>> I fail to understand why such a fuss is being made of this >>> re-hashing. >> >> I wouldn't say this constitutes a "fuss". > > "fuss" was a reference to how some folks are reacting to this > "new" attack, "BREACH". First it isn't new, second it isn't (in my > view) practical. Fair enough. >>> The original CRIME presentation also (correctly) pointed out >>> that any attack based on this is entirely theoretical and not >>> currently at all practical. >> >> Coffee shop + XSS? Perhaps a stretch. > > To succeed, the attacker requires: > > a) The victim is using a site that uses HTTP-level compression on > responses b) The site echoes user input in HTTP response bodies c) > The response bodies contain a constant secret (eg. CSRF token) > > So far, not too hard. c) is a little unusual. Session IDs are > normally in cookie headers, CSRF tokens should change on every > request. That said, there are plenty of sites that meet a) to c). > > d) The attacker has the ability to view the victim's encrypted > traffic. e) The attacker has the ability to cause the victim to > send HTTP requests to the vulnerable web server. > > e) is where I think this attack becomes impractical. This may > change over time but at the moment the coffee shop scenario would > require social engineering the victim or subverting the router if > the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is > another option with mixed HTTP/HTTPS. I tend to agree: being able to both remotely monitor the victim's traffic *and* remotely-control the browser means that you already have quite a bit of control over the situation. Perhaps decrypting the SSL stream isn't the worst thing an attacker in such a position can accomplish. >> The point is that folks are starting to chip-away at certain >> aspects of TLS. Just like they did with hashing algorithms. MD5 >> was great when it came out. So was SSL. There's nothing wrong >> with looking toward the future, even if the current crop of >> problems aren't exactly catastrophic. > > Indeed. If only everyone was approaching this with the same sense > of perspective. I agree the attacks will only get better / easier / > more practical but right now there are some big obstacles and I > don't see any obvious roots to getting over them. Agreed. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRAUAAoJEBzwKT+lPKRYKMsP/3ye2X1m8oZGMxDfjhOxLr+B xRS1SycborjXnEhAXnGAx+U1jFDzKPWQ0AdDMd2o4NKPqS6jWJTQ37CBeXN+25y2 0+FxZKP9FwrY94qY/dCNHK70nuUda6hpcGcpWRc78swh+hUnBzB0ue52WaaWjTJH DfTPcRu1zvIeXj1zylIG4GebqKOH1+5P+NgL37+hnzoIwGmsgJ2FeVpAXELrrtZJ wOcYguKLv0NrqkAx7CvZDmtr6a4ZpZvmyXpVGJlaoi/ejmQzDvtZDOFlsBaYOMwc 4HsweP4mEi7Ms3QYBzn9naVFXr1x+saaoO75F0jnRGE9yLJXbkhGgmpLM/+arnhO /laV3ZMqHLXZYu+cmZvD/JsdL2liAaMPcwEB3c1ebFuTI8ro7+/7qlVx+H2inGew 2DIvWePjAXyKuudL8GqqHTcsbe6nrbpB41fqRyWCBSxtZwLbUfxgfjfXRQOfkX5e 88f2FmL7/BHq7YgO368rreZWx+RVze2SVv7nGm20M7LzEP6Dd2k7etca+K+KdS9L ndNs4yHAtK8328dPsCsIYwcI767Y/5qTV3UIV0Bz8YDfjSYZvDQYVlCQRHs1VA/A xisZptwRA1jZro3WrTlgzjdHfTOcxIYDaL65eZUXcjGgXB2T9YeIAfguf7PFK5wC I6LlkxLa23oMvDL7Z2+c =RJjz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
