WiFi - login page redirection not working
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
On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <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-create-wifi-popup-login-p... 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
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 On Thu, Nov 30, 2017 at 2:02 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <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- 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
On Nov 30, 2017, at 08:20 , Josh Luthman <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 Direct: 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> wrote:
On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <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- 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
On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong <owen@delong.com> wrote
On Nov 30, 2017, at 08:20 , Josh Luthman <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.
A well known SSL certificate that if it appears during negotiation means the application should "check for captive portal." -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Nov 30, 2017, at 10:15 , William Herrin <bill@herrin.us> wrote:
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.
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 On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong <owen@delong.com> wrote:
On Nov 30, 2017, at 08:20 , Josh Luthman <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 Direct: 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> wrote:
On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish <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- 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
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
❦ 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 <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.
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: http://captive.apple.com/hotspot-detect.html Windows: http://www.msftncsi.com/ncsi.txt Ubuntu: http://start.ubuntu.com/connectivity-check 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: https://tools.ietf.org/html/rfc7710 -- After all, all he did was string together a lot of old, well-known quotations. -- H. L. Mencken, on Shakespeare
On 01/12/17 09:32, Vincent Bernat wrote:
DHCP and neighbor discovery can also provide the information of the login page: https://tools.ietf.org/html/rfc7710
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: https://tools.ietf.org/html/rfc7710
I don't think it got support in any os.
It's supported on Linux by Network Manager. -- All things that are, are with more spirit chased than enjoyed. -- Shakespeare, "Merchant of Venice"
On Dec 1, 2017, at 04:16 , Vincent Bernat <bernat@luffy.cx> wrote:
❦ 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: https://tools.ietf.org/html/rfc7710
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 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Owen DeLong Sent: Friday, December 1, 2017 12:12 PM To: Vincent Bernat <bernat@luffy.cx> Cc: nanog@nanog.org Subject: Re: WiFi - login page redirection not working
On Dec 1, 2017, at 04:16 , Vincent Bernat <bernat@luffy.cx> wrote:
❦ 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: https://tools.ietf.org/html/rfc7710
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
participants (8)
-
Edwin Pers -
Jimmy Hess -
Josh Luthman -
Nikolay Shopik -
Owen DeLong -
Ramy Hashish -
Vincent Bernat -
William Herrin