RADIUSdesk

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
user_guide:md_on_lede_https [2016/11/17 14:54] – [Actions] adminuser_guide:md_on_lede_https [2016/11/17 16:13] (current) – [Requirements] admin
Line 9: Line 9:
   * A server with a public IP Address and FQDN having NGINX configured with a signed certificate by a known Certificate Authority (CA)   * A server with a public IP Address and FQDN having NGINX configured with a signed certificate by a known Certificate Authority (CA)
   * A LEDE build environment as stipulated in the page's parent document.   * A LEDE build environment as stipulated in the page's parent document.
-  * In our example we use here we have a server with a FQDN of 01.radiusdeskhosted.com+  * In our example we use here we have a server with a FQDN of 01.wifi-dashboard.com
   * We followed the standard instructions from LetsEncrypt to obtain a certificate for NGINX. (https://letsencrypt.org/)   * We followed the standard instructions from LetsEncrypt to obtain a certificate for NGINX. (https://letsencrypt.org/)
  
Line 39: Line 39:
   * Next we will look at all the technical issues around our work we just completed.   * Next we will look at all the technical issues around our work we just completed.
  
 +===== All the technical things =====
 +==== uamuissl ====
 +
 +  * When we specify **uamuissl** we enable the CoovaChilli Captive Portal to listen on port 4990 for requests (on top of the default of 3990)
 +  * These requests will be served over https and is thus encrypted.
 +  * We need to do this if we want to serve the login pages over https since many browsers does not allow you to '//step down//' e.g. going from https and then try to do Ajax request over http.
 +  * We also specify which certificates the CoovaChilli captive portal will use for this https transactions.
 +  * When  **uamuissl** is enabled the captive portal login page will include a **ssl** item in the query string e.g. ** ssl=https%3a%2f%2f01.wifi-dashboard.com%3a4990%2f**
 +  * Our dynamic login page has some logic build in to look for this and automatically then replace the queries to the CoovaChilli controller's http port (3990) with (4990).
 +  * You will see that the ssl item has a value of: **https://01.wifi-dashboard.com:499/**
 +  * By default if you try and ping this FQDN if will resolve to the public IP Address the server is running on.
 +  * Coova however pulls a fast one and intercepts DNS requests to the DNS server for **01.wifi-dashboard.com** and replaces it with the value if the UAMIP. (typically 10.100.0.1 or something similar)
 +  * //How does it know what to intercept and replace?// It looks at the value of **uamaliasname** and **domain** and concatenate them.
 +  * //What if I specified my own DNS server?// Then it will not work since it only replaces the reply if the query was to one of the DNS servers which Coova uses.
 +  * //Why does it do it?// The browser will go to a FQDN in the URL and NOT an IP Address. It then determines that the certificate is belonging to a FQDN. Then it ask the DNS server what is the IP Address of this FQDN. Once it has an answer it can compare with the IP Address it is visiting and confirm that hey are the same, else it will complain.
 +
 +==== redirssl ====
 +  * **redirssl** tells CoovaChilli to also listen on port 443 for incoming traffic.
 +  * If Coova is listening on port 443 it will answer as if it is the other side of the conversation. e.g. it will pretend to be https://www.youtube.com. \
 +  * Most browsers however are working in such a way as to check the certificate it got during the https transaction. If this certificate is not the same as that for which site it wants to go to it usually have a redirect to the login page mechanism.
 +  * Alternatively it will just stop with a message saying it thinks there is a man in the middle.
 +  * This is because in our case it expected Youtube's certificate but got WiFi-Dashboard instead.
 +  * As we mentioned many modern gadgets and operating systems support redirecting this to a login page though there will definitely be some devices that complains outright. 
 +  * This is the trade-off between not having https support and clients assume it does not work, also this should become better supported over time.