5

With passwordless public WiFi hotspots, it's easy to demonstrate that packets can be sniffed and (in the case of non-HTTPS traffic) private information gained. While the long-term solution would be to completely implement HTTPS and deprecate HTTP, why is there not a way to encrypt traffic? Traffic traveling through an SSH tunnel is encrypted, so why can the device not negotiate an encrypted transmission with the hotspot so that even HTTP traffic is unreadable? Does such a system/protocol exist, or why has no-one developed one?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Luke Moll
  • 161
  • 4
  • The WiFi solution would only protect the traffic local to the AP. Can you explain how WPA2 is not the solution that you're looking for? – schroeder Jan 25 '17 at 18:57
  • @schroeder is this describing a WPA2 network? I wasn't aware of such systems in wide use in places with free wifi – Luke Moll Jan 25 '17 at 18:59
  • Check out the answer here: http://security.stackexchange.com/questions/68748/free-hotspot-open-wifi-vs-wpa2-wifi-with-known-password – schroeder Jan 25 '17 at 19:02
  • 1
    @schroeder WPA2 _with_ a password negotiates encryption — does it do so _without_ a password? – Luke Moll Jan 25 '17 at 19:03
  • So, your goal is to not have a password? That's what you mean by "open"? – schroeder Jan 25 '17 at 19:06
  • @schroeder yes, I thought 'unprotected' would contradict 'encrypted'. What would be a clearer wording so I can edit the question? – Luke Moll Jan 25 '17 at 19:09

2 Answers2

5

There is at least one proposal for this: Opportunistic Wireless Encryption.

In this proposal, the WPA2 password is the same as the SSID, and automatically used by the connecting software.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • Are there any drawbacks to this? This is exactly what I was looking for – Luke Moll Jan 25 '17 at 19:11
  • @LukeMoll this is very much like the solution provided by the link I sent you – schroeder Jan 25 '17 at 19:12
  • @LukeMoll Read the document (espacially 1.1) carefully. This method doesn't protect against sniffing very well. – Ludwig Behm Jan 25 '17 at 22:15
  • @LudwigBehm It protects against passive attacks quite well. It doesn't protect against MitM attacks with a fake AP. Protecting against the active attacks is a lot better than having no protection at all. Active attacks can at least be detected, a passive one can't at all. – Steve Sether Jan 26 '17 at 06:03
  • @SteveSether in my understanding passiv attacks are still possible by listening for the entire handshake. Just imagine the AP in a small shop or cafe, with an attacker reading newspaper and waiting for newly arriving victims. Sure it is harder, but not still not detectable. – Ludwig Behm Jan 26 '17 at 06:18
  • @LudwigBehm Hmmm.. you're right. There's no public key exchange, so you only need listen to the initial handshake. – Steve Sether Jan 26 '17 at 06:29
1

Fully secure unauthenticated encryption is impossible.

By definition, Public WiFi means neither the Access Point nor the Client has any sort of identification of each other when they connect. Without any identification, there is nothing that the client can do to verify that the encryption key exchanged is one that belongs to the Access Point. If the client and the Access Point owner actually had a chance to exchange identification detail, then for most users, exchanging the WPA2 password is simplest much simpler compared to exchanging certificates or fingerprints, like you'd have to do with SSH/TLS.

With SSH, the client must know the server's certificate fingerprint before connecting, while with TLS the server must own a certificate signed by a CA that is pre-trusted by the client. This certificate contains authentication detail (the public key), that can be used to make spoofing impossible.

The best you can do with systems without identifications like a Public WiFi is TOFU (Trust On First Use). But this is a very weak guarantee when most Open WiFi users doesn't actually connect to the same WiFi more than once and you have tens of Access Point in your remembered network history.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93