3 ms·

New baseline expectation that web traffic will be encrypted on the wire: very good! New de-facto requirement that you need to receive the blessing of a CA to m

New baseline expectation that web traffic will be encrypted on the wire: very good! New de-facto requirement that you need to receive the blessing of a CA to make use of basic web platform features... not so good.

jovial_cavalier 10mo ago
That's not new, LetsEncrypt just didn't solve it. And if you think this is the only single point of failure in the stack, I have news for you.
- greyface- 10mo ago
  It's absolutely new. No HTML5 features were restricted to secure origins only pre-LE. Today, many are. Google was able to push these requirements in large part due to Let's Encrypt's success making secure origins ubiquitous.
  - ekr____ 10mo ago
    The order of events is a bit more complicated than this. Google initially proposed restricting powerful features to secure origins back in February of 2015 (https://web.archive.org/web/20150125103531/https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features/ https://web.archive.org/web/20150125103531/https://www.chrom...) and Mozilla proposed requiring secure origins for all new features in April of 2015 (https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ https://blog.mozilla.org/security/2015/04/30/deprecating-non...). Let's Encrypt issued its first certificate in September of 2015. This isn't to say that these two things are unrelated: Mozilla obviously knew about Let's Encrypt and we considered it an important complement for this kind of policy, and at least some people at Chrome knew about LE, though I'm not sure how it played into their thinking. However, it's not as simple as "LE happened and then people started pushing for secure origins for new features".
    - bruce511 10mo ago
      I'd also argue, very necessary. A lot of thd new APIs have to do with accessing hardware. Camera, Microphone, Serial ports (currently experimental) etc. Given how easy a MITM attack to injection JavaScript or HTML into insecure pages is, a world where insecure pages had access to hardware makes that hardware very vulnerable. Even though all you'd be doing is reading some random blog etc. To those who still think serving HTTP is some sort of principled stand, just be aware that injecting malware onto your page at delivery time is pretty trivial. Quite honestly, and I mean this in a constructive way, it doesn't signal "principles" it signals "incompetence".
ekr____ 10mo ago
Can you elaborate a bit about what you mean by "the blessing of a CA"? I agree that it's true that you need a certificate to do TLS, but importantly Let's Encrypt isn't interested in what you do with your certificate, just that you actually control the domain name. See: https://letsencrypt.org/2015/10/29/phishing-and-malware.html https://letsencrypt.org/2015/10/29/phishing-and-malware.html
- greyface- 10mo ago
  Their policy today is to grant certificates liberally. There is no technical guarantee that this remains the case indefinitely, only a political one. I don't doubt the sincerity of this guarantee, but I wish I didn't have to rely on it.
  - ekr____ 10mo ago
    I agree that technical guarantees are better than policy guarantees.
  - crote 10mo ago
    A big factor is that they are serving so many certs, with only a tiny amount of funding. Anything beyond the most basic pre-written list of blocked domain names is infeasible. Analyzing the content of every single domain would increase their resource needs by several orders of magnitude. That's reasonably close to a technical guarantee, if you ask me.
    - KronisLV 10mo ago
      > That's reasonably close to a technical guarantee, if you ask me. Until the feds show up like: Okay, either you block these domains, or you're going to jail: politician-x-did-something-bad.com politician-y-is-corrupt.com country-z-did-crimes-against-humanity.com political-opposition-party-w-homepage.com blog-that-mentions-any-of-the-above.com ... (rest of the list that works for 10 or 100'000 domains) I complained about the centralization that reminds me of Cloudflare in another place, but in general the more distributed this sort of infra is, the better. Both for technical reasons, as well as political ones. In general, one can plan around potential risks like "Okay, what if I assume that this infra of mine is actually running in Russia and the govt hates me and I need to migrate." VPSes and domains are pretty easy to move across country borders (e.g. moving from NameCheap to INWX and from something like AWS to Hetzner, at least for simple setups), less so when you don't control the CA.
unethical_ban 10mo ago
Kinda hear you, but DNS is a defacto requirement as well. Neither DNS (common TLDs) nor any of the major cert vendors I'm aware of ask you your site's business before issuing.
- charcircuit 10mo ago
  >ask you your site's business before issuing. Because they want your money. If they ask you after they get to keep your money.

jovial_cavalier 10mo ago

That's not new, LetsEncrypt just didn't solve it. And if you think this is the only single point of failure in the stack, I have news for you.

greyface- 10mo ago
It's absolutely new. No HTML5 features were restricted to secure origins only pre-LE. Today, many are. Google was able to push these requirements in large part due to Let's Encrypt's success making secure origins ubiquitous.
- ekr____ 10mo ago
  The order of events is a bit more complicated than this. Google initially proposed restricting powerful features to secure origins back in February of 2015 (https://web.archive.org/web/20150125103531/https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features/ https://web.archive.org/web/20150125103531/https://www.chrom...) and Mozilla proposed requiring secure origins for all new features in April of 2015 (https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ https://blog.mozilla.org/security/2015/04/30/deprecating-non...). Let's Encrypt issued its first certificate in September of 2015. This isn't to say that these two things are unrelated: Mozilla obviously knew about Let's Encrypt and we considered it an important complement for this kind of policy, and at least some people at Chrome knew about LE, though I'm not sure how it played into their thinking. However, it's not as simple as "LE happened and then people started pushing for secure origins for new features".
  - bruce511 10mo ago
    I'd also argue, very necessary. A lot of thd new APIs have to do with accessing hardware. Camera, Microphone, Serial ports (currently experimental) etc. Given how easy a MITM attack to injection JavaScript or HTML into insecure pages is, a world where insecure pages had access to hardware makes that hardware very vulnerable. Even though all you'd be doing is reading some random blog etc. To those who still think serving HTTP is some sort of principled stand, just be aware that injecting malware onto your page at delivery time is pretty trivial. Quite honestly, and I mean this in a constructive way, it doesn't signal "principles" it signals "incompetence".

ekr____ 10mo ago

Can you elaborate a bit about what you mean by "the blessing of a CA"? I agree that it's true that you need a certificate to do TLS, but importantly Let's Encrypt isn't interested in what you do with your certificate, just that you actually control the domain name. See: https://letsencrypt.org/2015/10/29/phishing-and-malware.html https://letsencrypt.org/2015/10/29/phishing-and-malware.html

greyface- 10mo ago
Their policy today is to grant certificates liberally. There is no technical guarantee that this remains the case indefinitely, only a political one. I don't doubt the sincerity of this guarantee, but I wish I didn't have to rely on it.
- ekr____ 10mo ago
  I agree that technical guarantees are better than policy guarantees.
- crote 10mo ago
  A big factor is that they are serving so many certs, with only a tiny amount of funding. Anything beyond the most basic pre-written list of blocked domain names is infeasible. Analyzing the content of every single domain would increase their resource needs by several orders of magnitude. That's reasonably close to a technical guarantee, if you ask me.
  - KronisLV 10mo ago
    > That's reasonably close to a technical guarantee, if you ask me. Until the feds show up like: Okay, either you block these domains, or you're going to jail: politician-x-did-something-bad.com politician-y-is-corrupt.com country-z-did-crimes-against-humanity.com political-opposition-party-w-homepage.com blog-that-mentions-any-of-the-above.com ... (rest of the list that works for 10 or 100'000 domains) I complained about the centralization that reminds me of Cloudflare in another place, but in general the more distributed this sort of infra is, the better. Both for technical reasons, as well as political ones. In general, one can plan around potential risks like "Okay, what if I assume that this infra of mine is actually running in Russia and the govt hates me and I need to migrate." VPSes and domains are pretty easy to move across country borders (e.g. moving from NameCheap to INWX and from something like AWS to Hetzner, at least for simple setups), less so when you don't control the CA.

unethical_ban 10mo ago

Kinda hear you, but DNS is a defacto requirement as well. Neither DNS (common TLDs) nor any of the major cert vendors I'm aware of ask you your site's business before issuing.

charcircuit 10mo ago
>ask you your site's business before issuing. Because they want your money. If they ask you after they get to keep your money.