On LEDE? No it doesn't. And probably will never be.
Exactly what? the force or not force https? that involves many technicisms and many of the arguments there are opinions about but you need to know how it works and when it is not recommended to chose it. (alternate content, blank pages, test pages, content restriction, services/app restrictions, etc) public or controlled devices/users internet access, knowledge of the users (yes, there is people that see MITM warning but ignores because it sees https, even browsers with poor UI/UX and app that ignore or doesn't validate certificates.
As far as OpenWRT / LEDE concerns it will be necessary to inspect http headers and detect and inyect a location header or do a similar thing in order to achive that. This will not be done at Operating system level, probably could will be done with a proxy-like software.
Opening LEDE for remote Web UI management from Internet is a bad idea, wherever it's over HTTP or HTTPS.
For local WebUI management of a LEDE device, you'd only need https if you suspect there're malicious actors inside your own home network which could snoop on your unencrypted traffic. Usually you'd then want to separate these suspicious devices into a different VLAN/WLAN anyways, so they wouldn't have access to snoop on your unencrypted HTTP password (enabling HTTPS is not the best solution in that case).
Better minds might correct the technicalities, but this is the gist of it.
Sorry, I misunderstood, I believed that LEDEuser wanted to LEDE act as a Router that forces users to browse using https only, not https only for webui/luci... (I interpreted HTTP Everywhere as the usual browser extensions called equally that does this) Those are two very different things...
Hey everyone thanks for the replies!
TBH I would be happy with just something that checks if theres an HTTPS version of the site im trying to visit, if not, just use HTTP, nothing else.
Or I could just block port 80 :P.
Good thing the days of HTTP are counted :).
@LEDEuser if you really want to do it I already done something like you describe, but sadly I just throw the code because it didn't work very well... so you could try to write by yourself, it will not be so difficult.
initial iptables rule to redirect all forwards to 80 port to a nginx local web server with uwsgi and python web app.
python web app (in flask) it receives the original http header with get and host headers, it checks for https port (at first pinging) and later I added a flag variable enabled in config so it checks the response headers and content received too. If success flask returns a location header to client with https url using original url (as it obtained from get and host headers) post data was loss, but at least it works for a 'starting to browse' like behaviour. On failure it adds a iptables ipset entry in order to iptables allow forwarding of that ipset list to original destination on 80 port.
I was doing some improvements (like doing a nslookup to get other ip's from same host/domain/subdomains, because some sites and CDN providers have some kind of protections and showed up some error pages but as I just said, I just throw the code because it was just too adventurous to me at that time. I also tryed to do the opposite too (redirecting 443 to 80 on nginx) just to make some fun of it, but everything failed of couse!
Edit, sorry but I do not rememeber if I used nginx or apache, mh... I think it was apache.