WiFi - login page redirection not working

Fri Dec 1 02:26:04 UTC 2017

> On Nov 30, 2017, at 13:24 , Josh Luthman <josh at imaginenetworksllc.com> wrote:
> 
> non-SSL requests are not the issue.
> 
> SSL requests are.  For example, Google cache's their 301 redirect from http://www.google.com <http://www.google.com/> to https://www.google.com <https://www.google.com/> which means clients that had access while that browser ps stays active will still attempt https instead of http, regardless of what you actually type.

Right, you’re talking about HSTS as I mentioned below.

However, if there’s a well known URL for getting the captive portal to work (e.g. http://captive.portal), then we educate users (or
browsers that they can type captive.portal (or whatever URL we choose) instead of google (which was my traditional go to before HSTS,
I admit) and voila… Problem solved.

I’m fortunate enough to have my own non-HSTS domain that I use for this purpose and it’s quite easy and effective.

Owen

> 
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
> 
> > On Nov 30, 2017, at 08:20 , Josh Luthman <josh at imaginenetworksllc.com <mailto:josh at imaginenetworksllc.com>> wrote:
> >
> >> If TLS  would somehow allow you to redirect...
> >
> > No but it would be nice to have a solution that redirects the user instead
> > of "this page can't load" creating confusion.
> 
> A well-known non-SSL (non-HSTS) URL that users could use for this purpose would
> serve the same purpose without producing the security problems mentioned.
> 
> Owen
> 
> >
> >
> > Josh Luthman
> > Office: 937-552-2340 <tel:937-552-2340>
> > Direct: 937-552-2343 <tel:937-552-2343>
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > On Thu, Nov 30, 2017 at 2:02 AM, Jimmy Hess <mysidia at gmail.com <mailto:mysidia at gmail.com>> wrote:
> >
> >> On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <ramy.ihashish at gmail.com <mailto:ramy.ihashish at gmail.com>>
> >> wrote:
> >>
> >>
> >>> Two points with this problem: 1)Is there a "non client" solution to the
> >>> problem of the WiFi login notification not showing up on the clients
> >> after
> >>> connecting to the WiFi network?
> >>>
> >>
> >> A  Captive portal  embedding WispR  XML data
> >> for connections from browsers/OSes that request a test page upon network
> >> access.
> >> https://stackoverflow.com/questions/3615147/how-to- <https://stackoverflow.com/questions/3615147/how-to->
> >> create-wifi-popup-login-page
> >>
> >> However if WPA2 authentication is not method used for access,  then network
> >> traffic is
> >> vulnerable and not secured.
> >>
> >> AP solutions that are non-standard being a "Non client" solution and using
> >> "Open Wireless" mode SSIDs are likely so deficient in security as to be
> >> an unreasonable risk for users to actually connect to.
> >>
> >>
> >>> Second, anything to be done from the AP to show the landing page even if
> >>> the page requested is HTTPs?
> >>>
> >>
> >> If TLS  would somehow allow you to redirect or create a HTTPS connection
> >> from
> >> a domain name that is not yours, then this could obviously be exploited for
> >> attacks.....
> >>
> >> --
> >> -JH
> >>
> 
> 