4 ms·

Current desktop OSes don’t offer fine grained permissions, so there is no reason to hold software with specific features to a higher standard of integrity. Stil

Current desktop OSes don’t offer fine grained permissions, so there is no reason to hold software with specific features to a higher standard of integrity. Still, I recommend you install anything you can, mkcert included, from your package manager, as shown in the README. As for the snark, I stand by my provocation: I believe it’s best practice to automate TLS certificate renewal, and for 95% of deployments that means ACME, which for 95% of cases currently (but not necessarily) means Let’s Encrypt.

Waterluvian 8y ago
So if I'm using AWS certificate thingy I'm doing it wrong? Should I feel dumb, too? How dumb should I let myself feel before changing it to what the blog post says?
- FiloSottile 8y ago
  :/
segfaultbuserr 8y ago
It's still desirable to have the "release" version of source code tarballs signed, so maintainers who are making packages for a system distribution can check the integrity and get some level of confidence. But fair enough, at least GitHub has HTTPS. And well, it uses AWS for files, so a signature is still useful. From time to time, I encounter projects that the upstream doesn't support HTTPS and all tarballs don't have signatures. There's a high psychological pressure as a packager when one is dealing with projects like this, it's totally impossible to verify the integrity of the project and users may get pwned because of my package. My solution is (1) download the packages from different servers and compare the hash, (2) check the hash from the repository of other Linux distributions, to make sure at least my own network was not subjected to a MITM attack...
- pastage 8y ago
  There have been cases were official download servers have been seeded with bad payloads, I think it is usually solved within a day/week. So some time between downloading and comparing those hashes is probably a good factor as well. Automatic software installation is really a great way to have a backdoors into systems.
nodesocket 8y ago
AWS ACM is great, and they handle auto renewal for you as well. LetsEncrypt is fantastic, but there are other options.
- mgamache 8y ago
  AWS ACM is not for general use like LetsEncypt. >>You cannot install public ACM certificates directly on your website or application. You must install your certificate by using one of the services integrated with ACM and ACM PCA. https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html https://docs.aws.amazon.com/acm/latest/userguide/acm-overvie...
- FiloSottile 8y ago
  Anything with automated renewal is great.
  - forty 8y ago
    With AWS being the biggest cloud vendor, it means that most people could probably use ACM and still do things right (it's probably even better than LE as it's harder to mess it up). So your 95% above is probably extremely inaccurate :)
- deleted 8y ago
  [deleted]
josteink 8y ago
> Current desktop OSes don’t offer fine grained permissions Please correct me if I'm wrong, but my impression was that Windows offers several certificate stores on several security levels (AD-domain, machine, user), each one able to separately set ACLs for the certificate container, the individual certificate and the private key. Just because Linux and OSX doesn't support fine grained permissions, doesn't mean "current desktop OSes" doesn't. In fact the dominant desktop OS out there does this just fine and has for decades. It's the niche hipster-OSes used by developers and security experts (like Linux and Mac OS) which lacks this fine grained control (and I'm saying this as a Linux user). No need to say that what the guy asks for doesn't exist, when it clearly does in the OS with the clear majority market-share. Or... Again... Am I missing something crucial or really obvious here?
- stephenr 8y ago
  > Windows offers several certificate stores on several security levels (AD-domain, machine, user) macOS has different certificate stores and different keychains too. The OP's tool specifically opts to use the "admin" cert store in the system keychain, not user/user (the default for the `security add-trusted-cert` command). Honestly if you take Windows users out of the equation, this whole thing could just be a posix shell script, which would also solve the "verified release binaries" issue, IMO.
- ZoFreX 8y ago
  Windows doesn't have fine-grained permissions for adding to or changing certificate stores, though. When you run "mkcert -install" you'll get a generic prompt for mkcert requiring admin permissions, not a prompt for it changing certificate stores. I believe the point is that any software asking for admin could fiddle with your certificate stores, so there's no sense in asking for a higher standard of integrity from software that tells you it will do so.
  - detaro 8y ago
    > Windows doesn't have fine-grained permissions for adding to or changing certificate stores, though. From quick testing, in a non-elevated prompt, I can edit my local users trust store, but not the machine wide one. In an elevated prompt, I'm allowed to edit both. Seems like there are different permissions for different stores to me. (I haven't tested if any browser considers the user store, if they don't it's not very relevant for this specific use case. If I remember right, which browser wants certificates presented how was kind of a hassle)
tallanvor 8y ago
Requiring some manual steps for certificate renewal is actually standard practice many places. The renewal process offers a chance to recognize when you have sites or services that are no longer needed and should be shut down, whether it's to save money, reduce potential security risks, etc. --That's not to say that it needs to be completely manual, it could be as simple as an email being sent to a group and someone approving the renewal. Everything after that could be automated.
rospaya 8y ago
I'm in the middle of automating certificate renewals for my company and I really haven't thought about anything except Let's Encrypt. In fact I was surprised to see that various providers offer APIs to deploy paid certs.
- stephenr 8y ago
  I was pleasantly surprised to discover a few other CAs support the ACME protocol, however it’s either a free cert without support for SANs or certificates that require manual approval via a web control panel. I’m not against paying for a cert but don’t make it much harder than LetsEncrypt to use it.
- tialaramex 8y ago
  APIs to handle obtaining and deploying certificates weren't new with ACME. What's new in ACME is the stuff that lets you automate proof of control of a name. There's a fun thread on m.d.s.policy where I'm explaining this and Peter Guttman (who does some work in this area) starts out asserting that this feature is so unimportant and stupid that you could easily do it with other existing protocols, when that argument was destroyed he switches to claiming nobody ever wants to do such a thing, and eventually he retreated to the idea that the Web PKI is an insignificant application anyway and so it doesn't matter. The funniest part is that this all happened not when Let's Encrypt was an untried experiment but months into deployment when it was already a huge success. It was the equivalent of that moment when an elderly relative informs you that they can't see these new fangled computers ever amounting to much.

Waterluvian 8y ago

So if I'm using AWS certificate thingy I'm doing it wrong? Should I feel dumb, too? How dumb should I let myself feel before changing it to what the blog post says?

FiloSottile 8y ago
:/

segfaultbuserr 8y ago

It's still desirable to have the "release" version of source code tarballs signed, so maintainers who are making packages for a system distribution can check the integrity and get some level of confidence. But fair enough, at least GitHub has HTTPS. And well, it uses AWS for files, so a signature is still useful. From time to time, I encounter projects that the upstream doesn't support HTTPS and all tarballs don't have signatures. There's a high psychological pressure as a packager when one is dealing with projects like this, it's totally impossible to verify the integrity of the project and users may get pwned because of my package. My solution is (1) download the packages from different servers and compare the hash, (2) check the hash from the repository of other Linux distributions, to make sure at least my own network was not subjected to a MITM attack...

pastage 8y ago
There have been cases were official download servers have been seeded with bad payloads, I think it is usually solved within a day/week. So some time between downloading and comparing those hashes is probably a good factor as well. Automatic software installation is really a great way to have a backdoors into systems.

nodesocket 8y ago

AWS ACM is great, and they handle auto renewal for you as well. LetsEncrypt is fantastic, but there are other options.

mgamache 8y ago
AWS ACM is not for general use like LetsEncypt. >>You cannot install public ACM certificates directly on your website or application. You must install your certificate by using one of the services integrated with ACM and ACM PCA. https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html https://docs.aws.amazon.com/acm/latest/userguide/acm-overvie...
FiloSottile 8y ago
Anything with automated renewal is great.
- forty 8y ago
  With AWS being the biggest cloud vendor, it means that most people could probably use ACM and still do things right (it's probably even better than LE as it's harder to mess it up). So your 95% above is probably extremely inaccurate :)
deleted 8y ago
[deleted]

josteink 8y ago

> Current desktop OSes don’t offer fine grained permissions Please correct me if I'm wrong, but my impression was that Windows offers several certificate stores on several security levels (AD-domain, machine, user), each one able to separately set ACLs for the certificate container, the individual certificate and the private key. Just because Linux and OSX doesn't support fine grained permissions, doesn't mean "current desktop OSes" doesn't. In fact the dominant desktop OS out there does this just fine and has for decades. It's the niche hipster-OSes used by developers and security experts (like Linux and Mac OS) which lacks this fine grained control (and I'm saying this as a Linux user). No need to say that what the guy asks for doesn't exist, when it clearly does in the OS with the clear majority market-share. Or... Again... Am I missing something crucial or really obvious here?

stephenr 8y ago
> Windows offers several certificate stores on several security levels (AD-domain, machine, user) macOS has different certificate stores and different keychains too. The OP's tool specifically opts to use the "admin" cert store in the system keychain, not user/user (the default for the `security add-trusted-cert` command). Honestly if you take Windows users out of the equation, this whole thing could just be a posix shell script, which would also solve the "verified release binaries" issue, IMO.
ZoFreX 8y ago
Windows doesn't have fine-grained permissions for adding to or changing certificate stores, though. When you run "mkcert -install" you'll get a generic prompt for mkcert requiring admin permissions, not a prompt for it changing certificate stores. I believe the point is that any software asking for admin could fiddle with your certificate stores, so there's no sense in asking for a higher standard of integrity from software that tells you it will do so.
- detaro 8y ago
  > Windows doesn't have fine-grained permissions for adding to or changing certificate stores, though. From quick testing, in a non-elevated prompt, I can edit my local users trust store, but not the machine wide one. In an elevated prompt, I'm allowed to edit both. Seems like there are different permissions for different stores to me. (I haven't tested if any browser considers the user store, if they don't it's not very relevant for this specific use case. If I remember right, which browser wants certificates presented how was kind of a hassle)

tallanvor 8y ago

Requiring some manual steps for certificate renewal is actually standard practice many places. The renewal process offers a chance to recognize when you have sites or services that are no longer needed and should be shut down, whether it's to save money, reduce potential security risks, etc. --That's not to say that it needs to be completely manual, it could be as simple as an email being sent to a group and someone approving the renewal. Everything after that could be automated.

rospaya 8y ago

I'm in the middle of automating certificate renewals for my company and I really haven't thought about anything except Let's Encrypt. In fact I was surprised to see that various providers offer APIs to deploy paid certs.

stephenr 8y ago
I was pleasantly surprised to discover a few other CAs support the ACME protocol, however it’s either a free cert without support for SANs or certificates that require manual approval via a web control panel. I’m not against paying for a cert but don’t make it much harder than LetsEncrypt to use it.
tialaramex 8y ago
APIs to handle obtaining and deploying certificates weren't new with ACME. What's new in ACME is the stuff that lets you automate proof of control of a name. There's a fun thread on m.d.s.policy where I'm explaining this and Peter Guttman (who does some work in this area) starts out asserting that this feature is so unimportant and stupid that you could easily do it with other existing protocols, when that argument was destroyed he switches to claiming nobody ever wants to do such a thing, and eventually he retreated to the idea that the Web PKI is an insignificant application anyway and so it doesn't matter. The funniest part is that this all happened not when Let's Encrypt was an untried experiment but months into deployment when it was already a huge success. It was the equivalent of that moment when an elderly relative informs you that they can't see these new fangled computers ever amounting to much.