On Nov 30, 2017, at 13:24 , Josh Luthman <josh@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@delong.com <mailto:owen@delong.com>> wrote:
On Nov 30, 2017, at 08:20 , Josh Luthman <josh@imaginenetworksllc.com <mailto:josh@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@gmail.com <mailto:mysidia@gmail.com>> wrote:
On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <ramy.ihashish@gmail.com <mailto:ramy.ihashish@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