7 ms·

It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or s

It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid. Plenty of existing applications will refuse to connect to a self-signed certificate on the belief that allowing the end-user to confirm a certificate offers basically 0 protection against malicious actors.

mmd45 2y ago
explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.
- stephenmac98 2y ago
  I didn't say a "pinned self signed cert is insecure" I said that self-signed certs are a lazy choice I also said "allowing the end-user to confirm a certificate offers basically 0 protection" If an average user get's prompted to trust a certificate they will do so blindly At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA Using a CA also allows for use of CRLs or OCPS. If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate. In Summary: Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs Using Self signed certificates creates more work when handling certificate leaks or certificate rotation Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate. BUT A self signed certificate is lower effort on the initial setup Lazy
  - mmd45 2y ago
    for the use case of a single user IMAP server this is all way, way, too complicated and buys you nothing in terms of security. it's completely analogous to why we dont use CAs to validate openssh host certificates.
    - Twisell 2y ago
      Yes it's a analogous using CA is still a higher bar, but it would arguably be better to also use CA to validate openssh host certificates for all the reasons he listed above. So maybe we should ask ourselves why can't we just figure out a way to improve handling of CA? Thanks to Let's Encrypt https coverage dramatically improved, now is maybe the time for more people to switch to self CA. I agree though that promoting adoption through good tooling and pedagogy would be a nicer approach than Apple slap on the wrist.
  - kortilla 2y ago
    You need to calm down and take a step back to realize not everyone needs to support 20 devices or even 2. What you’ve suggested is a ridiculous blanket statement assuming everyone is setting up things for a fleet of clients.
- lxgr 2y ago
  It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers. "Just use Letsencrypt" really is the correct answer for 99% of use cases, but good luck if you find yourself with one from the 1%. You'll get an army of people mindlessly parroting "best practices" and will assume you're incompetent/lazy if you can't find a way to make them work for you.
  - User11110 2y ago
    Internal CAs and self signed certificates are different. You can still generate a CA, sign your certificates, import your own CA into your phone and have that verify your certificates. You don't need Letsencrypt. But you'll learn in time.
    - lxgr 2y ago
      Thanks for the condescension, but I know how to do all of this. I've done it before. And because of that, I can first hand attest that it's way too complicated. No non-sophisticated user is able to run their own local CA, and that's why their NAS, IoT setup etc. all run over HTTP only, which in turn has implications for available web APIs (thanks to "secure origin only" policies and no exemption for local IPs/zeroconf domains) and many other things. It also doesn't work for at least modern Android apps, since Android no longer makes user-provided CA certificates available to (non-browser) apps anymore, I believe, unless they're compiled with a special debugging parameter. On iOS it's still possible, but I'm not sure how long it's going to stay that way.
      - stephenmac98 2y ago
        If a user set up a NAS they should be capable of googling "Openssl how to set up a CA" > First link fully explains it https://arminreiter.com/2022/01/create-your-own-certificate-authority-ca-using-openssl/ https://arminreiter.com/2022/01/create-your-own-certificate-... "How to import CA into iPhone" > First link fully explains it https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-installing-root-ca-ios https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-ins... "Android app customize trusted CAs" > First link fully explains it https://developer.android.com/privacy-and-security/security-config https://developer.android.com/privacy-and-security/security-... The barrier to entry on PKI isn't that it's hard, it seems to be that people just can't be bothered, PKI is among the most google-able tech processes out there
shakow 2y ago
There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself? Now if I were to provide this as a commercial service, sure, my customers may be worried.
- stephenmac98 2y ago
  "This is good enough because I don't expect anyone other than me will use it" is lazy What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
  - deleted 2y ago
    [deleted]
  - denkmoon 2y ago
    >"This is good enough because I don't expect anyone other than me will use it" is lazy is both a mischaracterisation of the argument, and wrong. It's not lazy, it's a choice with pros and cons. Just because you don't like it does not mean it is lazy. Again, issuing your own certificates is a choice. Allowing self signed certificates does not "significant lower the bar". Did you know that all root certificates are self signed? The management of multiple trusted certificates is basic administration for large private networks. Yes, TLS and certificate management can be complex, but that is not a good argument for disallowing it, and the idea that managing your own certificate trust is against "best practices" is ludicrous.
  - akira2501 2y ago
lxgr 2y ago
Or is operating a local-only mailserver not connected to the larger internet? I guess that's a lazy or stupid thing too, these days... I'm a fan of having TLS on by default for everything on the Internet, but I'm seriously annoyed by the collateral damage to local self-hosted services the implementation of that has caused. It shouldn't be this hard to e.g. host web server on my local network that browsers grace with "trusted website APIs", but it really is. Why on earth do I need to set up Letsencrypt (and by extension at least DNS) on a local website if I want to be able to use a game pad on it, for example!? https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure... We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs. For example, TOFU seems like a much better model for that use case than trying to bend the "public Internet" model until it fits. SSH has had considerable success in that model, for example.
- stephenmac98 2y ago
  You have to consider the rarity of your use case vs the use case they're defending against. How often do you think someone tries to connect their gamepad to a local server? Not never, but the total amount of users doing it is probably high tens or low hundreds at most Compare that to how often gamepad users try to connect to a malicious website - probably hundreds or ever thousands of times a day. Loosening certificate validation further expose the many less than competent users to risk, and the potential impact both on the customer base and on the product's reputation are significantly higher than the risks of making it cost a couple bucks a year to allow your gamepad to connect to a local server. For something like a computer, there is a legitimate argument for allowing the user to bypass SSL/TLS restrictions (after some resistance) because laptops are used for development. I can almost guarantee that the gamepad developers had an options for certificate validation bypass in it's developer options, but they're not gonna expose that needlessly when it offers no benefit, but exposes their customers to additional risk. Your gamepad is likely not a development device after all
  - lxgr 2y ago
    Any malicious website can access my gamepad, since it can trivially get a Letsencrypt certificate – the only requirement for getting "secure origin" API access. What exactly is this restriction preventing me from, then? (And what does a malicious website do with my gamepad data anyway?) > Not never, but the total amount of users doing it is probably high tens or low hundreds at most Yes, I'm fully aware that local hosting is rare in the grand scheme of things, but I think you're vastly underestimating the potential. It's currently not even possible to do much better even as a commercial NAS provider, and these are somewhat popular. A big part of that also seems like a chicken and egg problem: Fewer and fewer users do it because it's getting harder and harder, thanks to browser standards and OS defaults being largely driven by stakeholders that have no interest in it becoming easier. Yes, none of this is an evil conspiracy; it's just a question of incentives and priorities in the end. I just find it so sad how willingly even a "hacker" audience here embraces the move towards more and more centralization, on more than one dimension. (Peer-to-peer vs. client-to-server, "trusted CA only" vs. trust on first use, cloud vs. self-hosting etc.)
kortilla 2y ago
It’s 2024, we’ve seen countless examples of sophisticated hackers getting into all kinds of systems. Anybody who makes a blanket statement that you have to trust the public PKI is either lazy or stupid. SSH has TOFU and it works very well if you don’t want a key infrastructure.

mmd45 2y ago

explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.

stephenmac98 2y ago
I didn't say a "pinned self signed cert is insecure" I said that self-signed certs are a lazy choice I also said "allowing the end-user to confirm a certificate offers basically 0 protection" If an average user get's prompted to trust a certificate they will do so blindly At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA Using a CA also allows for use of CRLs or OCPS. If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate. In Summary: Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs Using Self signed certificates creates more work when handling certificate leaks or certificate rotation Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate. BUT A self signed certificate is lower effort on the initial setup Lazy
- mmd45 2y ago
  for the use case of a single user IMAP server this is all way, way, too complicated and buys you nothing in terms of security. it's completely analogous to why we dont use CAs to validate openssh host certificates.
  - Twisell 2y ago
    Yes it's a analogous using CA is still a higher bar, but it would arguably be better to also use CA to validate openssh host certificates for all the reasons he listed above. So maybe we should ask ourselves why can't we just figure out a way to improve handling of CA? Thanks to Let's Encrypt https coverage dramatically improved, now is maybe the time for more people to switch to self CA. I agree though that promoting adoption through good tooling and pedagogy would be a nicer approach than Apple slap on the wrist.
- kortilla 2y ago
  You need to calm down and take a step back to realize not everyone needs to support 20 devices or even 2. What you’ve suggested is a ridiculous blanket statement assuming everyone is setting up things for a fleet of clients.
lxgr 2y ago
It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers. "Just use Letsencrypt" really is the correct answer for 99% of use cases, but good luck if you find yourself with one from the 1%. You'll get an army of people mindlessly parroting "best practices" and will assume you're incompetent/lazy if you can't find a way to make them work for you.
- User11110 2y ago
  Internal CAs and self signed certificates are different. You can still generate a CA, sign your certificates, import your own CA into your phone and have that verify your certificates. You don't need Letsencrypt. But you'll learn in time.
  - lxgr 2y ago
    Thanks for the condescension, but I know how to do all of this. I've done it before. And because of that, I can first hand attest that it's way too complicated. No non-sophisticated user is able to run their own local CA, and that's why their NAS, IoT setup etc. all run over HTTP only, which in turn has implications for available web APIs (thanks to "secure origin only" policies and no exemption for local IPs/zeroconf domains) and many other things. It also doesn't work for at least modern Android apps, since Android no longer makes user-provided CA certificates available to (non-browser) apps anymore, I believe, unless they're compiled with a special debugging parameter. On iOS it's still possible, but I'm not sure how long it's going to stay that way.
    - stephenmac98 2y ago
      If a user set up a NAS they should be capable of googling "Openssl how to set up a CA" > First link fully explains it https://arminreiter.com/2022/01/create-your-own-certificate-authority-ca-using-openssl/ https://arminreiter.com/2022/01/create-your-own-certificate-... "How to import CA into iPhone" > First link fully explains it https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-installing-root-ca-ios https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-ins... "Android app customize trusted CAs" > First link fully explains it https://developer.android.com/privacy-and-security/security-config https://developer.android.com/privacy-and-security/security-... The barrier to entry on PKI isn't that it's hard, it seems to be that people just can't be bothered, PKI is among the most google-able tech processes out there

shakow 2y ago

There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself? Now if I were to provide this as a commercial service, sure, my customers may be worried.

stephenmac98 2y ago
"This is good enough because I don't expect anyone other than me will use it" is lazy What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
- deleted 2y ago
  [deleted]
- denkmoon 2y ago
  >"This is good enough because I don't expect anyone other than me will use it" is lazy is both a mischaracterisation of the argument, and wrong. It's not lazy, it's a choice with pros and cons. Just because you don't like it does not mean it is lazy. Again, issuing your own certificates is a choice. Allowing self signed certificates does not "significant lower the bar". Did you know that all root certificates are self signed? The management of multiple trusted certificates is basic administration for large private networks. Yes, TLS and certificate management can be complex, but that is not a good argument for disallowing it, and the idea that managing your own certificate trust is against "best practices" is ludicrous.
- akira2501 2y ago

lxgr 2y ago

Or is operating a local-only mailserver not connected to the larger internet? I guess that's a lazy or stupid thing too, these days... I'm a fan of having TLS on by default for everything on the Internet, but I'm seriously annoyed by the collateral damage to local self-hosted services the implementation of that has caused. It shouldn't be this hard to e.g. host web server on my local network that browsers grace with "trusted website APIs", but it really is. Why on earth do I need to set up Letsencrypt (and by extension at least DNS) on a local website if I want to be able to use a game pad on it, for example!? https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure... We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs. For example, TOFU seems like a much better model for that use case than trying to bend the "public Internet" model until it fits. SSH has had considerable success in that model, for example.

stephenmac98 2y ago
You have to consider the rarity of your use case vs the use case they're defending against. How often do you think someone tries to connect their gamepad to a local server? Not never, but the total amount of users doing it is probably high tens or low hundreds at most Compare that to how often gamepad users try to connect to a malicious website - probably hundreds or ever thousands of times a day. Loosening certificate validation further expose the many less than competent users to risk, and the potential impact both on the customer base and on the product's reputation are significantly higher than the risks of making it cost a couple bucks a year to allow your gamepad to connect to a local server. For something like a computer, there is a legitimate argument for allowing the user to bypass SSL/TLS restrictions (after some resistance) because laptops are used for development. I can almost guarantee that the gamepad developers had an options for certificate validation bypass in it's developer options, but they're not gonna expose that needlessly when it offers no benefit, but exposes their customers to additional risk. Your gamepad is likely not a development device after all
- lxgr 2y ago
  Any malicious website can access my gamepad, since it can trivially get a Letsencrypt certificate – the only requirement for getting "secure origin" API access. What exactly is this restriction preventing me from, then? (And what does a malicious website do with my gamepad data anyway?) > Not never, but the total amount of users doing it is probably high tens or low hundreds at most Yes, I'm fully aware that local hosting is rare in the grand scheme of things, but I think you're vastly underestimating the potential. It's currently not even possible to do much better even as a commercial NAS provider, and these are somewhat popular. A big part of that also seems like a chicken and egg problem: Fewer and fewer users do it because it's getting harder and harder, thanks to browser standards and OS defaults being largely driven by stakeholders that have no interest in it becoming easier. Yes, none of this is an evil conspiracy; it's just a question of incentives and priorities in the end. I just find it so sad how willingly even a "hacker" audience here embraces the move towards more and more centralization, on more than one dimension. (Peer-to-peer vs. client-to-server, "trusted CA only" vs. trust on first use, cloud vs. self-hosting etc.)

kortilla 2y ago

It’s 2024, we’ve seen countless examples of sophisticated hackers getting into all kinds of systems. Anybody who makes a blanket statement that you have to trust the public PKI is either lazy or stupid. SSH has TOFU and it works very well if you don’t want a key infrastructure.