LetsEncrypt authentication options #6667
Comments
|
port 80 already gets diverted to 443, so http 2 https ? edit: ALSO it checks for any traffic on port 80 thats NOT letsencrypt related and diverts it to 443 |
|
Thats my point, if 8889 is in use and not 80, you dont want ALL TRAFFIC going from 80 to port 8889, defeats the whole point of using port 8889 to get it off port 80, might just as werll use port 80... ergo, if LetsEncrypt will ONLY USE port 80, then the only URL Mesh should serve is http://domain.com/.well-known/ any other URL gets 404 or blocked, this keeping port 80 secure for LetsEncrypt only and no one ever works out port 8889 is the real port to use as port 80 did not forward to it |
|
right ok, so you want an option/value to keep port 80 alive |
|
Port 80 doesnt service the SSL, LetsEncrypt will only read the file in the /well-known, once it sees that it then sends and saves the SSL and places it in the server. Port 80 cant serve the SSL, it only expects to see the SSL if HTTPS is used for checking and its not, otherwise it would expect port 443 and not port 80. The above is how i understand it from LetsEncrypt methods. The Mesh server should not be accessed on port 80, like at all, it should only be available on the port dictated in the config.json, maybe 8889 ANY other ports open (unless its strictly a redirect) should server nothing (or closed), however LetsEncrypt wants to see .well-known so that should be the ONLY folder tree available on any other open ports. Whats the point of getting an SSL for port 8889 when you can get to the whole server on port 80, there's no point in getting an SSL in the first place. so this idea just makes no sense to even bother with LetsEncrypt, especially if port 80 then forwards to 8889 blowing any possible reason you used port 8889 to hide its use. when 80 just waves you over to the secret hiding port you choose to use. |
|
Maybe I am mis-uderstanding something but I am going to throw this out there.. On my instance, I run it behind a reverse proxy (Nginx Proxy Manager) and it handles the SSL cert for the instance to the outside world while behind the reverse proxy, the actually mesh server is using a long term self signed cert. Nginx Proxy Manager will auto renew the SSL cert with Lets Encrypt. That way, the traffic is always encrypted (world to nginx and nginx to the mesh server). This works quite well and is typically how most people (that I know) tend to run their mesh instances. |
|
The request details are direct to Mesh only, there are many ways to deploy Mesh, however doesnt negate that this appears to be a security flaw that should not require an external service to fix. Further details could be organized in the next meeting. |
|
@GRIFFCOMMca I think u might need to discuss this over a video call, |
|
Just got this, let me know when your next free (you can message on reddit directly if you prefer, might be easier) |
Is your feature request related to a problem? Please describe.
Security of the whole server is compromised when LetsEncrypt is used, the idea is to make the server securr but it has to be very unsecured to get the SSL
Describe the solution you'd like
LetsEncryyot to allow options
When a secret port is used to stop access by most people on the internet (such as port 8889), to be able to get an SSL port 80 needs to be open, which negates the whole point of using port 8889, as the whole server is now available on port 80...
If LetsEncrypt wants to use port 80 or 443 and those ports are not the ones used as the normal web server then the only URL that should be available on those ports would be the ones required by LetsEncrypt to authenticate itself (/.well-known/) and no access to the whole server GUII login, doing so will allow outside to try many username and passwords on port 80 (which isnt even encrypted).
This option would also be fixed by allowing LetsEncrypt to use DNS as testing
The above assumes no access to reverse proxy as the server is installed alone in a LAN.
The text was updated successfully, but these errors were encountered: