Re: [PLUG] https and wireless computing

["Toby DiPasquale" <toby@cbcg.net>]

On Wed, Dec 24, 2008 at 12:48 PM, edmond rodriguez <erodrig_97@yahoo.com> wrote:
> After a PLUG West meeting we were discussing wireless computing.  I had mentioned that I never worried too much about doing secure https type stuff, even on an open wireless network, as https: schemes take care of the security.
>
> Another mentioned that in an extreme perhaps unlikely case (but still possible), a "man in the middle" could intercept the pass phrase negotiation that goes on at the beginning of a https: session, and therefore continue from there using the established connection.
>
> I have been thinking about this for a while, and though I don't know the minute details of the process, I understand the the first stage of https negotiation uses private and public keys to negotiate a password for the next stage (a faster encryption scheme).
>
> So how can anything be "intercepted".   The client and the server each have their own private keys, which the man in the middle will never know.  So how could the man in the middle decrypt the negotiated passphrases being used without having anyone's private keys?   I have not googled much about this and only going by some things I learned about two or three ago.
>
> Of course I am sure the risk of computing on an open wireless network is greater than a secure and/or wired network.  But is using https on an open wireless network very vulnerable?

If the man-in-the-middle were able to spoof the DNS or IP address of
the site you're looking to go to, or more likely, spoof your upstream
router via something like ARP poisoning, then they could attempt to
perpetrate a MITM SSL attack. This involves the attacker becoming one
side of two SSL connections: they would become the server for you (the
"victim") and the client for the real server. In this way, they would
proxy the traffic back and forth to give the appearance of a
legitimate session, all the while seeing unencrypted data on the
attacker's box in between decrypt/encrypt proxying.

There are two problems with this attack working in real life, however:

1. Browsers check the validity of SSL certificates against their
database of trusted CA certificates. If the attacker is using a
self-signed SSL cert, or even one signed by a trusted third-party but
for a different domain than you are attempting to go to, you will see
the "This certificate does not match the domain!" warning in your
browser, alerting you to the attack.

2. While DNS spoofing is somewhat possible, IP spoofing is difficult
to pull off in real life and I can't imagine that ARP poisoning could
work on a wireless link. This is because ARP poisoning requires that
the victim *only receive* the ARP responses from the attacker, not the
real source, and there's no way to ensure that on a wireless link. IP
spoofing is difficult for similar reasons: the computer with that IP
"for real" could very well respond before the attacker.

In short, your real-world exposure to this particular attack is very
small, at best. Does this answer your question?

-- 
Toby DiPasquale
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug