Earlier quoted context omitted.
Idea that's been floated before: TOFU plus a distributed network of people automatically sharing what cert fingerprints they encounter. Chances are high that you already hit Facebook on your $device, and if you all of a sudden retrieved a certificate that didn't match the one you had before, or that most other people online hadn't seen, halt and throw up the warnings. Given the exploitability, laziness, general failu…
Where do you store the trust from all those people to be able to query the statistics? That's just another central point of failure.
ACME v2 and Wildcard Certificate Support is Live
271–280 of 321 posts
Re: ACME v2 and Wildcard Certificate Support is Live
#272Earlier quoted context omitted.
This could be solved without HTTPS. People choose not to for ideological reasons.
How would you solve it without HTTPS?
"Injection" is the process of inserting content into the payload of a transport stream somewhere along its network path other than the origin. To prevent injection, you simply need to verify the contents of the payload are the same as they were at the origin. There are many ways to do this.
One method is a checksum. Simply provide a checksum of the payload in the header of the message. The browser would verify the checksum before rendering the page. However, if you can modify the payload, you could also modify this header.
The next method is to use a cryptographic signature. By signing the checksum, you can use a public key to verify the checksum was created by the origin. However, if the first transfer of the public key is not secure, an attacker can replace it with their own public key, making it impossible to tell if this is the origin's content.
One way to solve this is with PKI. If a client maintains a list of trusted certificate authorities, it can verify signed messages in a way that an attacker cannot circumvent by injection. Now we can verify not only that the payload has not changed, but also who signed it (which key, or certificate).
Note that this does not require a secure transport tunnel. Your payload is in the clear, and thus can be easily cached and proxied by any intermediary, but they can not change your data. So why don't we do this?
Simple: the people who have the most influence over these technologies do not want plaintext data on the network, even if its authenticity and integrity are assured. They value privacy over all else, to the point of detriment to users and organizations who would otherwise benefit from such capability.
Re: ACME v2 and Wildcard Certificate Support is Live
#273Earlier quoted context omitted.
Use Terraform to manage records. They have support for lots of DNS providers (AWS Route53, Google Cloud DNS, Cloudflare, DigitalOcean, Azure DNS, DYN, DNSMadeEasy, NS1, UltraDNS, PowerDNS).
I switched to Terraform + CloudFlare for managing my DNS entries and I absolutely love it. No more messing around with web pages, change a line in a file and you're done. Fantastic. Warning: I have made services inaccessible by deploying before making sure the git repo I was working from was the latest version. That's the downside of stateless deployments!
We've all been there!
Re: ACME v2 and Wildcard Certificate Support is Live
#274Earlier quoted context omitted.
I switched to Terraform + CloudFlare for managing my DNS entries and I absolutely love it. No more messing around with web pages, change a line in a file and you're done. Fantastic. Warning: I have made services inaccessible by deploying before making sure the git repo I was working from was the latest version. That's the downside of stateless deployments!
Did you do a deploy before a plan? ;) We've all been there!
Re: ACME v2 and Wildcard Certificate Support is Live
#275Earlier quoted context omitted.
I never understood why DNS providers are so reluctant to offer standards-based access, like nsupdate(1). It's easy to set up, it can do everything, it's secure, requires no custom anything and it just works.
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.
Re: ACME v2 and Wildcard Certificate Support is Live
#276I do hope GitHub employs this for rolling out https for Pages sites using custom domains too.
Re: ACME v2 and Wildcard Certificate Support is Live
#277Earlier quoted context omitted.
The SSL zealotry drives me nuts. The infosec community screams constantly about "HTTPS everywhere", but they either don't know or don't care about all the effort and pain they're creating for developers who just want their software to work. How many perfectly good sites will be marked ominously as "insecure" by Chrome in the next few months? Sites that were working just fine until someone at Big G decided they weren'…
> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. > they either don't know or don't care about all the effort and pain they're creating You have not been paying attention to the hundreds of tools available to make HTTPS painless. > until someone at Big G decided they weren't. And Mozilla. And countle…
Re: ACME v2 and Wildcard Certificate Support is Live
#278Earlier quoted context omitted.
We've been using TXT records to authenticate certificate requests since Let's Encrypt launched. That hasn't changed.
Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…
A cloud provider/datacenter controls the IP space in the majority of cases.
If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security (TLS) where the identity of the applicant has been validated by proving some control over a DNS domain"
If this is something that worries you, then you should only trust sites that have Extended Validation certificates.
Re: ACME v2 and Wildcard Certificate Support is Live
#279Now here's to hoping that Heroku supports this soon. That will to mean I can a last migrate a number of apps that require wildcard domains to their platform.
And Heroku already supports wildcard certs (that you need to provide yourself) if you use the SSL addon.
Re: ACME v2 and Wildcard Certificate Support is Live
#280Now here's to hoping that Heroku supports this soon. That will to mean I can a last migrate a number of apps that require wildcard domains to their platform.
I'm intrigued. What kind of app that you could host on heroku requires wildcard certificates? Bearing in mind that heroku can't really support wildcard subdomains for a single app. Each custom subdomain for an app needs to be added to the app. And then if you enable Automated Certificate Management for the app (which uses LetsEncrypt under the covers), they'll happily fetch a cert for each listed subdomain. And Herok…
Why not?