Re: [PLUG] https and wireless computing

[bergman@merctech.com]

In the message dated: Wed, 24 Dec 2008 14:24:21 EST,
The pithy ruminations from Gordon Dexter on 
<Re: [PLUG] https and wireless computing> were:
=> No, a man-in-the-middle attack is not possible using HTTPS.  The reason 

It is possible, but there are (as you point out) warnings or other indications 
that something is wrong. Unfortunately, most people don't recognize or 
understand those indications, or ignore the warning.

    [SNIP!]

=> 
=> If the common name and the domain name don't match, browsers will 
=> generate a scary-looking warning that there might be something nefarious 
=> going on.  In most cases it's a poorly-configured website, or perhaps 

Right. The problem is that most people simply accept the warning and proceed.

Another problem [3] is that a MITM machine can present data from or redirect to
a phishing site that is skinned to appear to match the real site, rather than
try ing to intercept the SSL traffic itself.

For example, consider this exchange:

                                             
[V] = victim
[E] = evil site
[MiTM] = attacker
[B] = bank                    
                                                                 
     [V] https://mybank.com --> [MiTM] --> [E] http://my.bank.com
    		 Victim attempts to connect to https://mybank.com
                 MiTM redirects traffic to http://my.bank.com (no SSL cert
		warning)

     [V] <-- [MiTM] <-- [E] http://my.bank.com
    		 Evil sends back phishing site skinned to look like mybank.com
                                                                 
     [V] http://my.bank.com/login --> [MiTM] --> [E]
    		Victim enters login/password information,
		Evil records login info

     [V] <-- [MiTM] <-- [E] http://my.bank.com/retry
		Evil sends back phishing site skinned to look like failed
		login page from mybank.com all links on the page point
		to the real mybank.com page

     [V] https://mybank.com/retry --> [MiTM]
		 Victim clicks on "retry". The MiTM (using techniques
		 from stateful firewalls) notes that the Victim has
		 been sent to Evil already now gets out of the middle
		 (sending a refresh to the Victim and then reconfiguring
		 itself to stop intercepting traffic).

     [V] https://mybank.com/retry <--> [B] https://mybank.com
     		 Normal banking session continues without MiTM
                                    

How many people would notice that the first login screen doesn't have an SSL
connection, or that there's an "extra" refresh?

This type of attack becomes much easier if the MiTM is actually the wireless
AP....

Mark

References

[1] http://news.netcraft.com/archives/2005/12/28/more_than_450_phishing_attacks_used_ssl_in_2005.html

[2] http://www.darkreading.com/security/management/showArticle.jhtml?articleID=208804464

[3] http://www.straightsectalk.com/?p=46

[4] http://www.securityfocus.com/columnists/407

=> 
=> --Gordon
=> 
=> edmond rodriguez 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 http
=> s: 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: s
=> ession, 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 t
=> he 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?
=> > ___________________________________________________________________________
=> > 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
=> >   
=> 
=> ___________________________________________________________________________
=> 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
=> 







___________________________________________________________________________
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