How did this make the frontage and why? Why HTTP without encryption and self-signed sertificates are OK

For anybody, who doesn't want to visit the page:

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.

That works only if you 100% trust your environment, which is not the case anymore. Currently Zero Trust architecture is the closest one to be as safe as possible on the internet, and it forces encryption on everything, even in LAN/intranet.

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.

There is no "wrong protocol" there is "who do you trust:

• use end-to-end if you don't trust anybody
• use TLS/VPN if you don't trust ISP and BGP, but you trust the server (most common case)

Worrying about CPU time in 2022?

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.

Just remember all certificate fingerprints and validate them yourself. How hard can it be?

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.

Users are lazy, stupid, or both. They don't want to think what to do, they just want to watch pictures of cats or buy concert tickets.