4 ms·

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... The problem here is

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on certificate authorities. And CAs are always highly centralized and highly centralizing. If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet. There's an easy solution to this though. Don't throw alway plain protocls. Plain and TLS wrapped are synergistic. Use both. There's no need for, and it is damaging, to always encrypt without an option for plain text. A hypothetical downgrade attack is not an excuse for using only highly centralized TLS CA based protocols in this context.

gefhfff 5y ago
Encryption does not imply authentication, does it?
- superkuh 5y ago
  Browsers scaremonger really hard about self-signed SSL certs. And browsers are starting to implement HTTPS only as a default. It won't be too long before HTTP is blocked by mega-corp browsers and not having a CA TLS cert means your website is now un-visitable by non-technical people (and not indexed by search engines).
  - midasuni 5y ago
    The concern about http over https is that a bad actor can intercept and change traffic. If you allow self signed certificates, anyone who can MITM traffic can masquerade your site just like with http Self signed does however stop passive fibre taps - to intercept you need to MITM. There then the “remember this cert” option. If I visit www.selfsigned.com on a secure network, my browser remembers the certificate. If I then travel to another network with a MITM, my browser can flag up a warning. This is how SSH works. However I’m not too concerned by SSL certificates as a centralised point - my browser trusts dozens, probably more than 100, root certificates. That’s not centralisation.
    - mistrial9 5y ago
      this seems to be a well-known list of trusted Certificate Authorities https://ccadb-public.secure.force.com/mozilla/CAInformationReport https://ccadb-public.secure.force.com/mozilla/CAInformationR...
    - immibis 5y ago
      Self-signed certs should be no scarier than unencrypted connections. If self-signed certs are allowed then you can have a case for banning unencrypted connections - the way Mozilla tried to do in the past, but they didn't allow self-signed certs. If we're not going to show interstitial warning pages for HTTP-not-S sites, so you can't see if it's HTTPS without checking the address bar, then a red open padlock and a red strike through the "https" seems sufficient for self-signed HTTPS sites. Some indication is needed, otherwise you'd see the "https" and think it was secure, but the indication shouldn't be scarier than HTTP-not-S!
AnthonyMouse 5y ago
> This is because the current status quo for encryption is to use TLS based on certificate authorities. Not everything has to be TLS or even HTTP. Look at messaging apps. Signal is encrypted, but the end-to-end encryption it uses isn't TLS and doesn't use certificate authorities. > If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet. Not really. Let's Encrypt doesn't have a monopoly over anything. They use an open protocol (ACME) that any other CA could implement. If they went evil, someone else would implement the same protocol and everybody would switch to them. Which also implies that they won't, because why bother if that's what will happen? This is kind of a problem with the CA system the other way -- if you have one bad CA they can sign any domain even if they shouldn't -- but in this case it prevents what you're worried about.
- judge2020 5y ago
  > that any other CA could implement. For reference, many CAs (even paid ones) have implemented it: Digicert https://docs.digicert.com/certificate-tools/Certificate-lifecycle-automation-index/acme-user-guide/ https://docs.digicert.com/certificate-tools/Certificate-life... Sectigo (formerly Comodo) https://sectigo.com/resource-library/sectigo-adds-acme-protocol-support-in-certificate-manager-platform-to-automate-ssl-lifecycle-management https://sectigo.com/resource-library/sectigo-adds-acme-proto...
- judge2020 5y ago
  > if you have one bad CA they can sign any domain even if they shouldn't -- but in this case it prevents what you're worried about. This is why certificate transparency is a thing and most browsers require it for public internet domains[0,1]. 0: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/net/docs/certificate-transparency.md#Chrome-Policies https://chromium.googlesource.com/chromium/src/+/refs/heads/... 1: https://support.apple.com/en-us/HT205280 https://support.apple.com/en-us/HT205280
- immibis 5y ago
  I'm surprised if Signal doesn't use TLS, considering that Android tries to force apps to always use TLS, which is because of the point the parent comment is making.
foxfluff 5y ago
LE also forces you to rely on DNS, which is highly centralized..
- xxpor 5y ago
  What CA doesn't?
  - hackmiester 5y ago
    I don't think it was meant as a criticism, just a statement of the current status quo, which is inherently rooted in the centralized DNS.
  - foxfluff 5y ago
    There are many CAs that give certs for IPs. LE won't. Not that it's much better. IPs are still granted to you by someone in a centralized hierarchy.
- deleted 5y ago
  [deleted]
- midasuni 5y ago
  How is DNS centralised?
  - judge2020 5y ago
    All roads lead to . [0], ie. IANA. Many IANA-approved entities run them[1], but they all only resolve TLDs ICANN authorizes (and those TLD operators control what domains are registered under their TLD, of course). 0: https://dns.google/query?name=.&rr_type=NS&ecs= https://dns.google/query?name=.&rr_type=NS&ecs= 1: https://www.iana.org/domains/root/servers https://www.iana.org/domains/root/servers
  - im3w1l 5y ago
    Well on a technical level there are root servers. But DNS is a hierarchy and so if the root servers ever tried to pull a fast one there are second-in-command authorities that could take over: the cctld orgs. People would rather follow their lead than ICANN, so they have the real power. I'm pretty sure this is by design.

gefhfff 5y ago

Encryption does not imply authentication, does it?

superkuh 5y ago
Browsers scaremonger really hard about self-signed SSL certs. And browsers are starting to implement HTTPS only as a default. It won't be too long before HTTP is blocked by mega-corp browsers and not having a CA TLS cert means your website is now un-visitable by non-technical people (and not indexed by search engines).
- midasuni 5y ago
  The concern about http over https is that a bad actor can intercept and change traffic. If you allow self signed certificates, anyone who can MITM traffic can masquerade your site just like with http Self signed does however stop passive fibre taps - to intercept you need to MITM. There then the “remember this cert” option. If I visit www.selfsigned.com on a secure network, my browser remembers the certificate. If I then travel to another network with a MITM, my browser can flag up a warning. This is how SSH works. However I’m not too concerned by SSL certificates as a centralised point - my browser trusts dozens, probably more than 100, root certificates. That’s not centralisation.
  - mistrial9 5y ago
    this seems to be a well-known list of trusted Certificate Authorities https://ccadb-public.secure.force.com/mozilla/CAInformationReport https://ccadb-public.secure.force.com/mozilla/CAInformationR...
  - immibis 5y ago
    Self-signed certs should be no scarier than unencrypted connections. If self-signed certs are allowed then you can have a case for banning unencrypted connections - the way Mozilla tried to do in the past, but they didn't allow self-signed certs. If we're not going to show interstitial warning pages for HTTP-not-S sites, so you can't see if it's HTTPS without checking the address bar, then a red open padlock and a red strike through the "https" seems sufficient for self-signed HTTPS sites. Some indication is needed, otherwise you'd see the "https" and think it was secure, but the indication shouldn't be scarier than HTTP-not-S!

AnthonyMouse 5y ago

> This is because the current status quo for encryption is to use TLS based on certificate authorities. Not everything has to be TLS or even HTTP. Look at messaging apps. Signal is encrypted, but the end-to-end encryption it uses isn't TLS and doesn't use certificate authorities. > If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet. Not really. Let's Encrypt doesn't have a monopoly over anything. They use an open protocol (ACME) that any other CA could implement. If they went evil, someone else would implement the same protocol and everybody would switch to them. Which also implies that they won't, because why bother if that's what will happen? This is kind of a problem with the CA system the other way -- if you have one bad CA they can sign any domain even if they shouldn't -- but in this case it prevents what you're worried about.

judge2020 5y ago
> that any other CA could implement. For reference, many CAs (even paid ones) have implemented it: Digicert https://docs.digicert.com/certificate-tools/Certificate-lifecycle-automation-index/acme-user-guide/ https://docs.digicert.com/certificate-tools/Certificate-life... Sectigo (formerly Comodo) https://sectigo.com/resource-library/sectigo-adds-acme-protocol-support-in-certificate-manager-platform-to-automate-ssl-lifecycle-management https://sectigo.com/resource-library/sectigo-adds-acme-proto...
judge2020 5y ago
> if you have one bad CA they can sign any domain even if they shouldn't -- but in this case it prevents what you're worried about. This is why certificate transparency is a thing and most browsers require it for public internet domains[0,1]. 0: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/net/docs/certificate-transparency.md#Chrome-Policies https://chromium.googlesource.com/chromium/src/+/refs/heads/... 1: https://support.apple.com/en-us/HT205280 https://support.apple.com/en-us/HT205280
immibis 5y ago
I'm surprised if Signal doesn't use TLS, considering that Android tries to force apps to always use TLS, which is because of the point the parent comment is making.

foxfluff 5y ago

LE also forces you to rely on DNS, which is highly centralized..

xxpor 5y ago
What CA doesn't?
- hackmiester 5y ago
  I don't think it was meant as a criticism, just a statement of the current status quo, which is inherently rooted in the centralized DNS.
- foxfluff 5y ago
  There are many CAs that give certs for IPs. LE won't. Not that it's much better. IPs are still granted to you by someone in a centralized hierarchy.
deleted 5y ago
[deleted]
midasuni 5y ago
How is DNS centralised?
- judge2020 5y ago
  All roads lead to . [0], ie. IANA. Many IANA-approved entities run them[1], but they all only resolve TLDs ICANN authorizes (and those TLD operators control what domains are registered under their TLD, of course). 0: https://dns.google/query?name=.&rr_type=NS&ecs= https://dns.google/query?name=.&rr_type=NS&ecs= 1: https://www.iana.org/domains/root/servers https://www.iana.org/domains/root/servers
- im3w1l 5y ago
  Well on a technical level there are root servers. But DNS is a hierarchy and so if the root servers ever tried to pull a fast one there are second-in-command authorities that could take over: the cctld orgs. People would rather follow their lead than ICANN, so they have the real power. I'm pretty sure this is by design.