Why HTTP without encryption and self-signed sertificates are OK
Encryption is important. It is used to make sure that no-one eavesdrops the
data transmission or injects something like ads or malicious scripts into the
content. However, there still are, and always will be, valid reasons to also
allow the use of HTTP without encryption.
1) There are many different levels of protocols, and HTTP is only one of them.
Modern computer networking is based on something called "protocol stacking".
Basically there are many different protocols acting as a payload to another
protocol. Usually under HTTP there is at least two other protocols, TCP and IP.
When we are encrypting a HTTP connection, we are only adding one more protocol
(TLS) between the HTTP and TCP protocols.
When connecting to the internet required calling the ISP with a modem, it was
possible to encrypt the whole call - that way every protocol in the stack,
including TCP/IP, became encrypted. With a completely encrypted protocol stack
the HTTP protocol doesn't need TLS to prevent man-in-the-middle attacks, if the
server also has (and it probably will have) a trusted connection to the public
internet and the route of the packages between the server and the user's ISP is
known.
Although with modern internet connections it is unusual to have the whole
protocol stack encrypted, some users may still have a completely encrypted
protocol stack. In these cases it is completely acceptable to use unencrypted
HTTP at least for accessing static content.
2) The route of packages is sometimes known to be safe.
Often the route of the packages is also completely known (for example in
intranets), and sometimes in these cases, there is even no routing to the
public internet available, which makes it impossible to update the root
certificates easily. Using TLS in these conditions can be troublesome.
3) Are we encrypting a wrong protocol?
Adding an encryption with a certificate to the protocol stack doesn't
automatically improve security. We have to understand what is the confidential
data that we want to encrypt, and in what level of the protocol stack should
the encryption be so that it prevents any unauthorized people from seeing the
confidential data.
For example, modern instant messaging platforms like Discord, Facebook,
Snapchat etc. encrypt the connection between the client and the server and
therefore falsely advertise themselves as "secure". However there is no
end-to-end encryption, and anyone who has an access to the server can also see
the messages - and this includes not only the administrators of the messaging
platform but also any national intelligence agencies and other often malicious
actors.
The correct way to do it is to encrypt the messages (or whatever payload is
transmitted between the clients) in the sender's client and then decrypt them
in the receiver's client. That way the server cannot see the unencrypted
content. That's also what end-to-end encryption means.
Encrypting a wrong protocol without a proper reason may at best only create
more overhead and consume more bandwidth and CPU time than is needed, but at
worst it may create a false sense of security.
4) Self-signed certificates are normally safe, and malicious sites these days
usually have "trusted" certificates.
There used to be a time when malicious websites usually didn't have encryption
at all, or if they had, their certificate was self-signed. Let's Encrypt
changed that. Now every malicious site has a certificate that appears trusted,
and there will soon be a need of having different levels of "trust", where
free-of-charge certificates like the ones from Let's Encrypt will become
essentially untrusted.
This is a problem that cannot be solved. Self-signed certificates used to be
considered fine, but now every mainstream browser shows a scary warning before
entering a site with such certificate. The same will happen to the certificates
from Let's Encrypt and then it will again be impossible to get a trusted
certificate for free.
However, there is nothing wrong with self-signed certificates as long as the
browser actually shows the relevant information (the public key etc.) so that
the user can make sure that the other end of the connection really is what it
claims to be. When used properly, self-signed certificates are actually safer
than certificates from Let's Encrypt. Showing the user nonsensical warnings like
"Someone is trying to steal your credit card information!!!!11" only creates
confusion and misconceptions about security.
Phishing websites also did not have lookalike domains before unicode characters
were allowed in domain names. That itself is much more dangerous problem than
having no encryption, because it is harder to notice.
5) Allow using the site with retro hardware.
People are using the internet with old hardware for variety of reasons. Some do
it for fun, and some do it because they cannot afford a newer, more modern
device. Continually imposing new technical requirements for accessing the site
may be discriminating against these people.
Sometimes the server itself can also be archaic hardware (for example a
Commodore 64 or a 486 PC) for reasons. The server and/or the client computer
can also sometimes have a completely homebrew software stack that is not capable
of doing modern encryption.
6) Let the user decide.
By convention the TCP port 80 is used to serve non-encrypted content and the
port 443 is used to serve the content encrypted via TLS. There is no valid
reason to change this. Web browsers, and in many cases also servers, should
respect the user's choice.