We had a problem, I think because we used an HTTP 301 redirect, and some browsers (cough, cough, IE9) would permanently cache the result. So the customer’s homepage would permanently go to the payment nag screen. The only way to undo it was some complicated sequence the included private browsing.
https://answers.microsoft.com/en-us/ie/forum/ie9-windows_7/possible-bug-in-ie-with-http-code-301-permanent/33cd03f0-8c82-e011-9b4b-68b599b31bf5 Probably it was our error using a 301 redirect instead of 302 but I’m not sure, that’s awhile ago. From: AF <af-boun...@af.afmug.com> On Behalf Of Jesse Dupont (Celerity Networks) Sent: Tuesday, September 10, 2019 10:03 PM To: Adam Moffett <dmmoff...@gmail.com> Cc: AnimalFarm Microwave Users Group <af@af.afmug.com> Subject: Re: [AFMUG] HTTPS redirect It seemed it had to do all sites because they were never trying to do a lookup for those test sites - the ones the OS was looking up had to be returned as the captive portal. I agree - once they paid, they really need to reboot their router. I did the same thing - set TTL to 1, but until the router was reboot, it was holding onto it. I decided it was worth it. YMMV. Jesse DuPont, Owner Celerity Networks LLC Celerity Broadband LLC On Sep 10, 2019, at 5:52 PM, Adam Moffett <dmmoff...@gmail.com <mailto:dmmoff...@gmail.com> > wrote: I toyed with mangling DNS, but the issue was after they paid they still have cached results pointing to the wrong IP. Even when my fake results had a TTL of 1 minute the client seemed to keep them longer than that. Is it sufficient to make DNS entries for the captive portal test sites or do you really have capture *all* DNS queries? On 9/10/2019 7:04 PM, Jesse DuPont wrote: Redirecting HTTPS, as you know, doesn't work because of the certificate. Even using your own certificate won't work because you can't get a trusted certificate issues that is valid for all domain names. The only think you can do is redirect them BEFORE they try to do HTTPS by triggering the captive portal detection methods in modern OS's - like they're in a hotel. https://success.tanaza.com/s/article/How-Automatic-Detection-of-Captive-Portal-works As you can see in that doc, all devices try to reach a known URL and expect to see a well-known result. If the result is different than what it expects, it assume it's behind a capture portal. We exploit this (in a non-black-hat-hacker kind-of-way). Our billing system is tied to our RADIUS server so when a suspended account authenticates, RADIUS sends an additional attribute (instead of denying it) - basically an address-list entry. We use this additional attribute on routers to treat traffic from these people differently. Primarily: 1) We DST-NAT all their DNS queries to a fake-master server which issues our "you haven't paid" landing page IP for ANY DNS query they do except for our website and billing portal, which are right (this is the first part of triggering captive portal detection - the IP returned to the OS isn't right). 2) We DST-NAT all their HTTP traffic to the proxy configured on the router, which triggers the second part of triggering captive portal detection - the HTTP server doesn't return the expected response. Also, using the proxy, we allow them to be able to reach our walled-garden content (our web page, our billing system portal) using the actual URLs, not just the IP. All other requests are redirected to our landing page. 3) In the firewall, even though we've essentially blocked it in the proxy, we only allow traffic from suspended customers to reach our landing page, our payment portal and our web site (the walled-garden). 4) Once they pay, they reboot their router and it's resolved. I can share specifics if you want. Jesse DuPont Network Architect email: jesse.dup...@celeritycorp.net <mailto:jesse.dup...@celeritycorp.net> Celerity Networks LLC Celerity Broadband LLC Like us! facebook.com/celeritynetworksllc <http://facebook.com/celeritynetworksllc> <celeritynetworks-GIF.gif> Like us! facebook.com/celeritybroadband <http://facebook.com/celeritybroadband> On 9/10/19 4:05 PM, Adam Moffett wrote: I already know the answer I think, but if you're redirection non-pay customers to a web page what do you do with (the majority) who have an HTTPS home page? do you A) present your own certificate and expect them to click through the warnings? B) Don't bother and just drop https? C) do something else? I told the boss if there was a way to do this then we should quit the ISP game and make a killing with phishing scams, but he seems to think there's a way to handle it. Thanks, Adam
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
