Re: [vox] Starbucks and 802.11b
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox] Starbucks and 802.11b
On Thu, Feb 27, 2003 at 01:07:38PM -0800, email@example.com wrote:
> > On Thu, Feb 27, 2003 at 12:58:01PM -0800, firstname.lastname@example.org
> > wrote:
> >> And to top it off any jerk with dsniff will own the people that are
> >> willing to pay that much for insecure wireless.
> > Nope; they're not that stupid -- you have to authenticate over a
> > SSL-encrypted website (which is cross-platform) first, and then only
> > your data packets (authented via DHCPed IP and MAC, I'd assume) are
> > allowed through until you log out.
> I disagree.
> They have you auth, but their service isn't secure, aim, pop, imap etc
Oh, I see what you mean -- I thought you were only talking about your
authentication against the proxy. I'm not terribly worried about
someone armed with a packet sniffer, as I'm either dealing with data
that I know is insecure (web browsing), or I'm using encryption (SSH,
SSL, IPsec, etc...)
> Run them on any public network run by tmobile and then laugh.
> It's so stupid, it's funny!
T-Mobile can't be faulted for that, though -- it's up to the user to
provide security, not the network provider. Besides, most
> And then of course there is the fact that lots of people trust any
> security cert that comes up.
> So you can do a ssl mitm attack.
I'm interested in keeping things as legal as possible. *grin* But, yes,
in theory, I could set up a DHCP server on my laptop that sets up the
client to use it as a gateway, then use transparent proxying and NAT to
man-in-the-middle any SSL connection that comes through (including the
initial connection to the proxy). The problem with this attack is
1. Sure, they "might" accept any old certificate, but if they aren't
that stupid, then I'm screwed. Only way around this is to pay
Verisign for a valid certificate, which then ties you (evidence-wise)
to the connection.
2. I have to get to the client before the T-Mobile DHCP server does;
since this is firmware on the Starbucks AP, this isn't a given. If
the client gets DHCPed off of the T-Mobile AP, then I'm cut out of a
MITM attack. I could try impersonating the AP, but that would likely
toast the entire network.
It's also worth nothing that this is not a simple attack; it requires
knowledge of NAT, transparent proxies, DHCP, and an operating system
that will support all of these -- this rules out Joe Average Script
> It is trivial.
> To top it off if your stack is faster than theirs is you can do certian
> things with the same ip and mac while they are on.
> Small stuff that won't send tons of rst flags.
Even if it doesn't send tonnes of resets, there will still be a boatload
of collisions (remember, same MAC and IP), so the network stack is
likely to report that another computer is using the IP address (Windows
2K and later will do this, IIRC). Besides, I can't think of anything
worthwhile to do with such a small data-stream -- it certainly wouldn't
be usable for SSH or web-browsing. Encapsulating data in UDP might
work, but not for SSH, and you'd need a machine on the outside to handle
relaying data for you.
Don Werve <email@example.com> (Unix System Administrator)
Yorn desh born, der ritt de gitt der gue,
Orn desh, dee born desh, de umn bork! bork! bork!
vox mailing list