15

If someone is using an insecure wireless connection (for example a hot spot in a coffee shop) does it pose a threat even if the person is using a secure application layer protocol? What I mean by secure application layer protocol is HTTPS, sftp, ssh etc. In this article, it is claimed that credit card numbers can be compromised, but would this be the case even if using HTTPS?

If I connect to a non-password protected wireless signal and use the Facebook app on my mobile phone, is it easy to get my Facebook password?

Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
Celeritas
  • 10,039
  • 22
  • 77
  • 144
  • Seems like a duplicate of [Does an established ssl connection mean a line is really secure](http://security.stackexchange.com/q/5/971) and [How secure is SSL?](http://security.stackexchange.com/q/5167/971). As far as I can tell, the answers there already cover everything. – D.W. Jul 24 '12 at 21:36
  • Advice on [How to use public WiFi safely?](http://security.stackexchange.com/q/37597/32746) may also be relevant. – WhiteWinterWolf Jan 24 '16 at 14:44

5 Answers5

8

but if I rely on HTTPS (assuming a valid certificate) for all sensitive browsing, (banking, social media, e-mail, etc.) then is there still an issue?

Yes and no. It has been demonstrated that HTTPS can be circumvented, giving the user almost no clue that this happened. You can read more about this here: SSLSTRIP

On the same site you can read about a vulnerability that IE had which made HTTPS not secure (IE Basic Constraints vulnerability. Even if this vulnerability has ever since been patched, this shows that even if HTTPS is secure in itselft, one of its implementations can be broken and therefore make you vulnerable to an attack.

Finally, this article explains five ways in which you could break HTTPS.

This doesn't mean of course that HTTPS is not secure or that it's useless, far from it, but you shouldn't feel 100% safe when you are using it.

Also, I know that it is as well trivial to obtain a user's MAC address, but I am not aware of any dangers associated with this. If I understand correctly, a MAC address is no different from a physical address, and poses no harm in the wrong hands.

It can indeed be a problem. There is one type of attack, called ARP spoofing, which allows an attacker to impersonate another computer on the LAN, thereby receiving all the packets originally addressed to the legitimate user.

This is a little different from the scenario you are picturing (obtaining another user's MAC address), because here the attacker tries to associate its own MAC address to the IP address of the victim, but it's just to show you that MAC addresses can be used to attack.

Open ports are dangerous, is this why? In my specific case, I use things like MAMP, could this be a vulnerability if I were to use it while connected?

The answer in the link you posted is very good. Yes, you are more vulnerable than you would be without leaving that port open, because it's simply another way through which a malicious user could attack you.

But more and more I am starting to think that with the proper counter-measures, using an open network can be no different to using a WPA/WPA2 encrypted network.

It is different, because if you encrypt your network, an attacker would first need to enter your network. If the network is properly encrypted, this could mean a huge work for the attacker, who could then simply decide that it's not worth it :)

Assuming that I don't care about others mooching off of my internet, what are the downfalls?

As Lucas pointed out, you are responsible for your network. Suppose that some kind of illegal activities take place on your private home network, you are the one who will be held responsible (it already happened). It would be difficult, at this point, to prove that you were not involved.

user1301428
  • 1,927
  • 1
  • 23
  • 28
8

An attacker sharing the wireless network can definitely pose a threat even when you are apparently communicating securely.

There is a great commercial wireless penetration test tool titled Silica that can do much of what you alluded to (i.e. Passively hijack web application sessions for email, social networking and Intranet sites.).

enter image description here

Regarding Facebook or other mobile phone applications, it depends on the applications being properly configured to communicate securely over the network.

Facebook's Help Center states:

Facebook always posts to a secure page when users are logging in and employs industry standard encryption. This may not always be apparent from the URL (web address), but rest assured our logins are secure.

But that doesn't mean your active sessions are safe - you could also become a victim by accepting a rogue SSL certificate by any number of clever means, again, allowing an attacker full visibility.

Michal Zalewski has a great blog entry titled Unencrypted public wifi should die that reveals a number of additional risks.

The best advice is still to use a VPN connection anytime you are using public wifi.

Tate Hansen
  • 13,714
  • 3
  • 40
  • 83
  • 3
    which web-browser negotiates NULL or 40 bits encryption by default? – curiousguy Jul 18 '12 at 07:08
  • 1
    I consider that the lack of answer to mean that the part about HTTPS was pure FUD. – curiousguy Jul 24 '12 at 17:46
  • good question, I haven’t done such research, but the data here summarizes browser support from 2011 http://www9.atwiki.jp/kurushima/pub/pkimisc/SSLTLS_CipherSuite_Support_Table_.html, though I guess a black swan can appear (https://twitter.com/ivanristic/status/8555011235). More interesting I imagine is all the custom mobile apps that connect via https to servers (devs forgetting they configured setValidatesSecureCertificate:NO and/or using null ciphers for debugging?) – Tate Hansen Aug 09 '12 at 07:57
  • nonethelesss, removed the content to make you happy curiousguy! – Tate Hansen Aug 09 '12 at 07:59
5
  1. No probably not unless they do SSL spoofing after rerouting some of the traffic to them. But then the users will still get SSL mismatches. So no they will be okay.
  2. I don't think so. Except maybe using the MAC to do an attack. (pretend to be him)
  3. That's why you should put those computers on a different subnet.
  4. That's true, but don't forget you are still responsible for your network. Make sure you have a policy people need to accept. If someone carries out attacks on other people through your network, they might come knocking on your door.

Make sure you block everything that's not necessary. You don't want Torrents. Implement a form of bandwidth shaping so no single user can monopolize the network.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
2

TL;DR:

Whether or not your Facebook account in particular is vulnerable on an unencrypted Wi-Fi network greatly depends on how your Facebook app connects to the Facebook servers, even if it is using HTTPS.

Stil, there are other concerns to be mindful of on public Wi-Fi networks - encrypted or not. The best advice is to avoid these networks where possible. Use a VPN for your Internet access, if you must connect via public Wi-Fi.


If I connect to a non-password protected wireless signal and use the Facebook app on my mobile phone is it easy to get my Facebook password?

In short, the answer is it depends.

First, are you sure your phone's Facebook app uses HTTPS? If it doesn't, then your credentials and data are being sent in the clear.

Second, does the Facebook app use HTTPS only for login or does it handle all transactions through HTTPS? If the former, your session cookie is probably being sent in the clear - nearly equivalent to your login credentials.

Third, does the Facebook app support and use strong ciphers for its SSL/TLS connections? If not, the data may be as weakly protected (or worse) as if it was in the clear on a WEP network.

Fourth, does the Facebook app perform validation of Facebook's certificate before establishing a connection and will it give an error or refuse the connection if the certificate is invalid? If not, you could fall victim to a man-in-the-middle attack via an SSL proxy.

There are probably more weaknesses to consider that could still expose your Facebook credentials on an open wireless network, but the checklist above should help you avoid most attacks.

However, it should be noted that you are still putting your computer (or phone, tablet, etc.) in a more vulnerable state when connecting to any public network. At home, your first line of defense from untrusted systems is your router. Most routers have built-in firewalls, and their NAT functions also make attacks targeted at your system much more difficult. Once you've connected to a public network though, your system is locally reachable by every other system connected to that network - and, since the owners of these systems are total strangers, those systems are by nature untrusted.

That risk is essentially the same whether the public network is encrypted or not. Lack of encryption and/or authentication on the wireless network just means that the barrier for entry to it is effectively nil. I discuss this issue a little bit more in my answer regarding password-protected free Wi-Fi networks.

It is still worth stating that just because you're on a local network of untrusted systems, it doesn't mean that those systems have unfettered access to yours. Your system's local firewall and other protections still have to be compromised for that to happen. However, it does mean that users of those untrusted systems can break into yours much easier than a random hacker on the Internet.

All of these concerns can be greatly mitigated with a VPN that tunnels all network activity to your trusted provider, and does not allow your system to accept connections from others on the local network.

Iszi
  • 26,997
  • 18
  • 98
  • 163
0

If someone is using an insecure wireless connection (for example a hot spot in a coffee shop) does it posse a threat even if the person is using a secure application layer protocol?

It should not - this is by definition of a "secure application layer protocol".

If a so called "secure application layer protocol" cannot be used over an insecure link, it just means it is not a secure protocol.

But some sites, like stackexchange.com, only offer HTTPS for the login phase (for password protection), when you are logged in you go back to HTTP, so your cookies travel in clear-text and someone else could use your SE account.

No e-banking should be designed that way, of course: e-banking, and e-commerce should be only done over HTTPS.

If the web-application sometimes uses HTTPS and sometimes reverts back to HTTP, the privacy and integrity of exchanges could be compromised.

If your browser implementation of TLS has flaws, it could be attacked.

If you accept unverified TLS certificates, the TLS session integrity can be compromised.

See also: BEAST

Regarding the referenced article

In fact, many internet service providers include a clause in your contract that holds you responsible for any illegal activities that occur on your connection.

The contract with your ISP does not define your legal responsibility for illegal activities. The law defines your legal responsibility.

The clause in the contract with your ISP ("you are responsible...") just says that the ISP will consider that any action against the ToS (Term of Service) using your connexion allows them to terminate the contract (they cannot prove it is you who initiated this particular action, and they do not care).

Also, once an intruder has access to your home network, they have access to everything you have stored on any computers on that network and anything you do online.

This is utterly wrong and just absurd. Access to a network does not imply access to every file on every computer connected to the network. Or any Internet connected computer would be open to every other Internet connected computer.

An intruder, once inside can access your tax documents, financial records, online banking information, credit card numbers, emails, usernames and passwords, and even where you are going online.

And it goes on...

(At this point, I just stop reading.)

Just disregard such tabloid stuff, as I do.

curiousguy
  • 5,028
  • 3
  • 25
  • 27
  • While the cited portions of the article regarding access to data on your home network are slightly exaggerated, they're not to be completely ignored. Systems on the local network would have a *much* easier time obtaining access to your system and/or your network traffic than any system on the Internet. Also, while you may not ultimately be held responsible for the activities of malicious users on your network (this may vary by jurisdiction), you could still find your door broken down by a SWAT team before they figure out you're not the hacker/terrorist they're looking for. It's happened. – Iszi Jul 18 '12 at 14:49
  • @Iszi "_While the cited portions of the article regarding access to data on your home network are slightly exaggerated, they're not to be completely ignored._" "You are going a die horribly if you do that" articles are hardly helpful. "_Also, while you may not ultimately be held responsible for the activities of malicious users on your network (this may vary by jurisdiction),_" my point exactly: it varies by **jurisdiction**, not by ISP. – curiousguy Jul 18 '12 at 20:54
  • "_you could still find your door broken down by a SWAT team before they figure out you're not the hacker/terrorist they're looking for._" I am not telling people to set-up an open Wifi AP. I think your comment is more useful than the linked article: it clearly points out a real issue. – curiousguy Jul 18 '12 at 20:57
  • @Iszi "_you could still find your door broken down by a SWAT team before they figure out you're not the hacker/terrorist they're looking for._" This was not the subject at all. The question is about **using** a public AP, not setting-up one. I was merely pointing out that **the linked article is very confused about legal issues** ("ISP makes you responsible" part), so it should not be taken a reliable source. I was not telling people to open their own Wifi. (Or telling people to do anything _other_ than disregarding silly articles.) – curiousguy Jul 24 '12 at 20:30