0

I have doubt about how to implement hotspot for my startup. Idea is to have implemented WPA2-Enterprise with remote radius server and splash page. This implementation came after the reason of ease of remembering password on client devices, so they can access to AP without having to enter password every time they login.

But with progress of SSL implementation on the websites there is a fear that it might greatly increase issues with raising certificate errors because of MiTM like exceptions.

And as I know of, there is no solution for old clients/browsers to avoid such situation.

So, does anyone know more about statistics, how many clients would possibly be affected by this issues, today, in a real world, and what can be expected?

Additional note: Maybe I was not clear, very common Cons with captive portals is that they raise SSL invalid certificate error when it's being redirected to the Splash/login page, so the question concerns about usability of captive portal and current implementation of solution in browsers.

1 Answers1

1

This question is a little convoluted, but you seem to have conflated network authentication methodologies with SSL (TLS).

  1. WPA2/ Radius is not a proxy, so MiTM is not applicable.
  2. SSL / TLS provides end-to-end encryption for data content. How those packets are routed in terms of WiFi is irrelevant.

Think of it this way: you have encased a letter in an 800 pound safe. You can move the safe from point A to point B using a train (ethernet) or you can do it via an airplane (WiFi).

In both cases, the mode of transportation is irrelevent to the message (the letter) it's protection (the safe) and its delivery.

Your radius server simply acts as a registry of allowed train depots and airports from which the letter in the safe can be dispatched.

If you're concerned about the "burden" of users having to remember their password to access your network, then you're going to be sadly disappointed in man-kind. It seems to be a prerequisite for users to complain about their passwords and the inconvenience of having security. Security and ease-of-use are diametrically opposed. So, you have to compromise between having great security (encasing your wifi in concrete and sinking it to the bottom of the ocean) and having usable wifi (open, unencrypted, click to connect house of internet disease).

If you're willing to front-load your efforts, you can make it "easier" to connect to your wifi by implementing radius that uses RSA or other key encryption. To the user, that's "click to connect" easy because all the authentication is done behind the scenes.

If you can't (or are unwilling) to do this, then you need to tell your users they are going to have to remember their passwords. If the users are employees, then it's their tough luck that they have to put "effort" into their job. If the users are customers, then you have to make a judgment call on how much security they are willing to put up with in order to access network resources and where your liability is. Users probably won't let you setup RSA, nor will they want to type in d892la0as9jfm10-9svnm as their password.

In either case, RADIUS does not a proxy make, and therefore, MiTM worries are baseless.

DrDamnit
  • 854
  • 4
  • 12
  • Maybe you misunderstood, of course MiTM is not applicable to WPA2/radius, also SSL is not prone to suffer from MiTM attacks, that's why I said "MiTM exceptions" which are actually browser exceptions that SSL is not valid during redirecting to splash page, which is considered as MiTM exception where router intercept request to let's say `https://google.com` to `https://my`. It is not about security, Question is more about concern of exceptions itself and usability Both of these solutions were implemented in hotspot: 1. WPA2 + radius 2. Captive portal with no radius/mac login only – Milos Radojevic Aug 03 '17 at 11:11
  • Your hotspot should (must) use 302 redirects to send the traffic as a separate request. Thus, the request to `https://google.com` gets redirected to `https://myportal.com`, where local DNS resolves that to your captive portal. There are no exceptions to be had. They are two different (stateless) requests. – DrDamnit Aug 03 '17 at 19:41
  • If you use 302 redirects, redirect response is loading certificate for `https://myportal.com` on domain `https://google.com` and therefore cause invalid certificate error. Actually portal performs "MiTM like" redirection as per above. if there is no certificate served, browser will reject it allogether. For such thing google, firefox, and other browsers and also android OS have added captive portal support, I have no status for other OS. So the problem is in real world, that some people will eventually suffer from it for sure. But what I don't know is how many of them. – Milos Radojevic Aug 05 '17 at 22:51