Letsencrypt working in 2.3
-
I have the same question as reggie14. Is the concern about Let's Encrypt specifically or just domain validated (DV) certificates in general? I understand erring on the side of caution. I'd do the same thing if in doubt. I haven't looked at the specific solutions offered in this thread, so my opinion isn't an endorsement of any of them.
I don't see how using a DV certificate for WebGUI access is worse than using a self signed certificate. Presumably there's already an expectation for users to understand the pros and cons of self signed certificates vs domain validated certificates vs extended validation (EV) certificates vs self managed PKI. How does that change by having support for Let's Encrypt?
For home and SOHO users, I think something like Let's Encrypt offers a fairly practical solution if you consider cost, convenience, and security. Both are a class of users that (in my experience) are the most likely to use the default, self signed certificate while ignoring browser warnings.
I currently use a DV certificate from StartSSL for my home pfSense box. Is it as secure as managing my own PKI and having a dedicated management machine that trusts only my self managed CA? No. Is it good enough for what I need? Absolutely.
There are also a couple of things in that Reddit thread that I'm not sure about.
-
Is the wildcard DNS issue actually that concerning? If you control the DNS for your domain you can (likely) remove wildcard entries. If you don't control the DNS, is it really your domain? Regardless, the Wikipedia entry for wildcard DNS says a wildcard entry won't override an explicitly defined DNS entry. So, if I use https://pfsense.example.com as a host, what kind of an attack would benefit from someone getting a certificate for https://somescam.example.com? Did I misunderstand the flaw / concern?
-
There are situations that warrant enabling the WebGUI on the WAN. The most obvious example is making configuration changes remotely. Temporarily enabling WAN access to the WebGUI can save a ton of hassle if you accidentally make a mistake that breaks VPN access.
I think the point of Let's Encrypt is to provide a baseline, minimum level of security with almost no effort. It's about raising the bar on the bottom end of security, not replacing existing best practices at the top end. As long as there aren't any technical flaws that reduce security, it's a much better option than having people bypassing certificate warnings IMHO.
-
-
I skimmed over the issue with the DV certs. It seems that the method that the attckers used was to gain access to the DNS and then create an entry for a machine they controlled. If someone else has access to your DNS then there is a problem right there. The Acme protocol assumes you have secured your DNS. This is of course and assumption. I think it is a valid one and companies should take takes to make sure they don't give someone else access. Without this rogue DNS entry, the flaw doesn't work.
For this reason, I think it is reasonable to use Let's Encrypt for Pfsense, at least for the home and SOHO user. I might want to get a seperate cert if I really had to make sure the system was secure, but I think that most users benefit from the easy access to encryption.
-
When I first heard of Let's Encrypt a little over a year ago in spring of 2015, I was really looking forward to their service. Then as some details and policies became known, and raised red flags, my enthusiasm quickly turned to skepticism.
NOYB @ Let's Encrypt
https://community.letsencrypt.org/users/noyb/activity/topicsGetting Bad Vibes
https://community.letsencrypt.org/t/getting-bad-vibes/3424Eric Rescorla (NSA back door involvement) (Youtube)
https://community.letsencrypt.org/t/getting-bad-vibes/3424/43NBR: Security vs. Privacy
https://community.letsencrypt.org/t/nbr-security-vs-privacy/4247Surveillance Advantages of Short Lifetime Certificates
https://community.letsencrypt.org/t/surveillance-advantages-of-short-lifetime-certificates/4559Seth Schoen: Let’s Encrypt Presentation (Youtube)
https://community.letsencrypt.org/t/seth-schoen-lets-encrypt-presentation-youtube/502Peter Eckersley: Let’s Encrypt Presentation (Youtube)
https://community.letsencrypt.org/t/peter-eckersley-lets-encrypt-presentation-youtube/530 -
One of the things about getting old(er) is that dampened response to the new shinny becomes the order of the day.
This, and the unease expressed by NYOB are the substance of my reluctance to rush pfSense onto the "Let's Encrypt" train.
-
I haven't seen any arguments that convince me that LE is any worse than any other non-EV certificate, ie regular DV.
Yes, there's a chance someone can pop your box without having access to your domain, but if so that is just lack of trying. If they have your box and want to get your domain, they have a huge attack surface against you to make sure they get your domain creds.
-
I haven't seen any arguments that convince me that LE is any worse than any other non-EV certificate, ie regular DV.
What are your credentials that say others should relay on your judgment?
Perhaps you just have a different risk tolerance than others. Or maybe you just haven't looked very diligently or objectively or have different assessment of the importance of certain things found.You certainly do not speak for me.
-
I haven't seen any arguments that convince me that LE is any worse than any other non-EV certificate, ie regular DV.
What are your credentials that say others should relay on your judgment?
Perhaps you just have a different risk tolerance than others. Or maybe you just haven't looked very diligently or objectively or have different assessment of the importance of certain things found.You certainly do not speak for me.
DV relies on the assumption that if you have control over the email delivery chain and control over DNS for domain.tld that you own domain.tld. The former can be subverted via the latter so the only real trust is control over DNS.
LetsEncrypt removes the assumption of control over email delivery chain, and relies on the actual thing being trusted by DV: control of DNS.
LE is no better or worse than DV certs. If you're not comfortable with DV certs then there's a huge percentage of sites you shouldn't trust, including this one.
-
As explained above, your arguments against LetsEncrypt are essentially arguments against DV certificates in general. Ok, I'll concede that - the world is an imperfect place. A site with only a DV (or LetsEncrypt) cert should probably not be trusted with the nuclear launch codes.
However, I find the crux of your argument to be completely ridiculous in the terms of the pfSense WebGUI. First, I disagree that there are ever good reasons to expose a firewall GUI to the internet. If you're really concerned about security, that should be the first thing to go. If you broke VPN, you would just need to get physical hands on the device (or have a second VPN). Second, there should only be (in a large organization) a handful of people that even have access to said WebGUI and only another handful of people that even know it exists. Are you really that concerned about an attacker spoofing your firewall WebGUI login that maybe 10 people have credentials to? If so you need to re-evaluate the group of people that have access to the WebGUI. They shouldn't be trusted anyhow.
Should we all get EV certificates? In a perfect world - sure, let's assume there's nothing better to do with $2k+ a year than going through the arduous process of EV for a WebGUI that isn't internet facing anyhow. But in reality, you're eliminating a valid and reasonable method for users to get encrypted access to their firewall GUI. I think we can all agree that LetsEncrypt is a better option than say using Chrome's –ignore-certificate-errors option. But that is exactly what you're implying that small businesses and home users should be doing. Because you wouldn't use a LetsEncrypt certificate on your installation. No one is saying you have to.
I also want to point out the double standard of making a huge huff about LetsEncrypt while leaving plain HTTP as a single radio button away. Clearly that's the better option. ::)
I love that last line in the reddit comment "This is exactly why there isn't support for Let's Encrypt in pfSense 2.3. (I'd looked at it and decided that it wasn't yet time.)"
Cool story, bro - I didn't realize pfSense was a maintained by a dictatorship. Not everyone's use case matches yours. Lighten up old man. -
Just thought I'd point out that there appears to be a feature request being worked on to have LetsEncrypt support in version 2.4…
https://redmine.pfsense.org/issues/5434
-
p.s. its not only usefull for the webgui itself, but also for other packages running on pfSense like for example haproxy or maybe vhosts package or even the captive portal might use a trusted cert to let people enter their voucher codes.
I would really like to have it available through 'official' channels instead of people needing to take lots of different scripts from sources the search-engine of choice presents..
-
Dear All,
As StartCom is likely to go down based in this issue: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview, I would expect that many more people will feel the need to switch to Letsencrypt soon. Having certbot or another update client in the HAProxy package in a sufficiently secure manner would superb then.
Regards,
Michael
-
This might be slightly off-topic for this thread, but it's at least related. I have a public-facing web server that obtains Let's Encrypt certificates for a number of internal hosts using the dehydrated script (https://github.com/lukas2511/dehydrated), and I'm able to automate deploying certs to most of those hosts using some fairly simple scripting. Typically this involves using scp to copy the relevant cert files to the appropriate locations, and then reloading the web server or other software using the cert. Is there any reasonably-straightforward way to automatically deploy a cert to a pfSense machine?
-
Dear All,
As StartCom is likely to go down based in this issue: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview, I would expect that many more people will feel the need to switch to Letsencrypt soon. Having certbot or another update client in the HAProxy package in a sufficiently secure manner would superb then.
Regards,
Michael
Yes, second that. I'm using StartCom at home now, using pfSense as a reverse proxy(add-on) that adds https for the websites running behind it. As StartCom is going down, I started looking into Letsencrypt and found this thread.
Letsencrypt seems ideal for this kind of stuff where you just want a little bit more(convenient) then self signed certificates. -
As StartCom is going down
They don't think they're going down. Their page mentions them generating new root certs for Mozilla to get off the shit list. IE and Chrome still trust them. It might be premature to dump your existing cert. I also use StartCom for my dinky site and I haven't seen any problems in Firefox with it yet.
-
@KOM:
IE and Chrome still trust them.
The(they have multiple, it's unclear to me which is which) root CA is also on the Chrome "shitlist" as of a few days ago.
Anyway, it seemend a good idea to switch to something else, as I do have to replace my certificates soon because of StartCom's problems. -
I've been doing some testing and the script here is working well;
https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh
put this script in your ~/.achme.sh/ folder and you're good to go with commands like;
~/.achme.sh/acme.sh –issue --dns -d yourdomain.tld -d sub.yourdomain.tld
after DNS is updated you're then able to update the certs and keys with
~/.achme.sh/acme.sh --renew -d yourdomain.tld (no need to specify all the subs here)this will create and update certs under ~/.achme.sh/yourdomain.tld/
I imported the key and cert manually in the web gui, but I'd like to do this automatically. Where are these keys/certs stored when using the web gui? and is it possible to load(move/copy) them with cli somehow?
After some digging I found the file /var/etc/haproxy/blabla.pem - however if i just cat my cert and key into this file and reloads haproxy, the old certificate is still in use.so.. how to import and reload certificates with cli?
-
I've been doing some testing and the script here is working well;
https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.shso.. how to import and reload certificates with cli?
Something similar to:
https://forum.pfsense.org/index.php?topic=107161.msg651063#msg651063 -
I've been doing some testing and the script here is working well;
https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.shso.. how to import and reload certificates with cli?
Something similar to:
https://forum.pfsense.org/index.php?topic=107161.msg651063#msg651063Thanks a lot for the "script.sh"! that helped me alot!
My certs that i use for haproxy is now being updated automatically!I see that in the script you are restarting the webgui (reloading the config file) with "/etc/rc.restart_webgui". I've checked "/etc/rc.*" but there's no haproxy restart script there (I can only find a "/etc/rc.haproxy_ocsp.sh" which updates haproxy OCSP responses).
How do I restart haproxy from cli?
EDIT: /usr/local/etc/rc.d/haproxy.sh -
FYI
https://github.com/pfsense/FreeBSD-ports/pull/89
that is all
-
Great to see this is getting some traction. I don't get all the hate towards LE. It seems even cPanel have implemented Letsencrypt into their AutoSSL feature.
I too am using a StartCom free DV cert to secure my pfsense webGUI, and a captive portal authentication page.
I intend to start using HAProxy soon to serve content from local webservers to the outside world directly from pfsense, rather than from a transparent Apache proxy inside the LAN. I'm already using Letsencrypt on this but I would much prefer to have this moved to the firewall.
I'll be watching this with great interest. Thanks for the great work guys.