What's new

Feature Request:GUI for lets encrypt cert requests and renewal.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

scyto

Regular Contributor
My Synology NAS just got a UI to request and update certs.

It certainly makes life simple - it only requires that the lets encrypt servers can access the machine that the cert is being generated from.

It would be great to have something like this in merlin firmware.
 
My Synology NAS just got a UI to request and update certs.

It certainly makes life simple - it only requires that the lets encrypt servers can access the machine that the cert is being generated from.

It would be great to have something like this in merlin firmware.

I have a feeling this will take some time to trickle down to the consumer level. We're starting to see it being supported on Enterprise appliances slowly and even Enterprise servers. Let's Encrypt is still fairly young so while I'm sure this will be standard in the future for DV Certs to be standard and free with easy UIs it's probably going to take time for the "trickle down" effect to occur.
 
it would require internet accessible web service on the router, which means a lot of security implications.

All for what? to not need to add router cert to local repo?
 
Apparenltyy not - so unsure if you are asking that rhetorically or not? Though when i follow that link where am i supposed to go next?

Or are you referring to the 'new features' statement of the goal. Merlin has introduced many new features, these may not have been coded by merlin but he has chosen to pull them in.

I have no clue what UI is or isn't out there in OSS land that could be brought in, i am sure there are UIs in other OSS products

. As such a request like this seems a valid request. Like asking for any feature like many others have done and the firmware has got. Bottom line - what's your point besides posting unhelpful and condescending passive aggressive replies?
 
Last edited:
it would require internet accessible web service on the router, which means a lot of security implications.

All for what? to not need to add router cert to local repo?
I agree there is a cost benefit to that that needs to be thought about. But i would argue a)the service only needs to be open for the length of time to request the cert / renew it (seconds). B) many (most?) people putting SSL cert on their ASUS router is so they can expose multiple services and in some case the admin UI to the web. At least that's what the guides on this site seem to mostly be about.

I assume you would be against letsencrypt modules being in the build for the same reason - i.e. this i not about UI but having the modules and scripts there that can be used? If so i at least understand your perspective but i believe for each person it is a cost benefit analysis of risk vs benefits of opening ports or not. Personally i have a whole bunch of services open to the web and I am happy have enough process and procedures to mitigate the risks to my level of acceptance.
 
Last edited:
I agree there is a cost benefit to that that needs to be thought about. But i would argue a)the service only needs to be open for the length of time to request the cert / renew it (seconds). B) many (most?) people putting SSL cert on their ASUS router is so they can expose multiple services and in some case the admin UI to the web. At least that's what the guides on this site seem to mostly be about.

I assume you would be against letsencrypt modules being in the build for the same reason - i.e. this i not about UI but having the modules and scripts there that can be used? If so i at least understand your perspective but i believe for each person it is a cost benefit analysis of risk vs benefits of opening ports or not. Personally i have a whole bunch of services open to the web and I am happy have enough process and procedures to mitigate the risks to my level of acceptance.

Whaaaaaat? Exposing the proprietary HTTPD to the web is a bad, bad, bad idea. We (I hope) do not advocate that in any way.
 
What do you mean proprietary? the main httpd is open source AFAIK. aiclouds is not, many of us are quite ok exposing the std httpd; same risk profile as vpn etc. but i understand if that's not acceptable in your eyes, everyones approach to risk is different.

i dont think any one is advocating it -it is all about risk management, if you are connected to the internet you have risk no matter what you are doing! i am happy i can manage that risk with 21 years of IP networking security experience. is it risk free? no, but there is on old saying one port or 65k ports open - its all the same difference..... port hijacking is a bitch :)

i'll scare you more, i even make extensive use of upnp :)
 
What do you mean proprietary? the main httpd is open source AFAIK. aiclouds is not, many of us are quite ok exposing the std httpd; same risk profile as vpn etc. but i understand if that's not acceptable in your eyes, everyones approach to risk is different.

i dont think any one is advocating it -it is all about risk management, if you are connected to the internet you have risk no matter what you are doing! i am happy i can manage that risk with 21 years of IP networking security experience. is it risk free? no, but there is on old saying one port or 65k ports open - its all the same difference..... port hijacking is a bitch :)

i'll scare you more, i even make extensive use of upnp :)

http://www.snbforums.com/threads/is-the-httpd-service-configurable.27596/#post-210691

Be careful with your many assumptions...

Read the entire thread I linked.
 
thanks for the link!

do you have link to any articles that go deeper, i keep finding stuff like this and it seems to relate to things other than httpd

http://www.pcworld.com/article/3036...over-insecure-routers-and-cloud-services.html

given the detail in the FTC report and the twenty years of audit, one would hope asus are now more highly motivated on security. the aicloud bypass was pretty serious, it is unclear to me if the csfr issues in the main webui still exist....

the ftc report makes for interesting reading https://www.ftc.gov/system/files/documents/cases/160222asuscmpt.pdf
 
Last edited:
thanks for the link!

do you have link to any articles that go deeper, i keep finding stuff like this and it seems to relate to things other than httpd

http://www.pcworld.com/article/3036...over-insecure-routers-and-cloud-services.html

given the detail in the FTC report and the twenty years of audit, one would hope asus are now more highly motivated on security. the aicloud bypass was pretty serious, it is unclear to me if the csfr issues in the main webui still exist....

the ftc report makes for interesting reading https://www.ftc.gov/system/files/documents/cases/160222asuscmpt.pdf

Hmm... I expected you to be defensive rather than inquisitive.
Impressive. Seriously. :)

The FTC thing is BS. See: http://www.snbforums.com/threads/ftc-dings-asus-for-selling-secure-routers.30621/

The CSRF "problem" is wide-spread. It is not an Asus only problem. Google CSRF for more info. It's more of a HTTP protocol or browser problem than a HTTP server problem (I think...).


For in-depth info about AsusWRT, read the posts of RMerlin, ryzhov_al, hggomes, john9527, zyxmon, sinshiva, yo-momma, etc.
 
Hehe, be careful with your many assumptions.

You are right about CSRF, I was looking for proven vulnerabilities on asus routers and CVE type reports specifically. I am aware of CSRF in general. It's one of the reasons I want to play with nginx more - as it can help mitigate issues when used as reverse proxy. It's also why I have some IDS running on the inside of my network - it's far more worrying to me than an open port with a web form.

I did turn off aicloud as bypassable auth is concerning. I haven't seen enough to make me worry about the main web page. Though 2 factor would be awesome feature that would make me happier doing that.... I am actually doing an experiment to surface the main web page out and see what happens.... Never have exposed that stuff in the past. I am also considering using the synology as the firewall - it has defense in depth with its security modules.... But I still can't bring my self to put in that role :)
 
Hehe, be careful with your many assumptions.

You are right about CSRF, I was looking for proven vulnerabilities on asus routers and CVE type reports specifically.

A lot of issues get fixed by Asus without these being assigned a CVE ID. I recommend checking Asus's release notes for the past year or two, you will see a fairly large number of CSRF/XSS issues that got fixed over time. While this is a good thing, it also indicates that the httpd daemon contains a fairly large amount of suspicious code.

The firmware's httpd was never hardened/tested as toroughly as, say, Apache or nginx. A complete code audit would be needed before I'd trust it as a public front-end. Until then, it's safer to keep it under lock and key, behind a VPN.
 
thanks, any ideas why they used the httpd that they did instead of using something like nginx... would seem a lot of weight to bear to doing something proprietary..?
 
thanks, any ideas why they used the httpd that they did instead of using something like nginx... would seem a lot of weight to bear to doing something proprietary..?

Because Broadcom has a custom scripting language to handle the webui, and there's also a lot of backend management done by httpd itself, it's not just a web server. To reproduce the same thing with nginx/apache with custom modules + some kind of super daemon would never have fitted in the 8 MB flash that Broadcom routers used for a long time.
 
I think let's encrypt allows for indirect verification too. You don't have to open httpd to the web, not even for the couple of seconds it takes for LE to verify. You can use email based verification either on the router itself if opkg has postfix or something similar, although I doubt it would be worth the hassle, or by forwarding the postfix port to a different system on the network. I would like to install a LE cert just for marginal benefit of not getting browser warnings, and because it sounds like fun. Also, isn't it possible to install apache/nginx using opkg and run it on a different port for the LE verification ?

Edit: It should also be possible to just forward 80/443 from the router to another machine on the LAN and do the LE stuff there directly.
 
Last edited:
I never heard of email verification, where is the details for this?

The official letsencrypt tools and the unofficial one I am using only do http based verification.

I really dont get why people even want this, the idea of a certificate is for trust between users and a server on the internet, not really for one user and his own device on his lan.
 
It looks like I was wrong. I thought LE also allowed verification by submitting a CSR which they can confirm by sending an email to the domain. That's how other ssl providers issue certs. It looks like LE doesn't have that path. It does allow creating csrs manually, but it still needs some interaction with httpd directly for the verification part.

Regarding the usefulness for lan, yes it doesn't make much difference. However, it's a good idea to have https only, even on the lan, and most users wouldn't bother with creating certs manually and trusting them in browsers.
 
Last edited:
you can have https only, it doesnt require a CA signed cert.

HTTPS is, by definition, both host verification and traffic encryption.

Forming a habit of reflexively over-riding untrusted HTTPS connections is not a good thing.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top