2 Replies Latest reply: Jan 6, 2013 11:19 PM by aussiewan RSS

    Captive Portal issues - SSL breaks and non-javascript POST login


      Hi all,


      We have MWG set up in transparent proxy mode and have configured a captive portal (based on the built in template for IP auth) to authenticate users, but have a couple of issues.


      First of all - SSL pages do not redirect to the logon page, the client gets an SSL error. If the user is already logged in, the pages work fine. It appears that the SSL tunnel can't be intercepted properly to inject the HTTP 302 to redirect to the logon page. I looked into the possibility of enabling the SSL Scanner, but from what I can gather I need to use a certificate on the MWG boxes which is always trusted by the end users. However this is for a guest network, and we don't have any managment over the end user devices, so we can not install the certificate on them. Is this a problem we are just going to have to live with? It still works, it's just inconvenient.


      The other issue is that the login page (POST) from the templates uses javascript and xmlhttprequest to generate a custom HTTP POST with the username and password sent in headers. This works fine for a lot of devices... however it doesn't in the mini webbrowser on iOS (iPad/iPhone) devices which comes up when they detect a captive portal. The page refuses to render at all because it can't handle the javascript, and when the page is cancelled it disconnects from that wireless network. If I allow unauthenticated access to the apple website, then it can access the test file it wants and thinks that there is no captive portal, so it doesn't pop up with that box, however users then have to load up a web browser to a non-SSL site so they get redirected to the login page. I have tried creating a new page that uses standard POST to submit the username and password, however the MWG rules only appear to let you see the body.text content for the response, not the request, so I can't grab the user credentials out of the POST. Changing it to a GET request would work, but naturally we don't want user credentials stored in the URL which can be more easily accessed both on end devices and in MWG.


      To make this process as painless as possible, we would like to resolve either one of these problems - we don't need both, just one, however I wouldn't mind working out both if possible.


      Any advice is welcome. I can provide the rule-set we are using if you like, but as I said it's basically the built in template with a few tweaks to the login page format and set to authenticate against AD



        • 1. Re: Captive Portal issues - SSL breaks and non-javascript POST login

          Based on a comment on this page by Andre Sabban @ McAfee, my thoughts on SSL issues are right:


          I can't redirect an SSL request to another page without the SSL scanner operational, and I don't want to do that in this scenario because I can't control the end device certificate store.


          So, that leaves my query about using the body of an HTTP POST request so that I can remove the dependency on Javascript for the captive portal. Any suggestions?

          • 2. Re: Captive Portal issues - SSL breaks and non-javascript POST login

            Hi all.


            It turns out that I can ignore my second issue too. If Apple devices detect a captive portal, they will bring up the login page before completing the wireless connection. If you cancel that page, it disconnects you from wireless. This behaviour would break some required functionality we have when using Apple Configurator to manage iPads etc. Since iOS devices are the only ones I know of that do not allow Javascript in the captive portal detection, this is no longer an issue. Even my Kindle was able to authenticate and get online with it the way it is.


            I hope these comments help others trying to implement anything similar.