Letsencrypt working in 2.3
-
There are reasons this isn't already in pfSense 2.3:
Caution is warranted.
https://www.reddit.com/r/PFSENSE/comments/4eqh2v/pfsense_23_letsencrypt_working_by_hand/d22nulb
-
Pullrequest for a acme package is pending (for a while now)..: https://github.com/pfsense/FreeBSD-ports/pull/89
Anyway certificates never ment that you should send every private detail about yourself over the connection without thinking. "Is this really my own banking site/gmail website.." .. As for validating domain ownership, if you can put contents behind a domain names webserver, that means that specific domain name is intended for you to use isn't it..? And LE does not provide wildcard certificates so your public www.company.tld webhoster wont be able to generate a certificate for your exchange.company.tld server hosted elsewhere.. To me it seems like the acme protocol is done in a legit way.. And a website with a 'valid' certificate called yourTrustedBankSite.hacked.tld you should not fill in your pin / security code / password no matter who signed the 'domain validated' certificate.. A official paid CA would happily provide signed certificates for *.hacked.tld with a single email send to hostmaster@hacked.tld.
Main point on that reddit discussion seems to be not to use 3rd party signed cert for the router webgui.. Using it for packages like haproxy is not something they specifically object.. (ive read over it..)
-
@jwt:
There are reasons this isn't already in pfSense 2.3:
Caution is warranted.
https://www.reddit.com/r/PFSENSE/comments/4eqh2v/pfsense_23_letsencrypt_working_by_hand/d22nulb
I'm sorry if this is off topic, but I'm very interested in understanding the security differences between Let's Encrypt and Domain Validated certs. As far as I can tell, the validation method used by Let's Encrypt doesn't seem particularly different than, say, Comodo's option of doing domain validation by putting a hash of a CSR at a particular URL. Is there some important distinction that I'm missing?
Admittedly, this seems like less of an argument in favor of Let's Encrypt, and more of an argument against DV certs…
-
so 14 and 15 cant be automated or done via terminal? If so 13 could be too and it seems like the whole thing can be configured to automatically update every 3 months.
-
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?
