Not every criticism of TLS is a criticism of encryption per se nor is it a plea for use of plain HTTP or other unencrypted traffic. TLS as implemented on the internet is only one way to do encryption. The use of certificates is not perfect, and arguably has scaling problems, e.g., imagine trying to use client certificates for every internet user
Not every online commentator that comments on TLS is a person who writes software to be used by others by which the person obtains a commercial benefit ("developer")
Some may be computer users that choose software for themselves, read source code (where possible) and even their own write software when they cannot find what they are looking for, so-called "end users"
Obviously the needs of each and their relationship with "TLS" may be different
What follows is not commentary from a "developer"^FN1
The CA system on which TLS relies is fundamentally flawed in several ways. Two that come to mind are
1. It invariably delegates authority to third parties. A third party ultimately decides whether A is allowed to "trust" B. What if A and B already trust each other. TLS does not care. A and B must trust a third party. A third party decides whether A and B can trust each other. This is classic Silicon Valley-style third party intermediation ("middleman") as a "business model". To add insult to injury, third party "Certificate Authorities" (CAs) are themselves self-appointed. If A and B are both end users, they do not get to choose who may become the third party. The third paty CA's have selected themselves. This self-appointment and derivation of "authority" over TLS "trust" from thin air is reminiscent of ICANN 's mysterious "authority" over "the" DNS. As it happens this is the source of fundamental flaw #2
This is not to say that there are never cases where using a third party may be useful. But TLS does not anticipate that there are _ever_ cases where a third party is not needed. It does not recognise the autonomy of A and B to make their own decisions in those situations, for example to function as their own CAs. It effectively (not actually) denies A and B the _option_ of relying on each other instead of a third party. TLS as implemented on the internet effectively (not actually) makes use of third parties _mandatory_ for everyone in every situation
Why would A or B ever want to manage trust themselves
For one, because unfortunately third party-mediated encryption is not always in the best interests of both parties to the transmission. Every sender that a third party CA or leaf "trusts" is not necessarily a sender that the recipient "trusts", e.g., where the sender is an ad server
Similarly every receiver that a third party CA or leaf "trusts" may not be a receiver that the sender "trusts" , e.g., where the receiver is a tracking server or a so-called "tech" company that performs telemetry, data collection and surveillance in order to offer targeted ad services
As a result, corporations for example must terminate TLS and perform "TLS inspection" to monitor TLS traffic in real-time traversing their own networks
2. The "CA system", specifically basic "validation", relies on another third party middleman, ICANN. Specifically, it relies on ICANN DNS. As above, like Silicon Valley's CAs, ICANN is self-appointed and derives its "authority" over domainnames from thin air. As with CAs, ICANN obtains (large) commercial benefit from operating as a third party intermediary, in this case between end users and domainnames. The idea that contributing to ICANN and registering a domainname through an ICANN-approved domainname registrar creates a level of "trust" that no end user can _ever_ achieve for themselves is laughable
These third party middleman approaches may be popular with developers who themselves aspire to profit from intermediation. But consider that developers do not always understand how stuff works
For example, some developers publishing unsolicited "advice" to others believe DNSSEC encrypts DNS queries
NB. This comment is not about the existence or non-existence of workarounds, e.g., Let's Encrypt, or internet usage patterns, e.g., everyone uses X, no one uses Y, and so on. It is, like the OP, about flaws that exist in TLS
It is also about the fact that TLS as implemented by developers generally makes no allowance for end users who want encrypt transmissions without using third party imtermediaries, e.g., no third party CA-signed certificates, no ICANN DNS domainnames.
In some circumstances, A and B might wish to operate their own CAs only for themselves and use their own DNS nameservers only for themselves, serving their own domainnames from their own root zone files. TLS as implemented actively tries to prevent TLS usage without third parties
Let's Encrypt seems to exist because some agree that use of TLS as implemented on the internet should be free. This comment is based on a similar belief: It should be both free to use (payment optional) _and_ not mediated by third parties unless the parties to the transmission actually want to use them (third parties optional)
FN1. For example, the top comment is a developer perspective. It refers to "excessive advertising" as if to imply some amount of advertising is not "excessive". It points to potential competition between developers over inserting advertising into web pages as a justification for use of TLS, e.g., competition between ISPs versus so-called "tech" companies should be resolved in favour of the so-called "tech" companies. But it fails to account for end user perspectives, e.g., zero tolerance for advertising from any third party, be it ISP, so-called "tech" company or anyone else, including TLS-protected data collection, telemetry and surveillance by these third parties
Not every online commentator that comments on TLS is a person who writes software to be used by others by which the person obtains a commercial benefit ("developer")
Some may be computer users that choose software for themselves, read source code (where possible) and even their own write software when they cannot find what they are looking for, so-called "end users"
Obviously the needs of each and their relationship with "TLS" may be different
What follows is not commentary from a "developer"^FN1
The CA system on which TLS relies is fundamentally flawed in several ways. Two that come to mind are
1. It invariably delegates authority to third parties. A third party ultimately decides whether A is allowed to "trust" B. What if A and B already trust each other. TLS does not care. A and B must trust a third party. A third party decides whether A and B can trust each other. This is classic Silicon Valley-style third party intermediation ("middleman") as a "business model". To add insult to injury, third party "Certificate Authorities" (CAs) are themselves self-appointed. If A and B are both end users, they do not get to choose who may become the third party. The third paty CA's have selected themselves. This self-appointment and derivation of "authority" over TLS "trust" from thin air is reminiscent of ICANN 's mysterious "authority" over "the" DNS. As it happens this is the source of fundamental flaw #2
This is not to say that there are never cases where using a third party may be useful. But TLS does not anticipate that there are _ever_ cases where a third party is not needed. It does not recognise the autonomy of A and B to make their own decisions in those situations, for example to function as their own CAs. It effectively (not actually) denies A and B the _option_ of relying on each other instead of a third party. TLS as implemented on the internet effectively (not actually) makes use of third parties _mandatory_ for everyone in every situation
Why would A or B ever want to manage trust themselves
For one, because unfortunately third party-mediated encryption is not always in the best interests of both parties to the transmission. Every sender that a third party CA or leaf "trusts" is not necessarily a sender that the recipient "trusts", e.g., where the sender is an ad server
Similarly every receiver that a third party CA or leaf "trusts" may not be a receiver that the sender "trusts" , e.g., where the receiver is a tracking server or a so-called "tech" company that performs telemetry, data collection and surveillance in order to offer targeted ad services
As a result, corporations for example must terminate TLS and perform "TLS inspection" to monitor TLS traffic in real-time traversing their own networks
2. The "CA system", specifically basic "validation", relies on another third party middleman, ICANN. Specifically, it relies on ICANN DNS. As above, like Silicon Valley's CAs, ICANN is self-appointed and derives its "authority" over domainnames from thin air. As with CAs, ICANN obtains (large) commercial benefit from operating as a third party intermediary, in this case between end users and domainnames. The idea that contributing to ICANN and registering a domainname through an ICANN-approved domainname registrar creates a level of "trust" that no end user can _ever_ achieve for themselves is laughable
For example
https://www.csoonline.com/article/3516343/tls-security-subve...
These third party middleman approaches may be popular with developers who themselves aspire to profit from intermediation. But consider that developers do not always understand how stuff works
For example, some developers publishing unsolicited "advice" to others believe DNSSEC encrypts DNS queries
https://www.xda-developers.com/reasons-host-your-own-dns-ser...
NB. This comment is not about the existence or non-existence of workarounds, e.g., Let's Encrypt, or internet usage patterns, e.g., everyone uses X, no one uses Y, and so on. It is, like the OP, about flaws that exist in TLS
It is also about the fact that TLS as implemented by developers generally makes no allowance for end users who want encrypt transmissions without using third party imtermediaries, e.g., no third party CA-signed certificates, no ICANN DNS domainnames.
In some circumstances, A and B might wish to operate their own CAs only for themselves and use their own DNS nameservers only for themselves, serving their own domainnames from their own root zone files. TLS as implemented actively tries to prevent TLS usage without third parties
Let's Encrypt seems to exist because some agree that use of TLS as implemented on the internet should be free. This comment is based on a similar belief: It should be both free to use (payment optional) _and_ not mediated by third parties unless the parties to the transmission actually want to use them (third parties optional)
FN1. For example, the top comment is a developer perspective. It refers to "excessive advertising" as if to imply some amount of advertising is not "excessive". It points to potential competition between developers over inserting advertising into web pages as a justification for use of TLS, e.g., competition between ISPs versus so-called "tech" companies should be resolved in favour of the so-called "tech" companies. But it fails to account for end user perspectives, e.g., zero tolerance for advertising from any third party, be it ISP, so-called "tech" company or anyone else, including TLS-protected data collection, telemetry and surveillance by these third parties