-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 8/9/13 12:17 PM, Mark Eggers wrote: > On 8/9/2013 8: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. >> >>>> 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 was reading about the pineapple wifi mark iv the other day. It > looks to be a particularly powerful piece of pen testing equipment. > This tool in a coffee shop would probably be all you need to have a > good chance at e). > > In short, don't do banking (or other sensitive work) at a coffee > shop when the pages are a mix of HTTP and HTTPS. Lots of people will stupidly connect to any unencrypted WiFi when they are out and about. I'd say this is a fairly plausible attack vector. Note that unencrypted + encrypted traffic is not necessary. You can just look over someone's shoulder to see what bank they're using. These days in the US most people use one of only like 5 banks. (It's kind of sad.) Once you know the site that is being used, just browse there yourself and attempt to login: you can probably see what kind of authentication / session tracking is being used without tricking the target into revealing that kind of information to you via HTTP (i.e. without HTTPS). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRr1AAoJEBzwKT+lPKRYxHwP/2WZmt7P+gtsiZ2Qx/S+idmr xN+k/XHS4kaxWOBdo8sK3lzZYE9mB5ROtsuVYQQZ1WRJaQS0Vb09/VCJ4GnpOSFf SR9aThyAXCxnnxF2vviTZUL93Dwh0LM/HwbRGpjYy5Tns0+qXATwm1IBNK3jzarF Mvx2SOrMAGqiTEet9CqW/7yYQV31kFpLaZGiDsdJT6FM+mBG8OrVcYstBr0b6qXF LC2IILQshvHvcAUmAEDDPO8NRfgxCY+4uzY9M028DromKeliAQ7PO0KD4E3nErZZ xL5ysEgSKSahd+0a1QJRXvLccb4XRLL9GCcSP9/TvUzqbOahWUDrIHgLGJWZYAfS ql4nO2QLtVDfTdtgBUyuNQsn+AlJZHR96g/N7lHuxZU8fap5Auir8xFijWDRWrdn LfykGonHPZ75UDlOFQmMUPM/8H6AFbymw9R8ZhpbCMwEPAU/SqVARbCLAThIVQWN zrroWjVqMLdUTbdqvT3Xi9EnmXkPuszHGjqQRtVgt60MRRZ63bkM8+F2hnJGlSId VpUFi6RrK0wM4TFd2viGlW7SbSbl/vSHAPruAYzwAJvkI+g2QduW8HVV4lESyZ+T C9vVnz59BJwsokc5H3ykNCcnurkaWCBwEm70LTc9MQKlS8ICyOtKX31TugZvzPKv EiJZhuKGsOZR/+lf3ser =98t0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
