2

Correct me if I am wrong: If you use https, you communication with a server is secure because it is encrypted. If my computer is connected to a wireless network and someone can see all the raw data/traffic between me and the wireless router, then they only see encrypted communication. The only thing they can see is what website/ip address that I connected to.

Is this correct?

I have heard a couple of times now that you still really shouldn't be accessing your bank account at a coffee shop becuase hackers can "do things" unless you use a VPN. This is, for example, mentioned in this Youtube video.

In the video linked about it is mentioned that an attacker can use devices and techniques to actually get a lot of information.

My questions are:

  1. What types of devices and general methods can be used to gain this information?
  2. What type of information can the attacker extract? If the traffic is encrypted, how can the attacker see any of that communication? Can they, for example, see the balance on my account?
Thomas
  • 3,861
  • 4
  • 22
  • 26
  • 1
    https://security.stackexchange.com/search?q=sslstrip – billc.cn Nov 30 '16 at 16:00
  • I'd be more inclined to think that SSL isn't necessarily what people refer to when they discuss potential vulnerabilities at coffee shops. –  Nov 30 '16 at 16:00

3 Answers3

3

They are awfully vague in the linked video, so no real guidance there. I could think of the following risks:

  • Even if you use HTTPS, the domains you visit will be visible to the eavesdropper. You might not want the world to know about all the domains you visit...
  • Sure, everything is fine as long as you use HTTPS. But are you actually using it? SSLStrip is a real thing, and unless you trust yourself to check that the connection is secure every single time you could easily fall for it.
  • In theory, the bad guy could have come across a rogue certificate somehow or there could be some bug in your browsers TLS implementation. While not common, these things are not unheard of.
  • There are known vulnerabilities (such as POODLE, CRIME, and BEAST) in older SSL cipher suits. But if you use a modern browser this should not be a problem (and I am not sure it would be even if you use an old one).

Of these four points, the first two are the only ones I would really worry about. But the first one doesn't really apply to banking, and the second can be handled by just checking the connection. So while I wouldn't do online banking in a coffee shop unless I really had to for some reason, it is not the end of the world if you do it.

Also note that the show you linked to disclose that they are sponsored by a VPN company on their homepage.

I should also mention there might be legal issues involved here - is your bank willing to pay you back in case your account is hijacked if you have accessed it over coffee shop Wi-Fi, even if the reason your account was hijacked has nothing to do with it?

Anders
  • 65,052
  • 24
  • 180
  • 218
  • 1
    *"Sure, everything is fine as long as you use HTTPS. But are you actually using it?"* Having HTTPS Everywhere installed and turning on its *Block all unencrypted requests* mode can be useful. – user Nov 30 '16 at 22:03
2

HTTPS does encrypt the communication from one point to another. So if the two points are your device (laptop/phone) and the other point is your bank, that information is encrypted. However, it is fairly trivial to setup a man in the middle attack on open wifi. The attacker could setup a fake wifi access point with the same SSID. If you connect to that the attacker could then look at much of your traffic, and could allow the attacker to be the second point where your encryption takes place.

Now, modern browsers would likely identify any SSL certificates used in this as a mismatch and either warn or block.

Aside from this there are various other pieces of information that be gathered in this method without a MiTM attack on the SSL encryption. Banks are notorious for less than optimal application development standards and other attacks such as session hijacking or information leakage could also occur.

An attacker could also use the MiTM attack to force you to a fake webpage that looks like the bank account sign in page. They could then ask you to enter your username and password and redirect you to the legitimate site. You may just think something went wrong, but then they capture your credentials. Social engineering in this scenario is more likely than actually snooping on SSL.

The wifi pineapple is one specific example of how this could be accomplished. You can use SSLStrip to try and force users to non SSL sites. https://www.troyhunt.com/the-beginners-guide-to-breaking-website/

Generally, if I don't have control and or I am sharing a connection with other people that I don't control, I am not going to access any sensitive information on that network. I won't even access my financial information on my phone unless I am on my phone wifi.

0

There are man in the middle attacks that can be performed, there are also ways to prevent them.

First is attacking how you get to the website. if you go to http://bank.example and either get redirected to https://bank.example or click a link to go to https://bank.example/login then the http://bank.example data could be changed so that you dont ever get a link/redirect to get to a https page and the middle man pretends to be http://bank.example and serves you the information they get from https://bank.example and sends everything you send to them to the bank. This can be mitigated by typing https://bank.example.

The other way is more difficult but sill possible. If the middle man can get a valid certificate for https://bank.example then they can sit in the middle description what the bank sends to them with the bank cert and then encrypting it with their cert and sending it to you and then doing the opposite when you send the bank data. The best mitigation you can do for this is partly being very limited (there are hundreds and you dont use them all) on the CAs you have as trusted. Mitigation that the bank can do is using HPKP and HSTS which are both ways of your computer knowing if the cert is an authorized cert from the site.

What types of devices and general methods can be used to gain this information?

A computer, nothing else is needed but it helps if they own the network but that can also be done with a computer

What type of information can the attacker extract? If the traffic is encrypted, how can the attacker see any of that communication? Can they, for example, see the balance on my account?

using the attacks above, they can see anything as in both cases they can decrypt the data.

user
  • 7,700
  • 2
  • 30
  • 54
Topher Brink
  • 1,629
  • 11
  • 13
  • 1
    Getting a valid certificate for "bank.com" is not, in fact, generally possible for a coffee shop attacker. If it were merely "difficult but still possible" than TLS would be utterly broken. There are of course vulnerabilities that surface in the certificate issuance process from time to time, (fairly regularly, in fact) but not typically in a way that would be useful to a coffee shop attacker. – Xander Nov 30 '16 at 16:16
  • can i point you to StartEncrypt which is a lets encrypt clone that would easily create certs for any domain that you could manipulate a 301,307 or 308 redirect for. something that is fairly trivial. – Topher Brink Nov 30 '16 at 17:21
  • StartEncrypt no longer exists. Even when it did exist, there was no guarantee that bank.com specifically would have a vulnerability that would allow this particular exploit, and certainly no guarantee that the attacker would both know about it and have already gen'ed a cert for bank.com. This is where the "difficult, but still possible" scenario falls over. Yes, in theory a weakness in the CA infrastructure may allow the pieces for this attack to work to exist, but in practice, the window of opportunity to exploit them doesn't exist. It isn't "difficult", but in fact not generally possible. – Xander Nov 30 '16 at 17:44
  • 1
    HSTS is not about whether the certificate is "authorized". HSTS is simply a way of telling a browser *that knows about it from before* to refuse to complete the HTTPS connection if there is a security-related problem; without preloading, it can be stripped by a MITM under certain circumstances. HPKP has a somewhat similar bootstrapping problem. (In both cases, if you are using your own computer, it shouldn't be too bad.) DANE can help, however, but only if your resolver or perhaps even the browser itself actually does proper DNSSEC. Not saying either is useless; just to know *how they help.* – user Nov 30 '16 at 22:08