Earlier quoted context omitted.
One option is to run your own BIND instance configured however you like, and pay for one or more secondary DNS services to sync off it. You can even hide your own BIND instance from everyone outside your network and just point your NS records at the secondaries, if you’re worried about misconfiguration/DoS attacks/etc.
That sounds interesting. Would you know of any secondary DNS service headquartered in Europe? I always wanted to host DNS myself but since I lack a secondary DNS...
ACME v2 and Wildcard Certificate Support is Live
261–270 of 321 posts
Re: ACME v2 and Wildcard Certificate Support is Live
#262Earlier quoted context omitted.
What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable. I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.
There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS. [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
Re: ACME v2 and Wildcard Certificate Support is Live
#263Earlier quoted context omitted.
> Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes if you have one server, yes. else it's the other way around, because if you have multiple servers you need to do a lot of fancy stuff. And LE also does not work in your internal network if you do not have some stuff publicy accessible. And it also does not work against different ports. Oh and it's extremly hard to h…
You can use Let's Encrypt certificates for non-publicly reachable hosts by using the dns-01 challenge type. That, of course, means that you need some way of properly automating your DNS infrastructure to add the necessary TXT records which, admittely, is sadly not the case in many organizations. It's a solvable problem, though. I don't understand your last point. Where do you see the problem with letting a reverse pr…
Re: ACME v2 and Wildcard Certificate Support is Live
#264Earlier quoted context omitted.
A lot of ISPs, some huge like the "XfinityWifi" SSID, routinely inject their own javascript in HTTP pages. Some even take no care to namespace their javascript and wreck a party on your window globals, too.
This could be solved without HTTPS. People choose not to for ideological reasons.
Re: ACME v2 and Wildcard Certificate Support is Live
#265Earlier quoted context omitted.
Is there a "standard" TLD for internal use that will also fit this requirement? The problem here is that there's no such thing as domain ownership, only domain renting. You forget to pay your bill (read: someone loses an email) and a core part of your infrastructure is up in smoke, or worse, taken over by a squatter.
Of course not. If there was a domain reserved for internal use and everyone could get a cert for it, everyone would be able to impersonate your internal hosts. I don't think there's a way around coming up with a reliable process for renewing your domain. You somehow manage to do it for lots of other things already.
Re: ACME v2 and Wildcard Certificate Support is Live
#266Earlier quoted context omitted.
Thanks! This looks awesome. Can i automate it as well? I have been toying a little with wildcard using certbot on my Ubuntu OpenVPN appliance, but was a bit unsuccessful at the moment. Maybe i should just try and build a very tiny virtual sever that does nothing but spit out a wildcard domain certificate to some predefined destinations to have it used in anything that wants a certificate. Could be beneficial to a (la…
For provider with DNS support, you can put it in a cron, and then create symlink or some copy step at the end of cron to copy private key and full chain to appropriate location of your web server. I think acme.sh is the easiet to use in all of clients.
I've put my DNS to Cloudflare and after that the acme.sh was incredibly easy to implement thanks to their API implementations.
Also learned a valuble lesson: *.provider.com is not the same as provider.com :)
Re: ACME v2 and Wildcard Certificate Support is Live
#267Earlier quoted context omitted.
This will break many tools which currently rely on LE. E.g. mailinabox, which uses LE to set itself up.
I doubt they would just break it. I imagine if they do this then this will be announced sufficiently in advance (probably around two or three years) to allow people to update their ACME clients. Then you can just operate the ACMEv1 for existing domains until noone is asking for more (and scale down the architecture).
> Technically, Mail-in-a-Box turns a fresh cloud computer into a working mail server. But you don’t need to be a technology expert to set it up.
I'm just choosing MIAB as an example here. This applies to anything that LE now enables. People don't know they're using LE, much like IOT users don't know they're using HTTP/1.1. It's part of the plumbing. What's an ACME client? What's LE? What's v1?
This is probably happening for IOT devices across the globe just the same. A 2y expiration date is an order of magnitude too low for plumbing. Imagine if we suddenly decided to phase out HTTP/1.1 within two years.
We have to recognise that we are shoving HTTPS down people's throats. Pretty soon, HTTP will get big f-off warnings. OK: fair enough. However, if we're doing that, we should also provide a viable alternative, with the same reliability. Otherwise, HTTPS is a massive step backwards for the decentralised web. LE is that alternative, but not if we start breaking backwards compatibility every 2 years.
Re: ACME v2 and Wildcard Certificate Support is Live
#268Earlier quoted context omitted.
I doubt they would just break it. I imagine if they do this then this will be announced sufficiently in advance (probably around two or three years) to allow people to update their ACME clients. Then you can just operate the ACMEv1 for existing domains until noone is asking for more (and scale down the architecture).
The problem is that LE is being used as plumbing. I noticed MIAB was using LE because I recognise that SSL-out-of-the-box is something interesting, and I investigated. But I wager most people who use it will have no idea. They just install it, and "it works", as it should. great. What's HTTPS? That's the entire point of tools like MIAB, mind you: > Technically, Mail-in-a-Box turns a fresh cloud computer into a workin…
Rather, "after this point, no new domains may setup via v1", so any existing certificates and installations are grandfathered. Two years is sufficient for MIAB to update their software and distribute to users.
>LE is that alternative, but not if we start breaking backwards compatibility every 2 years.
Not what I'm saying either. They have a v2 now, we don't know if they need a v3. And they want to keep v1 running for a while.
But there will be a point where v1 will need to be switched off, similar to how modern browsers have switched off SSLv1 despite a lot of people still having servers running with that.
LE will, at some point, have to decide between keeping v1 running or moving away from old protocols to be able to evolve. And that cannot be infinitely pushed backwards.
Re: ACME v2 and Wildcard Certificate Support is Live
#269Earlier quoted context omitted.
It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.
>wosign Are you name dropping wosign just to be obtuse? They were untrusted because they were untrustworthy, not because Google just doesn't like them. https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...
Re: ACME v2 and Wildcard Certificate Support is Live
#270Earlier quoted context omitted.
I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.
Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening. Basically, I see it this way: - You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause th…
Consider the websites you view every day.. most of them are probably HTTPS by now.
It's the wild west, basically. Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?