5 ms·
I'm kind of had enough of unnecessary policy ratcheting, it's a problem in a every industry where a solution is not possible or practical; so the knob that can
by ottah 10mo ago
I'm kind of had enough of unnecessary policy ratcheting, it's a problem in a every industry where a solution is not possible or practical; so the knob that can be tweaked is always turned. Same issue with corporate compliance, I'm still rotating password, with 2fa, sometimes three or four factors for an environment, and no one can really justify it, except the fear that not doing more will create liability.
- tgsovlerkhgsel 10mo agoThis was stated as a long-term goal long ago. The idea is that you should automate away certificate issuance and stop caring, and to eventually get lifetimes short enough that revocation is not necessary, because that's easier than trying to fix how broken revocation is.
- ryandrake 10mo agoThe problem is when the automation fails, you're back to manual. And decreasing the period between updates means more chances for failure. I've been flamed by HN for admitting this, but I've never gotten automated L.E. certificate renewal to work reliably. Something always fails. Fortunately I just host a handful of hobby and club domains and personal E-mail, and don't rely on my domains for income. Now, I know it's been 90 days because one of my web sites fails or E-mail starts to complain about the certificate being bad, and I have to ssh into my VPS to muck around. This news seems to indicate that I get to babysit certbot even more frequently in the future.
- LtWorf 10mo agoI did manage to set it up and it has been working ok but it has been a PITA. Also for some reason they contact my server over HTTP, so I must open port 80 just to do the renovation.
- patmorgan23 10mo agoThat would be because you set up the HTTP-01 challenge as your domain verification method. https://letsencrypt.org/docs/challenge-types/ https://letsencrypt.org/docs/challenge-types/
- eek2121 10mo agoReally? I've never had it fail. I simply ran the script provided by LE, it set everything up, and it renewed every time until I took the site down for unrelated (financial reasons). Out of curiousity, when did you last use LE? Did you use the script they provided you or a third party package?
- ryandrake 10mo agoI set it up ages ago, maybe before they even had a script. My setup is dead simple: A crontab that runs monthly: 0 2 1 * * /usr/local/bin/letsencrypt-renew And the script: #!/bin/sh certbot renew service lighttpd restart service exim4 restart service dovecot restart ... and so on for all my services That's it. It should be bulletproof, but every few renewals I find that one of my processes never picked up the new certificates and manually re-running the script fixes it. Shrug-emoji.
- jacquesm 10mo agoYes, same for me. Every few months some kind internet denizen points out to me that my certificate has lapsed, running it manually usually fixes it. LE software is pretty low quality, I've had multiple issues over the years some of which culminated in entire systems being overwritten by LE's broken python environment code.
- account42 10mo agoIf it's happening regularly wouldn't it make sense to add monitoring for it? E.g. my daily SSL renew check sanity-checks the validity of the certificates actually used by the affected services using openssl s_client after each run.
- noAnswer 10mo agoI don't know how old "letsencrypt-renew" is and what it does. But you run "modern" acme clients daily. The actual renewal process starts with 30 days left. So if something doesn't work it retries at least 29 times. I haven't touched my OpenBSD (HTTP-01) acme-client in five years: acme-client -v website && rcctl reload httpd My (DNS-01) LEGO client sometimes has DNS problems. But as I said, it will retry daily and work eventually.
- vrighter 10mo agoI set it up last year and haven't had to interact with it in the slightest. It just works all the time for me.
- LtWorf 10mo agoIt costs more to let's encrypt.
- Spooky23 10mo agoIt’s a stupid policy. To solve the non-existent problem with certificates, we are pushing the problem to demonstrating that we have access to a DNS registrar’s service portal.
- toddgardner 10mo agoIt's not really a stupid problem, its the BygoneSSL problem: https://www.certkit.io/blog/bygonessl-and-the-certificate-that-wouldnt-die https://www.certkit.io/blog/bygonessl-and-the-certificate-th...
- bigbuppo 10mo agoIt also ignores the real world as the CA/Browser forum admits they don't understand how certificates are actually used in the real world. They're just breaking shit to make the world a worse place.
- dijit 10mo agoeverything that uses TLS is publicly routable and runs a web service don’t you know. Well, you could also give every random server you happen to configure an API key with the power change any DNS record it wishes.. what could go wrong? #security
- johncolanduoni 10mo agoThat’s why the HTTP-01 challenge exists - it’s perfect for public single-server deployments. If you’re doing something substantial enough to need a load balancer, arranging the DNS updates (or centralizing HTTP-01 handling) is going to be the least of your worries. Holding public PKI advancements hostage so that businesses can be lazy about their intranet services is a bad tradeoff for the vast majority of people that rely on public TLS.
- dijit 10mo agoand my IRC servers that don’t have any HTTP daemon (and thus have the port blocked) while being balanced by anycast geo-fenced DNS? There are more things on the internet than web servers. You might say “use DNS-01”; but thats reductive- I’m letting any node control my entire domain (and many of my registrars don’t even allow API access to records- let alone an API key thats limited to a single record; even cloud providers dont have that). I don’t even think mail servers work well with the letsencrypt model unless its a single server for everything without redundancies. I guess nobody runs those anymore though, and, I can see why.
- cpach 10mo agoFWIW, there are ways to use DNS-01 without an API key that can control your entire domain. https://hsm.tunnel53.net/article/dns-for-acme-challenges/ https://hsm.tunnel53.net/article/dns-for-acme-challenges/
- ottah 10mo agoEnforcing an arbitrary mitigation to a problem the industry does not know how to solve doesn't make it a good solution. It's just a solution the corporate world prefers.
- tsimionescu 10mo agoExcept this isn't really viable for any kind of internal certs, where random internal teams don't have access to modify the corporate DNS. TLS is already a horrible system to deal with for internal software, and browsers keep making it worse and worse. Not to mention that the WEBPKI has made it completely unviable to deliver any kind of consumer software as an offline personal web server, since people are not going to be buying their own DNS domains just to get their browser to stop complaining that accessing local software is insecure. So, you either teach your users to ignore insecure browser warnings, or you tie the server to some kind of online subscription that you manage and generate fake certificates for your customer's private IPs just to get the browsers to shut up.
- noAnswer 10mo agoPrivate CAs and CERTs will still be allowed to have longer lives.
- tsimionescu 10mo agoThis doesn't help that much, since you still have to fiddle with installing the private CA on all devices. Not much of a problem in corporate environments, perhaps, but a pretty big annoyance for any personal network (especially if you want friends to join).
- account42 10mo agoWe could have just fixed OCSP stapling instead. Or better yet scrap the CA nonsense entirely and just use DANE.
- vladostman 10mo agoI just post the password semi-publicly on some scratchpad (like maybe a secret gist that's always open in browser or for 2fa a custom web page with generator built in) if any of those policies get too annoying. Bringing number of factors back to one and bypassing 'cant use previous 300000' passwords bs. Works every time.
- jfindper 10mo ago>I'm still rotating password A bit off-topic, but I find this crazy. In basically every ecosystem now, you have to specifically go out of your way to turn on mandatory rotation. It's been almost a decade since it's been explicitly advised against in every cybersec standard. Almost two since we've done the research to show how ill-advised mandatory rotations are.
- mwigdahl 10mo agoBut that would mean doing less, and that's by default bad. We must take action! Think of the children! I tried at my workplace to get them to stop mandatory rotation when that research came out. My request was shot down without any attempt at justification. I don't know if it's fear of liability or if the cyber insurers are requiring it, but by gum we're going to rotate passwords until the sun burns out.
- mboerwink 10mo agoPCI still recommends 90 day password changes. Luckily they've softened their stance to allow zero-trust to be used instead. They're not really equivalent controls, but clearly laid out as 'OR' in 8.3.9 regardless.
- jfindper 10mo agoI think it's only a requirement if passwords are the sole factor, correct? Any other factor or zero-trust or risk-based authentication exempts you from the rotation. It's been awhile since I've looked at anything PCI. In any case, all my homies hate PCI.
- deleted 10mo ago[deleted]
- jofla_net 10mo agoYeah the best/worst part of this is that nobody was stopping the 'enlightened' CA/Browser Forum from issuing shorter certificates for THIER fleets, but no we couldn't be allowed to make our own decisions about how we best saw the security of the communications channel between ourselves and our users. We just weren't to be allowed to be 'adult' enough. The ignorance about browser lock-in too, is rad. I guess we could always, as they say, create a whole browser, from scratch to obviate the issue, one with sane limitations on certificate lifetimes.
- ekr____ 10mo agoI fear this reflects two misunderstandings. First, one of the purposes of shorter certificates is to make revocation easier in the case of misissuance. Just having certificates issued to you be shorter-lived doesn't address this, because the attacker can ask for a longer-lived certificate. Second, creating a new browser wouldn't address the issue because sites need to have their certificates be acceptable to basically every browser, and so as long as a big fraction of the browser market (e.g., Chrome) insists on certificates being shorter-lived and will reject certificates with longer lifetimes, sites will need to get short-lived certificates, even if some other browser would accept longer lifetimes.
- zamadatix 10mo agoI always felt like #1 would have better been served by something like RPKI in the BGP world. I.e. rather than say "some people have a need to handle ${CASE} so that is the baseline security requirement for everyone" you say "here is a common infrastructure for specifying exactly how you want your internet resources to be able to be used". In the case of BGP that turned into things like "AS 42 can originate 1.0.0.0/22 with maxlength of /23" and now if you get hijacked/spoofed/your BGP peering password leaks/etc it can result in nothing bad happening because of your RPKI config. The same in web certs that could have been something like "domain.xyz can request non-wildcard certs for up to 10 days validity". Where I think certs fell apart with it is they placed all the eggs in client side revocation lists and then that failure fell to the admins to deal with collectively while the issuers sat back. For the second note, I think that friction is part of their point. Technically you can, practically that doesn't really do much.