Good day all,
A lot have been said on this topic, however I want to make sure I am not
missing something.
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?
Second, anything to be done from the AP to show the landing page even if
the page requested is HTTPs?
Thanks,
Ramy
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.
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.....
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.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
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
A well known SSL certificate that if it appears during negotiation means
the application should "check for captive portal."
This would require modification of all clients and I see no advantage to it vs. a well known
locally resolvable URL for captive portals that “MUST NOT” indicate HSTS.
Please explain.
Owen
non-SSL requests are not the issue.
SSL requests are. For example, Google cache's their 301 redirect from
http://www.google.com to 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.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
non-SSL requests are not the issue.
SSL requests are. For example, Google cache's their 301 redirect from http://www.google.com/> to 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
❦ 30 novembre 2017 18:26 -0800, Owen DeLong <owen@delong.com> :
SSL requests are. For example, Google cache's their 301 redirect
from http://www.google.com/> to
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.
You can use http://neverssl.com/.
But as mentioned earlier in the discussion, most OS have a non-HTTPS URL
to detect a captive portal. They can display notifications to the user
when they detect a captive portal. Browsers have that too.
iOS/macOS: Success
Windows: http://www.msftncsi.com/ncsi.txt
Ubuntu: Lorem Ipsum
Firefox: http://detectportal.firefox.com/
Chromium: http://clients3.google.com/generate_204
DHCP and neighbor discovery can also provide the information of the
login page: RFC 7710 - Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
I don't think it got support in any os.
Current take on that is capport WG
https://datatracker.ietf.org/wg/capport/documents/
❦ 1 décembre 2017 15:02 +0300, Nikolay Shopik <shopik+lists@nvcube.net> :
DHCP and neighbor discovery can also provide the information of the
login page: RFC 7710 - Captive-Portal Identification Using DHCP or Router Advertisements (RAs)I don't think it got support in any os.
It's supported on Linux by Network Manager.
Oh, you mean the first software anyone with clue turns off as soon as they can because of all the problems it causes for networking?
Owen
RHEL comes with it installed and enabled by default, so it can't be that bad /s