Precisely. tim
On Fri, Jul 13, 2012 at 11:24:37AM -0700, Gage Bystrom wrote: > Well if I understand Tim correctly you wouldn't need a CA. In the attack he > mentioned not once do you ever actually look at the ssl content. He's > talking about redirecting them to plain http and then setting the session > cookie and redirecting them back. Then when the victim logs on over ssl, > the session cookie isn't changed and is treated as authenticated. Obviously > since you set the cookie, you know what it is and can then impersonate > them. > > I also agree that it probably wouldn't take too much effort to make that > work, anything that can modify traffic ought to do the job easily enough > with some tweaking. If not it wouldn't take much effort to whip up > something specialized. > On Jul 13, 2012 11:15 AM, "Douglas Huff" <m...@jrbobdobbs.org> wrote: > > > > > On Jul 13, 2012, at 11:07, Tim <tim-secur...@sentinelchicken.org> wrote: > > > > > This is complicated, but it's not that much more complicated than what > > > existing MitM tools, such as sslstrip, already do. > > > > Better. I'm fairly certain this entire attack could be > > automated/orchestrated with mitmproxy with close to zero code changes. > > > > Only "hard" part is the procurement of a ca that will work on the target > > or finding some "behind the firewall" app to target that already uses a > > self-signed/invalid cert the users are used to clicking through. > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
