> Don’t blame your provider when they deploy CG-NAT, embrace IPv6 and global routing instead.
In theory this makes sense, but in practice my personal experience is that not a single wireline ISP I've ever seen deploy CG-NAT offered IPv6 service at all, nor did any of them indicate any intent or even interest when asked about it.
The mobile providers on the other hand have almost entirely gone IPv6-first, using 6>4 transition methods as the default form of v4 access which I fully support.
4>4 CG-NAT should never have existed and providers who deploy it without offering fully functional v6 should be shamed.
> (Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not as easy to set up as individual certificates for each subdomain.)
That's exactly what the new DNS-PERSIST-01 challenge is for, being able to authorize a specific system or set of systems to request certs for a given FQDN and optionally subdomains without having to give that system direct control over your DNS as the existing DNS-01 challenge requires.
As someone who also grew up on PC speaker, I think it sounds significantly worse than Wolfenstein 3D's PC speaker sound where it of course would be expected to be better than Wolf3D in every way.
I think they could have made something a lot better by, like Wolf, dropping music entirely from the PC speaker implementation. Focus on the sounds that matter.
For the same reasons as forcing companies to do it.
1. Revocation is a clusterfuck. Microsoft is currently failing to revoke tens of thousands of defective certificates for over seven months (the Baseline Requirements state that they should have been revoked within five days). Entrust was distrusted over repeated failures to revoke. Many TLS clients don't even bother to check revocation lists, or if they do they do it in a "fail-open" manner where inability to load the list does not prevent access which largely defeats the purpose. Short certificate lifetimes make revocation less important as both defective and compromised certificates age out rapidly, but without automation any meaningful reduction in lifetime directly translates to an increase in required effort which makes it a balancing act. With automation, however, reducing lifetimes is effectively free.
2. Automation is mostly a one-time cost. Manual renewal is a repeating cost. I started using LE to add HTTPS to my personal site when it first became available to the public in 2016 and then started using it for my work systems when our GoDaddy certs came up for renewal a bit less than a year later. Since then out of roughly 50 systems pulling around 70 certs I've had to "babysit" two of them once each, both because they were using wildcard certs which I was a very early adopter of and something about how I had set them up was technically wrong but worked in the initial version. Compare this to the "old world" where every couple of years I had to generally engage vendor support on both our server platforms and our CA because it had been long enough that things had changed on both sides so doing things manually required learning new things. Mandating short lifetimes is good for everyone. This is part of why LE has used a short lifetime since the beginning, to strongly encourage people to not try to do it without automation.
3. It's super easy. Lots of platforms have ACME support built in. For those that don't, packages like acme.sh are damn close to universal. If your system is able to expose a web server on port 80 it's basically trivial. If it's not, it's slightly harder. There's just not a good reason not to do it other than stubborn insistence. "Handcrafted TLS Certificates" just don't matter.
> I'm talking about managing two certificates so I can share a static site with a handful of friends. Each one takes about 10 minutes a year to update.
The personal site I started with is one certificate for a static site that I use for basically the same thing. It took me 10 minutes to set up in 2016 and I haven't thought about it for a second since then. It just works.
> Adding automation means I have to set up a process that I have to check up on at least once every 6.5 weeks to make sure it's still working.
Assuming you're using a common automation package and not rolling your own it should be included. I personally use acme.sh which can be configured to use email, XMPP, or HTTP(S) requests with prebuilt templates for most popular webhooks, as well as supporting fully custom notification scripts. I get an email every time it attempts a renewal that tells me if it succeeded or failed. Again one-time setup, easy, did it once literally almost a decade ago and haven't had to think about it since. As I pointed out in my previous post I did once have two of my systems fail to renew, I was notified, and I fixed it within a few minutes of seeing the emails.
Now that I'm actually thinking about the topic, these days for my work systems I have a platform that monitors for periodic updates and alerts me if they don't come in so I should probably reconfigure my notifications to use that instead of email and clean up my team's inboxes a bit by no longer needing to receive a couple dozen "everything's OK" mails every couple of months (or soon, couple of weeks).
> For this specific regulation, it's illegal to prevent someone who passes physical security screening and has paid their fare from boarding a plane.
Cite? Not that I'm doubting, just never heard this mentioned during the last news cycle around REAL ID when it "went in to effect" months ago. I didn't really look in to it any further as I've had a compliant ID for long enough it expires next year plus a passport so it didn't affect me.
Gilmore v. Gonzales (2006) sort of dealt with this. Dude wanted to fly, refused to present ID, refused the heightened security check, was told he couldn't fly. He sued, it went to the Supreme Court. The Supreme Court ruled that because the heightened security check was an option, the claimant's freedom of movement was not restricted.
There's a bunch of case law about freedom of movement, which is pretty radically protected in the United States. Not only can the federal government not put up unreasonable impediments to interstate travel, individual states and even private companies can't, either. Since American's aren't required to have ID (interestingly, this might be more political than legal, I can't find any case law enshrining the right to not have ID, just a lot of public outcry and backpedaling any time it's suggested), requiring one to travel interstate would be a significant impediment.
About six months ago I had a Dell Optiplex motherboard fail and they attempted to schedule a tech to come out the following day. I was not available for that and scheduled it a few days later but they did make as full of an effort as can be reasonably expected to make it happen within one business day.
The default warranty on at least the Optiplex line is one year of next business day service and upgrading to three years is cheap. I've never had a situation where same day service was worth the extra cost but it is an option.
I have always hated "m." domains for exactly this reason. They almost exclusively go one-way, mobile users get redirected to the mobile domain but desktop users never get redirected back, and all too often not only was the mobile version of the site objectively worse from the perspective of a desktop user but even the link to go back manually was either hard to find or nonexistent.
Wikipedia was one of the worst offenders, but lots of sites screwed this up in exactly the same way, and I feel it was a predecessor to modern "mobile first" web platforms that either treat desktop as second-class users or actively don't want desktop users.
Same problem though. The domain itself isn't the issue, it's that the redirect was only one way so mobile users always shared the mobile URL and desktop users who received that shared URL got the janky half-featured mobile site instead of the proper desktop one.
I'd make the assumption that posters located in Russia, China, NK, etc. are likely to be in some way tied to the state, where posters in India, random African nations, etc. are more likely to be private actors of which some will be US-based outsourcing to low-cost labor.
Its also just financially lucrative? The right tends to have more politically incorrect things to say and its no surprise click-farms from Asia would want to capitalize on that shock value.
> Wouldn't that only matter if the bug has no affect on little endian?
I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.
In theory this makes sense, but in practice my personal experience is that not a single wireline ISP I've ever seen deploy CG-NAT offered IPv6 service at all, nor did any of them indicate any intent or even interest when asked about it.
The mobile providers on the other hand have almost entirely gone IPv6-first, using 6>4 transition methods as the default form of v4 access which I fully support.
4>4 CG-NAT should never have existed and providers who deploy it without offering fully functional v6 should be shamed.
reply