HTTPS interception

[vidarak]

Hi
Is it possible to get nodogsplash to intercept HTTPS requests also?

Rgds,
Vidar

[mwarning]

nodogsplash doesn't accept/handle HTTPS request.

It is possible to intercept HTTPS. But the browser will clearly state that the certificate is wrong and might tell you that you are subject to a man-in-the-middle attack. The splash page won't be shown depending on the browser because of this.

Well, I haven't tried.

[vidarak]

Hi

This works well in other captive portals like the one built-into the Fortinet Fortigate devices. As long as the traffic is intercepted (from first packet) the client would not be able to tell that it is a man-in-the-middle attack, would it? With the Fortigate as captive portal my web browser simply shows a certificate warning saying the certificate does not match the URL and that it is not trusted (it's a self-signed certificate). I accept the risk and get the splashpage.

The behavior as seen in the Fortigate should be preferred as then it enables users to get to the splash page even if they have configured an HTTPS page as their browser home page. With nodogsplash such a user could be mislead to believe the internet connection is broken altogether.

Rgds,
Vidar

[mwarning]

If that's the case I agree with you - it would be a useful feature.

The main problem is to find someone interested to implement it.

[albig]

I just had a look on this issue. I think, it's not that easy to implement. It's not only an iptables rule to forward port 443 to port 80. This won't work.

But nodogsplash needs to handle SSL/TLS connections itself. Even then of course the user will get a certification error. But as far I can see, libhttpd doesn't support this.

[gluedig]

I'm using stunnel for this purpose - forwarding all port 443 traffic to it, stunnel then forwards it to standard nds port.
Works well enough.
Of course certificate is invalid but this is exactly how i have seen it implemented in the wild

To implement it natively would mean a change of http library - which might be a good thing anyway since libhttpd is bit dated and not maintaned afaik.

[albig]

@gluedig Thank you. I didn't know stunnel, but I will try it.

libhttpd seems really outdated. E.g. using curl -I to just get the response header fails with nds, because it doesn't recognize this as HTTP request. But this is really another issue.

[sayuan]

@gluedig
If you redirect the packet via stunnel, doesn't the nds consider the client was the stunnel (the AP itself?) rather than the real user?

I have an another solution.
We can just provide a HTTPS server and redirect all preauthenticated HTTPS request to this server.
Then, this HTTPS server always return 302 and redirect the packet to nds via HTTP.
Since uhttpd already support TLS and lua_handler, this can be done by a few lines of config and codes.
The simplified version of lua handler looks like the following.

function handle_request(env)
        uhttpd.send("Status: 302 Found\r\n")
        uhttpd.send("Location: http://192.168.1.1:2050/\r\n")
        uhttpd.send("Connection: close\r\n")
end

The biggest drawback I saw is the redir, the original URL user requested, which is missing.

ps. If your uhttpd doesn't dispatch requests to lua handler for all URL, make sure this patch exist in your uhttpd.
http://patchwork.openwrt.org/patch/6007/

[gluedig]

@sayuan
you are right, there is an option in stunnel to set x-forwarded-for header to contain original client's ip
then it is a trivial patch to use that in nds

your approach seems better and i guess there should be no problem to set "redir" as well
i overlooked uhttpd and it's ability to redirect from lua function when looking for a solution to this problem

[epipenau]

hey guys im trying to do what sayuan suggested but when i try to open the uhttpd https server page which should redirected based on the lua handler, instead i get Bad Gateway The process did not produce any response.

this is my /etc/config/uhttpd

config uhttpd 'main'
list listen_https '0.0.0.0:443'
list listen_https '[::]:443'
option cert '/etc/uhttpd.crt'
option key '/etc/uhttpd.key'
option lua_prefix '/'
option lua_handler '/etc/config/nossl.lua'

and this is my /etc/config/nossl.lua

function handle_request(env)
uhttpd.send("Status: 302 Found\r\n")
uhttpd.send("Location: http://internode.on.net:80/\r\n")
uhttpd.send("Connection: close\r\n")
end

i know the Location: should goto the nodogsplash page, but im currently just testing a basic request to the httpd directly on my lan as my AP is several kilometers away and i can't test the splash page from here. but in theory, pointing my browser to any IP on the AP, and port 443, or https://apsipaddress, should run that lua handler and redirect me to http://internode.on.net:80. is there something im doing wrong?

i tried removing /etc/config/nossl.lua and restarting the uhttpd and i just get a directory content listing when viewing the server's page in a browser, so i know it's working and trying to parse the nossl.lua command when i have it loaded, i'm just not sure what to make of this error and how to proceed from here.

[albig]

Hi epipenau,

I tried the same and had the same result als you in the first tries.

Two things fixed this:

1. opkg install uhttpd-mod-lua (this was missing on my router)
2. add another "\r\n" on your location line to send an empty line before "Connection: close". This is necessary somehow, I remember.

Have a look on the Embedded Lua Example:

http://wiki.openwrt.org/doc/uci/uhttpd

[lynxis]

I don't like this functionality in nodogsplash, because it requires https:// breakage. Most modern OS now honor captive portal via http:// checks against known URL and notify the user.
However I think it's a good idea to document https:// support without changing nodogsplash.

[vidarak]

lynxis,
This is about user experience really. All major commercial proxy services and captive portals do HTTPS interception for good reasons. Sure, it breaks the HTTPS (only while redirecting to the captive portal page), but that's better than getting an error message indicating there is no connectivity.

In my experience the OS captive portal detection is slow. Users (myself included) are trying to browse web pages immediately after they get connected. Users might easily have ignored/overlooked notification of captive portal from OS too, again because they are both slow at appearing and do not necessarily stand out visually.

[lynxis]

@vidarak I still don't like the idea of https:// redirecting, but maybe somebody would like to enable.
With Strict-Transport-Security this thing got even worse and I would say a Chrome run amok when it sees such certificates for google.com. No idea how other browser behave. Also this would teach users to ignore every BIG FAT WARNING about don't do this.

[florian583]

Hey !
I'am trying to put in practice the solution of @epipenau & @albig but i have a infinite loading on HTTPS pages.
My goal is to redirect users to the login page of NoDogSplash when they try to load a HTTPS page before auth.
I added in location http://redirect.fr (dumb domain) so the page of NoDogSplash come.
Thanks for any help

1/ Did i need to generate the crt files you use in the config ? If yes how ?
those in /etc/config/uhttpd :

option cert '/etc/uhttpd.crt'
option key '/etc/uhttpd.key'

2/ Is this config right ? I tried to add the additional \r\n" at the end of the line

/etc/config/nossl.lua

function handle_request(env)
uhttpd.send("Status: 302 Found\r\n")
uhttpd.send("Location: http://redirect.fr:80/\r\n")r\n
uhttpd.send("Connection: close\r\n")
end

[thxred]

I have the same problem as Daemon024, also tried change from "uhttpd.send("Location: http://IP:80/\r\n")r\n" to ""uhttpd.send("Location: http://IP:80/\r\n\r\n")" but does not redirect.

Thanks

[cloudstm]

Hi Guys,
someone could fix this?
Because in Brazil the home page usually is google.com.

[joernroeder]

more and more sites are using https by default (which is awesome) and redirecting https clients as well (maybe downgrade and redirect them to the http://splashpage) should be implemented. Otherwise the splashpage won't show up as a lot of users uses a https://favorite-search-engine as their start page.

[ArtMartin89]

Hello everyone, can somebody tell how to solve https problem with NDS? I've read previous posts & don't understand if someone have solved it for sure. I've tried what @gluedig and @sayuan suggest, but haven't got the result. Maybe I do something wrong, I'm not as experienced as you guys, so if there is a solution for this problem can someone tell the step-by-step instruction. I'm sure this instruction will be helpful for many people.

[haircrime]

Hi guys,

As ArtMartin89 is already asking, I am trying to revive this thread one more time.

Does anyone have any recommendations how to get nodogsplash to forward to the splash page, when a https request was made by the user.

Anything I can try out, even if it has the obious drawbacks of breaking the SSL etc...

Thank you very much, this would be a great help.

[mwarning]

@haircrime well, someone has to implement something. :-)

[bluewavenet]

It would be nice but the question is - Is it worth the effort?
100% of smartphone and tablet devices (iOS, Android and Windows) use their built in Portal Detection procedure. This tries to access some pre defined web page via http on port 80, not a browser home page, so works just fine with Nodogsplash.
In my experience of public hotspots, nearly 100% of devices are smartphones or tablets. Searching logs of a busy site shows less than 1 in 1000 devices are not this type. ie a very occasional Apple or Windows laptop (and a growing minority of Linux laptops!).
True that my logs would not show rejected devices trying https as a home page, but I think these will be rare.

[haircrime]

@bluewavenet

Hi, yes you certainly have a point. And until a couple of weeks ago, you were right.

Lately I have received a lot more complaints about not working hotspot connections. By doing some research I discovered that some newer Samsung mobile phones, running Android launch the browser with HTTPS://Google.com , when detecting a captive portal.

I have no idea why in the world Samsung would change the normal Android behavior, but of course this leads to a time out on nodogsplash.

[bluewavenet]

I have just tried on a Samsung phone with the very latest updates and see the following:
User Agent: Mozilla/5.0 (Linux; Android 6.0.1; SAMSUNG SM-G900F/G900FXXS1CPG2 Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/4.0 Chrome/44.0.2403.133 Mobile Safari/537.36

Requested URL: http://www.google.com/

Can you capture the user agent string from one of the problem devices?

[bluewavenet]

@haircrime
How do you know they request https://google.com?
In my example:
If the device was to connect to an open wifi that was not a redirecting hotspot like Nodogsplash, the Portal Detection will try to access http://google.com and, as it has immediate access to the Internet, will be redirected by Google to https://google.com so you may not actually be seeng Samsung doing something odd.

[bluewavenet]

@haircrime
Could you be seeing a manifestation of #113 ?

[haircrime]

@bluewavenet

thank you for your input and I have checked #113 but this is not the cause.

Attached you can find screenshots of 2 samsung phones I can replicate this issue with.

After selecting the free hotspot that runs nodogsplash, the android notification asks the user to sign in. After clicking, the regular browser opens.

The browser tried to load https://google.com and times out. There is no way for the user to get to the redirect page, unless he enters by hand a non-ssl url - which is rare.

What I normally find on android phones is, that after clicking the captive portal notification, a webview popup browser will open. This browser has limited feates (no javascript, no cookies etc..) and it loads a normal "non-ssl" url (gstatic...) which will result in a redirect to the nodogsplash landing page. So this behaviour is great and easy to use. Why does Samsung change the Android behaviour?

Does nobody else experience similar effect?
bluewavenet, any ideas?

Thanks a lot...

Infos about the phones:

[bluewavenet]

I have access to three Samsung phones at the moment running various versions of Android ranging from before your examples to versions after. All work normally and also I have not received any complaints from potential users.
As you have the apparent problem with various versions of Android on these Samsung devices, it looks like the problem lies elsewhere and is quite intriguing!
The url used for the portal detection is held in a configuration file only accessible on rooted Android devices and is of the form:
http://connectivitycheck.gstatic.com/generate_204
http://clients3.google.com/generate_204
etc. with variations depending upon vendor.
However recent versions (since around mid 2015) have been delivered with just plain old http://google.com

It is possible (on rooted devices) to disable Portal detection entirely.
Also, manual opening of a browser will attempt to go to the home page whatever it is.

Other operating system vendors have their own versions eg.:
http://captive.apple.com/hotspot-detect.html
http://www.windowsphone.com/

Changing the url to https will break Portal Detection. Samsung would not (intentionally) do this and I cannot see any other evidence that they have done so.

So what is causing your problem?

For example - on my laptop computer, if I connect to a Nodogsplash hotspot, start Firefox and click my bookmark for http://google.com I get the splash page.

If I do not use the laptop for a while and the Nodogsplash idle timeout is exceeded but Firefox is still running and I click the bookmark, I find Firefox has cached the Google redirect to https and of course I will not get the splash page.

Is perhaps something like this happening?

[vidarak]

I think it might boil down to which browser is the default browser on the phone and what web page is the startup/home page in the browser?

Scenario:

1. phone connects to wifi
2. phone checks one of those URLs you mention (http://clients3.google.com/generate_204) and discovers it cannot reach it so it notifies user about captive portal / sign in requirement
3. user clicks the notification which opens the default browser
4. default browser goes to its startup page... which could be https://www.google.com... and THAT doesn't work.

[bluewavenet]

Yes @vidarak !
The Portal detection should open the browser automatically and pass the detection url to it.
It should be independent of the default browser. For example on my personal phone with either the Samsung Internet app or Firefox for Android it goes to http://google.com regardless of the home page setting of the browser.
In fact the Portal detection tries the detection url directly without using the browser and should only start the browser if it does not receive the expected answer ie a 204 response. The browser is invoked with the detection url in its command line thus overriding the home page setting. At least this is how it is "supposed" to work. This is the first time I have heard of a browser that ignores this and goes to its home page regardless. Unfortunately I cannot replicate this problem.

[vidarak]

I'm not so sure the browser is supposed have the detection URL passed to it. That would be very counter-intuitive as the response from the detection URL is a blank response. I think you got that part wrong...?

I don't question the fact that the OS is using the detection URL outside of the browser - for the detection. It's just not passing that URL to the browser (and it is not supposed to!). Perhaps some phones have been hard-coded to pass a different URL (like http://google.com), but that is outside any standards AFAIK.

[agustindev]

@haircrime @bluewavenet somthing like this wifidog/wifidog-gateway#6

If nds is based on wifidog and this issue is closed, I think it could work

for the moment I create an static domain in dns srv of the router, ie: internet.com, and redirect to the gateway:2050 👎

[xewonder]

Hi,

I am a bit late with this, but have you found a solution for Samsung phones?

https://drive.google.com/file/d/0B0tIo4L0lOvqS2FVLVUxNzVfVVU/view?usp=sharing

Reading about it, it has nothing to do with DNS but what the site "throws" at the browser.

QUOTE from WIKI (https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections,[1] and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797.

UNQUOTE

So the samsung phones/tables redirect to www.google.com and Chrome converts to https!

[bluewavenet]

I have tested extensively now with Samsung and cannot replicate the error, but have not tried with Chrome as in your video. If you make the Samsung browser the default again (as it will be on the phone initially) then it will work, as indeed it will with Firefox. It seems it is the Chrome browser that breaks CPD.
Also read issue #140 for more insights into this.

[xewonder]

Thanks.

If you see the video, Firefox has no problem.

I guess users (I have about 400 routers out there) with Samsung and Chrome
as their default browser will not be able to get the splash page. Adding
.google.com to the whitest is not an option.. I think

---

Best regards
Denis Dorigo

(sent from mobile device)

On 27 September 2016 4:23:54 p.m. bluewavenet notifications@github.com wrote:

I have tested extensively now with Samsung and cannot replicate the error,
but have not tried with Chrome as in your video. If you make the Samsung
browser the default again (as it will be on the phone initially) then it
will work, as indeed it will with Firefox. It seems it is the Chrome
browser that breaks CPD.
Also read issue #140 for more insights into this.

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#3 (comment)

[bluewavenet]

Yes, works fine with both Samsung browser and Firefox. The CPD on Android seems to invoke the default browser.
If this can be verified as a problem with Chrome browser it should be reported as a bug to Google.
https://support.google.com/chrome/answer/95315

[bluewavenet]

I do however think something else is going wrong somewhere.
The Android CPD normally uses http://connectivitycheck.gstatic.com/generate_204 regardless of the browser in use.

[xewonder]

@bluewavenet Thak you for replies.

The more I look at this the more the more I am sure it is a SAMSUNG - CHROME problem. But finally Chrome!

I have now tested with serveral android devices and:

1> Samsung "log on to WIFI" pushes www.google.com.
2> Chrome (on any tested andorid device) converts www.google.com to https://... even before coova or anything else can intercept the request. Other browsers show http splash!

This comes down to a "too stric" implementation of HSTS by Chrome.

By the looks of it, HSTS pushes someting to the browser telling it that "next time" it should use HTTPS to reach the address...

QUOTE from https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

HSTS mechanism overview

A server implements an HSTS policy by supplying a header over an HTTPS connection (HSTS headers over HTTP are ignored).[12] For example, a server could send a header such that future requests to the domain for the next year (max-age is specified in seconds; 31,536,000 is equal to one non-leap year) use only HTTPS: Strict-Transport-Security: max-age=31536000.

When a web application[13] issues HSTS Policy to user agents, conformant user agents behave as follows:[14]

Automatically turn any insecure links referencing the web application into secure links. (For instance, http://example.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server.)
If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), show an error message and do not allow the user to access the web application.[15]

The HSTS Policy helps protect web application users against some passive (eavesdropping) and active network attacks.[16] A man-in-the-middle attacker has a greatly reduced ability to intercept requests and responses between a user and a web application server while the user's browser has HSTS Policy in effect for that web application.

UNQUOTE

So YES! this should (and I will) be reported to google and also Samsung!!

I have the feeling that this can not be overcome without them!

[bluewavenet]

Any CPD should try its tests on the network directly and not via a browser. If detection of the captive portal is positive then the browser should be invoked, passing a URL to the browser on the command line. I suspect Chrome is ignoring this and trying https://google.com instead. I will try a few more tests.

[bluewavenet]

I have just installed Chrome on a SG5 and made it the default and can now replicate the error. Chrome when invoked immediately tries https://google.com
It still works in Firefox and Samsung browsers.

[xewonder]

@bluewavenet

unless you clear the cache... then it woks a few times.. my guess is unill you visit www.google.com and then it downloads that "stupid" HSTS file....

[bluewavenet]

It was a fresh, first time install of Chrome that I tried and it failed at the first attempt so I am not sure what is happening, however you seem to be on the right track ;)

[bluewavenet]

Looking closely at a few more tests:
Android 6.0 tries http://connectivitycheck.gstatic.com/generate_204 and passes the same to the browser.
Android 6.01 tries http://connectivitycheck.gstatic.com/generate_204 but passes http://www.google.com.
So it seems a combination of Android 6.01 CPD and Chrome over "strict" might be causing the problem - but not necessarily as on a number of large sites I have not received any complaints of this problem. The latest version of Chrome perhaps?

[bluewavenet]

http://google.com does a 302 redirect to https://www.google.com
This would be ok and would work in NDS as the initial request is http.
Yet Chrome goes directly to https
My conclusion is that it is definitely Chrome causing the problem with a built in redirect rather than letting the web site do it.

[xewonder]

just as a"cherry on the cake".

I have tested on a device that is not even online (wifi off and sim card out).

Chrome transforms www.google.com (that I typed in) to https://www.google.com!!

[wificatalogue]

Hi, i have been researching the same issue for the last couple of weeks because i am facing customers complains too. I have reached the same conclusion. The latest version of Chrome when is the default browser, messes up the captive portals because of the HSTS implementation only on android lollipop.

We need to open a ticket somewhere and get a response from them.

[pmosse]

Hello everyone! I am facing the same problem. The captive is displayed in some phones (Samsung J1) as https://www.google.com, then the customer navigates freely to some HTTPS sites (like Facebook) and after a little while they are kicked out of the connection as the phone thinks there is no internet...

[bluewavenet]

I have just checked the logs of an extremely busy hotspot I have installed. In over 2500 logins, some 200 or so were using Chrome 55.0.2883, at the time of writing, the current release version I think.
At that site there have been no complaints received.

https will NOT bring up the splash page in any circumstances as Captive Portal Detection (lets call it CPD) is designed to use its own http port 80 request and NDS ignores all non 80 requests.

On Linux CPD is built into Networkmanager. Different distributions use their own url but all of them are designed to return 204 "no content" return code or a pre defined response string. This signals to the CPD that a valid Internet connection is present. If the CPD receives anything other than 204 or the response string with a 304 (see below) it will assume a splash page, if it receives nothing it will assume no connection to the internet. All this is done on port 80.

The configuration is in the NetworkManager.conf file, found usually in /etc/networkmanager or thereabouts.
It will be in the [connectivity] section.

in OpenSuse Leap it is:
[connectivity]
uri=http://conncheck.opensuse.org
response=NetworkManager is online
interval=300

In Debian it is:
[connectivity]
uri=http://network-test.debian.org/nm
response=NetworkManager is online
interval=300

On Android and iOS it is similar, but you have to root the device to see the details.

Note the interval defaults to 300 seconds. On first connecting to the WiFi the CPD will try the configured URL. Then it will retry at 300 second intervals.

What some people may be seeing is the following sequence:

1. You are already connected to the Wifi but not logged in
2. You open your browser and try an https site.
3. NodogSplash ignores you
4. The timing interval expires and the CPD kicks in, receives something other than 204 (or 304 with a response string) from NDS and pops up its browser to display the NDS splash page.
   Obviously this can take up to 5 minutes (300 seconds) with the default NetworkManager config.

Also if you are using the version distributed with Barrier Breaker (0.9_beta9.9.8-1), it is broken and lets everything through except port 80. @pmosse - the symptom of this is as you describe here.

I have now tried again, testing with Chrome 55.0.2883 and can only replicate using the scenario I describe here. This actually happens with ANY browser.

[pmosse]

Hey @bluewavenet, thanks for the full explanation! Yes, it is as you say. I am actually using the version 1.0... Do you think there is any way to display the Splash for the users that have an HTTPS site as the default (or maybe they don't but Google is displayed anyway)? Maybe playing with the DNS servers and changing Google's IPs to something else? Or intercepting the requests at some level?

[bluewavenet]

The point here is that even with a home page set up for https, the CPD will still always use its own port 80 request.
For a public hotspot I am seeing less than 1 in 2000 devices that are not CPD enabled. These are the very few old Windows laptops running Vista or earlier.
If you can replicate the issue on a Samsing smart phone for example. Try disconnecting the wifi then reconnecting. This should immediately invoke CPD. If not then try telling Android to forget the ssid. Then reconnect. If it does not work then, there must be some issue with CPD on that device.

[kerematam]

Any suggestion for Nodogsplash equivalent Captive Portal software which can handle SSL requests and return 302? Maybe some kind of packet software which includes light weight DNS and https server inside only serve for this purpose.

Also I wonder if SDN approach can be successful? OpenWrt supports OpenFlow, so a SDN controller attached to an AP can solve this?

[vidarak]

We went with MikroTik RouterOS on virtual machines... and some physical appliances shortly after I started this thread. Have been very satisfied with their reliability.

[kerematam]

@vidarak So you run virtual RouterOS on PC attached to an OpenWRT APs to handle captive portal?

[vidarak]

We run virtual RouterOS on ESXi servers (where available), and RouterOS on RouterBoards where we don't have local ESXi servers. The RouterOS is the gateway/dhcp server of the VLAN.

We use mostly Cisco APs with multiple SSIDs attached to separate VLANs. Only the guest VLAN has the captive portal (in RouterOS, APs are just L2).

[bluewavenet]

@vidarak , it is good that you found a workable solution for your application.
@xewonder , @pmosse I have found the possible problem with Chrome non-repeatable. It should not matter at all what the client has as home page on their browser as the CPD will always do its port 80 request as soon as the client connects to the WiFi of the Hotspot.
I have learned a lot about this subject since this issue was started. Looking at statistics I have collected from busy public hotspots running NDS, I see an extremely small number of none mobile devices attaching and of those most are Captive Portal Detection (CPD) capable (Windows 7 and above, Mac(any model), a few Chromebooks and a small but increasing number of Linux laptops). The problem, if it exists in the public hotspot environment, is very very small. Even if the client reaches the configured idle timeout or compulsory timeout, the CPD should (normally) kick in within 5 minutes, the default polling interval for CPD.

Is there a genuine environment where this is not enough, given the rapid increase in support for CPD over the past couple of years?

[rakesh2215]

Hi Folks,
Have you looked at this?
https://github.com/liudf0716/apfree_wifidog
They are claiming https support. Any comments are welcome. I am yet to try this out myself.

[bluewavenet]

Things have moved on and CPD has matured more and more.
For example the latest versions of the Facebook App now initially try:
http://h.fb.com/
Latest versions of Firefox have a built in and enabled CPD trying http://detectportal.firefox.com/
The list grows.

[bluewavenet]

I think this was all a combination of mismatching native CPD and Browser CPD that has now been resolved by the various vendors, both OS and Browser.
https redirection is not required in just about all situations where NDS is likely to be employed now that CPD is mature.

[dsmh]

This last part: "https redirection is not required in just about all situations where NDS is likely to be employed now that CPD is mature." Is not true, I've tried NDS with more than 650 phones and non of them got the CPD working, since now, most of the Captive Portal tools support https.

This Issue should be reopened since NDS is causing several problems in all the networks I manage, by the lack of https support.

Please fix this!

[bluewavenet]

CPD is the universally excepted standard by all OSs and (just about) all browsers and I could show you logs from NDS based captive portals showing hundreds of thousands of operating CPDs on mobiles, tablets, laptops and desktops.
Very few captive portals these days capture on port 443 as this generates dire errors on user machines and is totally unnecessary.
You might think captive portals are supporting https whereas in fact they are not, it is the CPD on devices that is doing, in the background, a port 80 request to one of many many special web pages set up specifically for CPD.
CPD was developed initially by Google in the early days of Android and has developed greatly since then and been adopted by everyone.
The three most used CPD urls in use today are:
http://connectivitycheck.gstatic.com/generate_204
http://captive.apple.com/hotspot-detect.html
http://www.msftconnecttest.com/redirect
All CPD implementations have a built in detection URL, depending on vendor and some can be changed from default.
You are clearly having a problem, so let us know some details of your NDS configuration, typical configurations and the type/versions of the 650 phones. This must be either a peculiar misconfiguration server side or a very specific "corporate" mobile setup.