> On Nov 30, 2017, at 13:24 , Josh Luthman <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > > > On Nov 30, 2017, at 08:20 , Josh Luthman <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > >> On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <[email protected] > >> <mailto:[email protected]>> > >> 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 > >> > >
