Blocking HTTPs traffic

[rnicolaev]

Is there any way to block incoming HTTPs traffic except Facebook, because we are using facebook login button in our captive portal. But the problem is that we can't specify entire list of fb domains with one command like (www.facebook.com*). And if you will not allow all domains for Facebook the login page display incorrectly.

Your advise will be highly appreciated. As far as I know this can be easily done using radius server because radius server uses DNS from the router. But unfortunately we are not using radius server.

[rnicolaev]

Actually my issue is similar to this post
#282

but what as I see, that guy also didn't get an answer, how it can be done in a proper way

[benoitg]

The short answer is that as the web moves away from http towards systematic use of https, and content delivery networks (CDN) this is becoming increasingly hard to do, and there is an increasing amount of complex code to write.

Basically one needs many additional features for this to work seamlessly:

• A solution to redirect if the first request is https (there are a few, none of them especially good, many quite complex)
• A solution to extract all the domains referenced in a set of webpages (pretty trivial in a web language, pretty nontrivial to do reliably directly on an embedded system).
• A solution to open, AND MAINTAIN AS THEY CHANGE, the whitelisting of all IP aliases for each domain name extracted above (typically there is more than one IP per domain).
• Even the above will not be compatible with some load balancing solutions, but should work in most case.
• As there are more and more CDN used, one will have to be increasingly carefull to avoid whitelisting the whole of facebook, the whole of google. Or works, partially enable it enough that if you go to google or facebook, the portal doesn't splash the login, but not all images or script load.

(ok, not that short an answer it seems)

[rnicolaev]

Thanks a lot Benoit for your quick reply.
One more question, is there any advantage of using LEDE + WiFidog solution in front of Radius server, in order to prevent user from accessing Internet. As I know radius server uses Java and its quite old.

What is your personal opinion?

[benoitg]

It really depends on WHY you are doing it.

However, if for some reason you will have a RADIUS server anyway, you may be better served by a radius-centric solution like https://github.com/coova/coova-chilli

[rnicolaev]

Our primary aim is to prevent user from accessing internet until he passes verification process. On login we show captive portal with login buttons and after we show some marketing features, like survey, or sponsored ads and etc. But we noticed that sometimes combination of Lede and Wifidog not very stable within big number of connections. Our competitors are mainly using Radius server for the same reason but we don’t like that it purely work on Java.

On Thu, Jan 11, 2018 at 11:21 PM Benoit Grégoire ***@***.***> wrote: It really depends on WHY you are doing it. However, if for some reason you will have a RADIUS server anyway, you may be better served by a radius-centric solution like https://github.com/coova/coova-chilli — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#287 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKGvGMRGbg_SKJOCi0ZiDrs3hPvlRm16ks5tJl8ngaJpZM4Ra72Z> .

-- Thank you and regards, Ruslan Nicolaev <http://www.maptomedia.com/>

[JJEU]

hello

---

## about wifidog performance
yeah it's really bad. they are memory leaks too if used in a crowed place for several hours.
I used to install openwrt on APU2C2 router boards for crowed places (one of the most powerfull solutions available. this thing can run windows 7 !).
and i added an auto reboot each night, plus a script that automatically reboot the router if wifidog can't connect to the internet (usually it means that it crashed).

with all of the above, it's a bit better.

but still far away from the performace of the "appfree" fork of wifidog. this is done by a chinese team. but uses a "custom"version of SSL for compilation, wich is fishy.
see their benchmarking results : https://github.com/liudf0716/apfree_wifidog/blob/master/doc/Apfree_WiFidog%E4%B8%8E%E5%8E%9F%E7%89%88wifidog%E6%80%A7%E8%83%BD%E5%AF%B9%E6%AF%94%E6%8A%A5%E5%91%8A.md

it's mostly in chinese, but the english parts allows comprehension.
if you have dev able to audit the code and remove the possible backdoors (including the SSL module needed for compilation) it could be a good solution

Wifidog :

Benchmarking: GET http://www.taobao.com/
50 clients, running 600 sec.

Speed=752 pages/min, 22274 bytes/sec.
Requests: 6691 susceed, 830 failed.

Appfree

Benchmarking: GET http://www.taobao.com/
50 clients, running 600 sec.

Speed=1462 pages/min, 162575 bytes/sec.
Requests: 14618 susceed, 8 failed.

---

## About portal detection
i had the same problem when i worked at Ile Sans Fil

if you really want to desactivate portal detection form cell phones and new OS, add this in your wifidog.conf file.
in this scenario, DNS resolution MUST be served by the openWRT router. because the names are assigned to several IP. you want your router to resolve the name once, and use the same IP afterwards.
so you need to

• activated the DNS proxy
• and give the adress of openWRT's LAN interface as the DNS router in DHCP configuration.
• not allow port 53 in the global rules or the unknown users rules.
  you can also block port 53 output directly in openwrt for good measure.

Note : its add new kind of problems. especially if the people are using an https start page.

for this reason I usually i just leave open the 443 in "unknown users"
usually when browsing there is always a moment where you are redirected to a port 80 / HTTP ressource, so then the portal would kick in.
blocking the 443 in this situation is really a support nightmare. calls and calls and calls

Also, if you check the logs, you will see that wifidog check each line each time a client connects, so it adds charge on CPU/ram/etc

Rule Set: unknown-users

    FirewallRule allow udp port 67
    FirewallRule allow tcp port 67

#uncomment this to avoid phone support nightmare :
    FirewallRule allow tcp port 443
    FirewallRule allow tcp port 443


#comment this for users to be forced to use your DNS only. it's important or else 
  # FirewallRule allow udp port 53
   # FirewallRule allow tcp port 53

#Regles pour dejouer l'autodetection des pages portails sur les elephones intelligents
#apple
#FirewallRule allow tcp to www.appleiphonecell.com
#FirewallRule allow tcp to captive.apple.com

#Android Captive Portal Detection
#FirewallRule allow tcp to clients3.google.com
#FirewallRule allow tcp to connectivitycheck.android.com
#FirewallRule allow tcp to android.clients.google.com
#FirewallRule allow tcp to ggpht.com
#FirewallRule allow tcp to play.google.com 

#Apple iPhone, iPad with iOS 6 Captive Portal Detection
#FirewallRule allow tcp to gsp1.apple.com
#FirewallRule allow tcp to akamaitechnologies.com
#FirewallRule allow tcp to www.apple.com
#FirewallRule allow tcp to apple.com

#Apple iPhone, iPad with iOS 7, 8, 9 and recent versions of OS X
#FirewallRule allow tcp to www.appleiphonecell.com
#FirewallRule allow tcp to apple.com
#FirewallRule allow tcp to www.itools.info
#FirewallRule allow tcp to www.ibook.info
#FirewallRule allow tcp to www.airport.us
#FirewallRule allow tcp to www.thinkdifferent.us
#FirewallRule allow tcp to apple.com.edgekey.net
#FirewallRule allow tcp to akamaiedge.net
#FirewallRule allow tcp to akamaitechnologies.com

#Windows
#FirewallRule allow tcp to ipv6.msftncsi.com
#FirewallRule allow tcp to ipv6.msftncsi.com.edgesuite.net
#FirewallRule allow tcp to www.msftncsi.com
#FirewallRule allow tcp to www.msftncsi.com.edgesuite.net
#FirewallRule allow tcp to teredo.ipv6.microsoft.com
#FirewallRule allow tcp to teredo.ipv6.microsoft.com.nsatc.net