4

I'm looking at ways an outsider (i.e. someone without a possible password) of the network could sniff the communication within the network, specifically focusing on WLAN.

This is what I understand about wireless network security:

  • When we connect to an open wireless access point (so, with WEP) it is possible to sniff the communication (but we can't decrypt SSL-encrypted connections).
  • To make it impossible for outsiders to sniff network, we could use WPA(2) or the like, but in any case this will require to password-protect the network.

This is what I understand about SSL:

  • When we use for example HTTPS (so HTTP with SSL), it isn't possible for attackers to see the data that is being communicated over the connection (unless a malicious certificate has been trusted).
  • When we connect to a server using HTTPS, we do not need to enter a passphrase.

Say I'd like to create an open Wi-Fi hotspot that encrypts the data in such a way that no one can sniff the communication of other users of the hotspot. This is, as far as I know, not possible (is that correct?). But then, why isn't it possible to encrypt the communication with the wireless access point using a technique like SSL? SSL doesn't require a passphrase, but guarantees nobody can sniff the line. Is there something essential about SSL that makes it impossible to use it for such an application?

Community
  • 1
  • I believe EAP-TLS is an option in most WiFi configurations. This approach isn't taken because admins usually want to manage who is connecting to their network. – RoraΖ Oct 15 '14 at 12:03
  • @raz from the wiki it looks like you're correct, and I'm mistaken in my assumption that this isn't possible yet. Thanks! (and maybe you could add it as an answer?) –  Oct 15 '14 at 12:07
  • Doesn't EAP-TLS require a client-side certificate? – Schiavini Oct 15 '14 at 12:15

2 Answers2

0

Basically, the key pair of the server works as a kind of passphrase for the HTTPS connection. The public key is added to the certificate, which is then signed by a certificate authority trusted by the client.

HTTPS requires the website to get a certificate, as you mentioned. This certificate is must be trusted by the client, otherwise the client will deny the connection.

To get a certificate from a certificate authority that is trusted by the clients, the domain owners must prove they are the actual owners of the domain for which they are getting the certificate. So the certificate is only valid for that domain.

In order for the clients of the open network to connect to websites through HTTPS, they will need to trust your system to be that website. In fact they will need to trust you for being any website whatsoever. Actually, you would be a man-in-the-middle, and could read and change anything that goes through that line, the clients couldn't know about it. The level of trust given by the clients would be too high.

Schiavini
  • 109
  • 3
  • No, I would actually suggest a scheme in which SSL would be used to add an extra encryption layer. Still, HTTP and HTTPS would be used according to the server, but then _that_ connection is encrypted. However, now I see the problem: every wireless access point would need to get its own certificate from a CA, that would mean many many certificates. –  Oct 15 '14 at 12:22
  • and how do you, as user, know that you're talking to the correct access point? It could basically be anybody, if you don't have a CA to validate that... – Schiavini Oct 15 '14 at 15:33
  • Yes, I would use a CA for that. –  Oct 15 '14 at 17:43
  • A real CA trusted by clients would never trust anyone to be any domain... – Schiavini Oct 15 '14 at 21:36
0

In the scenario you have outlined it is in fact possible, at least in theory, to sniff the connection.

Okay, so WEP is easy to crack, and if you are using, you should stop and get on to WPA2, which is far more secure, and nearly impossible to break.

In each of these cases you will need to have some sort of password/key set up. If it's just your own access point you can do this yourself by logging in to the AP directly and setting it up, and then setting it up on each device too.

Where it's some AP provided by an institution though lets say, it needs to be centrally administered, and then you need to be informed of the key by way of some "secure channel", e.g. over the phone, or perhaps by SMS in some sort of two-factor scheme.

But this is the "key distribution problem" that you are trying to solve, right? You don't want to have to do this. You're toying with the idea of simply having an open access point, with all access encrypted by SSL or TLS.

As @Schiavini points out, this is precisely what EAP-TLS does, and Protected EAP too, I think, but yes you still have your key distribution problem.

You wonder why you can't just login without a password, just as you would with an HTTPS website?

The reason is that an evesdropper can still break HTTPS, if they catch the initial key-exchange. It's just harder, for an attacker to passively monitor your activity. For instance if he was snooping a variety of links to then analyse them later on, offline, to pull out passwords and stuff.

The real advantage of HTTPS is not just the encryption, but that it authenticates the server to you! So you know you are talking to who you think you are talking to. The guy hosting the website has to pay somebody (a "certificate authority") money to gain a certificate that he can use to prove he is who he says he is, based on the public-key certificates that are distributed along with all commonly used browsers.

With SSL he has to have a more concentrated attack. He has to be targeting "you", and he has to put that extra computational effort into decrypting it.

So without having some sort of key distributed out of channel, you can't have perfect security. You can have a certain amount of protection, but if somebody really wants to get you they can.

robert
  • 335
  • 2
  • 11
  • More info on sniffing SSL links here: http://security.stackexchange.com/questions/19616/why-is-it-possible-to-sniff-an-https-ssl-request?lq=1 – robert Oct 17 '14 at 17:07
  • On mature reflection, I might add that it is not always possible to crack a SSL connection. BUT, if the private key of the link were compromised, then all links would be compromised. Also your scheme makes it harder to revoke somebody's access to the Network. – robert Oct 17 '14 at 17:15