New rfc for captive portal identification

[gareth41]

Some people may already be aware of this. There is a new rfc released for network clients to identify if they are behind a captive portal. Involves sending out DHCP option 114 to the client in the DHCP request, this option contains the address of the captive portal where the client should authenticate - rather than the client relying on the redirect method to detect the presence of a captive portal.

https://tools.ietf.org/id/draft-ietf-capport-rfc7710bis-08.html
https://developer.apple.com/news/?id=q78sq5rv

I haven't tried this yet, but there should be a way to add this option to dnsmasq on openwrt so the router broadcasts this DHCP option to the wifidog client.

The main reason for the rfc is due to the web moving to https, currently majority of captive portals work by intercepting http requests and redirecting them, however with https this is seen as a man in the middle attack and will throw certificate errors on the client.

This brings me to another problem that wifi dog will face in the future. Currently auth is done via a token, and the client is sent a redirect request to the local gateway running libhttpd - this will probably fail when all major browsers start to enforce https by default (it's not happening at the moment, but is inevitable at some stage). Most likely warnings will be thrown at users when they are redirected to a regular http website and the browser may prevent the site from loading unless the users accepts the risk and clicks continue - just like when a certificate check fails on https - wifidog will no longer be able to authenticate clients if this happens.

One way around this is for the local gateway webserver to run https with a valid certificate. Another way to solve this issue is for the client to authenticate themselves on the auth server, then the auth server initiates a request directly to the gateway to allow the client through the firewall, rather than the client bring redirected to the gateway with a token. However this approach also has issues as the gateway talks to the auth server using http(s) requests, and so the auth server can not directly initiate realtime communication with the gateway.

One way to solve all of this is to use the websocket protocol, the gateway connects to the auth server once at startup using regular http(s) and the connection is then "upgraded" to two way communication. Commands could be exchanged in realtime between gateway and auth server using json. The open charge point protocol already does this (it uses websockets with json) to manage EV chargers on a central system, remote start commands can be sent in real time to a charger from the central system.

I may look at implementing this if there enough demand for it, currently this repository has been pretty quiet over the last few years. I'm also interested to know peoples thoughts on the above.