paya wrote

how can fixed it ?

Paya, rather than hi-jacking any thread related to captive portals to ask the same question over and over again, you should read the answers to your question and give it a try:

http://forum.tp-link.com/showthread.php?101432-eap-110-captive-portal-not-work-when-internet-in-off

DocJones wrote

The only way the access point would be able to do this is if it could serve a valid certificate for the site the user was attempting to visit (e.g. google.com), which of course it can't or else that'd be a huge security vulnerability!

Absolutely! :) HTTPS has been developed not only for encryption of web traffic, but also to make sure that the site answering a request is indeed the site which was originally requested. Thus, no Wireless Captive Portal based on intercepting requests can redirect a HTTPS connection to the portal.

That's the reason why modern operating systems perform a connectivity check using DNS and HTTP requests if connecting to a Captive Portal, which sends a 302 REDIRECT response. Most iOS and Android platforms and also MacOS and Windows will show the portal page automatically after selecting the WiFi if you give them some time to detect it. But this works only with a portal page hosted on an EAP Controller, not in EAP's stand-alone mode.

A drawback of this method is that Google did a bad job implementing the connectivity check in Android since at least Marshmellow: after logging in, the "success" page isn't shown, since Android closes the webview window immediately as soon as connectivity has been established. I filed this bug several times to the Android Bug Tracking System, but they don't care, so Android users do not see the "success" page of Captive Portal systems.

Tobacco wrote

But in actual cases and products, this is left to vendor. I think in a later version the controller could allow you to redirect https pages too, as some other vendors have already done.

You can intercept HTTPS request technically, but the browser would warn the user about a suspected man-in-the-middle attack and would refuse to load the website with no option to override this (more on overriding in old browsers below). So, a vendor of a captive portal software can't do anything about it.

Maybe what you are observing if connecting to a HTTPS site and getting redirected to a portal is the connectivity check (aka "Network Awareness") in modern OSes, which basically send a HTTP request to see wether Internet is available. If the server sends a redirect (301 or 302) response, the connectivity check usually initiates the start of a browser or a separate webview window in sand-box mode, which connects to the redirected server only to process the login. It also sets a flag about the connectivity state preventing other requests to connect to the original server, but using just more HTTP requests to the connectivity check site, thus redirecting you to a captive portal even if you typed in a HTTPS URL.

This technique of "client-initiated redirects" happens as soon as you connect to an open WiFi and the vendor implementing this technique of "silent redirection" is the vendor which produces the operating system running on the device (smart phone, tablet, laptop etc.), not the vendor of a hotspot system. But still HTTPS requests are not intercepted; the connectivity check runs asynchronously from any standard browser request.

But (again), another change is coming, future OS or browser or website may enhance the security of HTTPs and prevent any attempts of intercepting or redirecting https websites, which is called HTTP Strict Transport Security (HSTS)

HSTS is basically a HTTP header which instructs the browser to always override HTTP requests to HTTPS for a given website. It's nothing new, the standard was published 2012 already. Wether it really makes sense to allow a web server to instruct a browser how to process requests of the user is IMHO rather questionable, since it forces any website owner to buy SSL certificates and to support HTTPS (the reason for being forced to switch to HTTPS is that a really bad guy could spoof a HTTP website and use HSTS to hijack all future requests to his own HTTPS site for as much as one year, but no, I won't give any details on this hack).

While it makes sense for online shopping and online banking to secure the connection through SSL, a weather site just publishing weather forecasts may choose to not use HTTPS at all, but this HSTS crap forces each and every site owner to buy and install SSL certificates for his website on the long run if he wants to mitigate against potential website theft. (Yes, I know that free certs are available, but they are most often only offering basic features, e.g. only for one subdomain.)

HSTS is the reason why connectivity checks have been introduced when vendors recognized that their HSTS settings prevents people on WiFi hotspots from logging in easily. If you want to support devices which implement HSTS, but not connectivity checks, you should deploy a HTTP-only website to allow interception of requests to this site for the purpose of redirecting the user to the hotspot portal. Of course, you need to tell users how to do this.

If you want to be somewhat anal to the HSTS protagonists, you could capture connectivity check requests and output a message that the user should start a browser, request your HTTP website, log into the hotspot and send an automated complaint to the vendor of the device about HSTS. ;)

I just notice that in iOS11 the Safari browser has already enable HSTS for some famous website, I used Aruba APs to redirect https to my captive portal and then seeing a Waring page without any "continue button".

Many browsers supports HSTS meanwhile and yes, websites using HSTS and requiring HTTPS-secured requests can't be used at captive portals which use interception for redirecting to the login page. But iOS 11 also implements connectivity checks, which should silently redirect you to the captive portal (if not disabled at all in your iPhone). Since this happens only a few seconds after connecting to the WiFi network, often people don't recognize this b/c they are too impatient. Just make a test: connect to an open WiFi and wait for the connectivity check to present ou the login page. On some Android platforms, there is just a notification, which most often is ignored as almost all other notifications, too. :D

So, I think a few years later, it won't be possible to redirect https pages to captive portal. Vendors and administrators are only suggested to block or allow users from https website completely before authenticated.

It never was possible to redirect HTTPS requests to a captive portal. It was indeed possible to override the HTTPS request and have the browser change it silently into a simple HTTP request by telling the browser to ignore a bad SSL certificate and use an unencrypted connection instead. The second HTTP request then could be redirected to a captive portal, but not the first HTTPS request.