5 ms·

Certificates suck. They are monumentally user unfriendly and complex. How many major internet properties have had outages driven by certificate renewal in the l

Certificates suck. They are monumentally user unfriendly and complex. How many major internet properties have had outages driven by certificate renewal in the last several years? Half? I know that enterprises I work with seem to have some sort of work impacting certificate problem every month. The ecosystem needs to become a lot more robust and user friendly in general. Unfortunately, I’m just a user of certificates not a cryptographer, so I’m not really qualified to design security critical aspects of the system, but here are some rough features that I’m looking for: - certificate warning date: a time period defined like expiry date that indicates that clients should warn of impending expiration but still click though - Make it easier for people to acquire and renew certs. Let’s encrypt is an amazing start here, but it’s not a universal solution yet - Formalize a way to solve the key distribution problem described in the article. Again, I’m not a security expert, but perhaps embedding a “replaces” concept into a certificate would work.

deleted 6y ago
[deleted]
danpalmer 6y ago
While I empathise with your viewpoint, that the ecosystem is hard to work with, I'm afraid I don't think there are any quick solutions to this. > certificate warning date If this is user-visible then for most companies this would be nearly as bad as expiry, and if it's not user visible then it's not useful. > Make it easier for people to acquire and renew certs Let's Encrypt pretty much solves this problem. The places where it doesn't work are companies that lock down the use of that sort of software. I don't think there's an easy way around that. > Formalize a way to solve the key distribution problem described in the article This problem isn't just the problem described in the article, it's _THE_ Key Distribution Problem. It has a Wikipedia entry, it's a chapter in most security textbooks, it's a lecture in most cryptography modules at universities. It's a _hard problem_. The practice of including Root CA certs on devices is the best thing we've come up with yet that has the security and scalability trade-offs necessary. If the "replaces" concept was viable in the general case I think we'd have likely implemented it, but I suspect it's too vulnerable, and likely only pushes back the problem.
- topkai22 6y ago
  I suspect we need standards/protocals defined at layers above the crypto-layer. For the certificate warning date, a yellow lock rather then giant red screens browsers show me now would be good, so at least in some cases users can do the notification. However, the real solution is standardized tooling that helps the organization detect the issue. Let's encrypt is definitely in this vain, however I think it needs to be the point where software defaults to user friendly behaviors like auto-renewal unless explicitly told not to. This seems like it could be address in standards making process, but maybe that's the wrong venue.
- user5994461 6y ago
  Certificates don't have to be difficult. The major CDN and hosting providers can setup TLS automatically with no user action. CloudFlare rolled great command line tools to handle internal certificates and CA (see cfssl). I've worked at startups with fully functional PKI. It's almost trivial to achieve, as long as you've got configuration management over all the servers (ansible, salt and assimilated). On the other hand. I've worked at a large bank trying to make TLS work across the firm and it was a mess. There was no motivation to have any automation around certificates management and no control over server configurations. One simple issue for example, CA on linux are managed by the ca-certificates package, all it takes to keep TLS working is to upgrade that package every couple years "apt-get upgrade ca-certificates". Some servers haven't had upgrade since 2015. It wasn't particularly difficult to get 10k servers from 5 departments upgraded after handing them instructions to do so, but of course a few other departments won't act until things break (and sometimes still won't act in spite of active incidents).

deleted 6y ago

[deleted]

danpalmer 6y ago

While I empathise with your viewpoint, that the ecosystem is hard to work with, I'm afraid I don't think there are any quick solutions to this. > certificate warning date If this is user-visible then for most companies this would be nearly as bad as expiry, and if it's not user visible then it's not useful. > Make it easier for people to acquire and renew certs Let's Encrypt pretty much solves this problem. The places where it doesn't work are companies that lock down the use of that sort of software. I don't think there's an easy way around that. > Formalize a way to solve the key distribution problem described in the article This problem isn't just the problem described in the article, it's _THE_ Key Distribution Problem. It has a Wikipedia entry, it's a chapter in most security textbooks, it's a lecture in most cryptography modules at universities. It's a _hard problem_. The practice of including Root CA certs on devices is the best thing we've come up with yet that has the security and scalability trade-offs necessary. If the "replaces" concept was viable in the general case I think we'd have likely implemented it, but I suspect it's too vulnerable, and likely only pushes back the problem.

topkai22 6y ago
I suspect we need standards/protocals defined at layers above the crypto-layer. For the certificate warning date, a yellow lock rather then giant red screens browsers show me now would be good, so at least in some cases users can do the notification. However, the real solution is standardized tooling that helps the organization detect the issue. Let's encrypt is definitely in this vain, however I think it needs to be the point where software defaults to user friendly behaviors like auto-renewal unless explicitly told not to. This seems like it could be address in standards making process, but maybe that's the wrong venue.
user5994461 6y ago
Certificates don't have to be difficult. The major CDN and hosting providers can setup TLS automatically with no user action. CloudFlare rolled great command line tools to handle internal certificates and CA (see cfssl). I've worked at startups with fully functional PKI. It's almost trivial to achieve, as long as you've got configuration management over all the servers (ansible, salt and assimilated). On the other hand. I've worked at a large bank trying to make TLS work across the firm and it was a mess. There was no motivation to have any automation around certificates management and no control over server configurations. One simple issue for example, CA on linux are managed by the ca-certificates package, all it takes to keep TLS working is to upgrade that package every couple years "apt-get upgrade ca-certificates". Some servers haven't had upgrade since 2015. It wasn't particularly difficult to get 10k servers from 5 departments upgraded after handing them instructions to do so, but of course a few other departments won't act until things break (and sometimes still won't act in spite of active incidents).