How TEA Project’s Use of HTTP in Web3 is More Secure than HTTPS in Web 2.0

Anyone browsing the internet is probably aware of the green HTTPS padlock in their browser’s URL bar. They understand that any web server running on HTTPS is considered secure, while any server running HTTP is considered not secure. But when it comes to Web3 and decentralized apps, HTTPS security concepts can be misleading and even irrelevant.

Clicking on an HTTP (no “S”) TEA Project IPFS link returns a feed of the binary app coming straight from IPFS. When you click on a TEA Project delegator link, you’re essentially asking the IPFS service to download the HTML / JS / CSS code to run in your browser. The whole process has nothing to do with any web server as the decentralized TEA Project app (TApp) runs directly in your own browser.

But when you click on a delegator node to run a TApp, your browser may give you a “Not Secure” warning:

But taking a closer look at HTTPS in relation to Web3 will reveal how these security warnings are quite misleading in the decentralized ecosystem of Web3 that the TEA Project is part of.

1. An SSL Cert Introduces a Central Authority

The HTTPS security lock denotes that your browser and the server it’s interacting with shares a certificate key. The SSL certificate ensures that all communication between the server and the browser is encrypted. This security protects against man-in-the-middle attacks.

The TEA Project’s aim is to run apps decentralized. We use HTTP for the purpose of remaining fully decentralized. The first issue with HTTPS is that these ssl certificates are issued by centralized certificate authorities that browsers like Google Chrome and Mozilla Firefox choose to recognize. Some of the largest central certificate authorities include:

- Comodo SSL
- RapidSSL
- Thawte SSL
- Sectigo SSL
- GeoTrust SSL
- Digicert SSL

Adding an SSL to your tech stack introduces an element of centralization to your app. In addition, the web 2.0 concept of “trustable” doesn’t really translate to IPFS where anyone who wants to be a miner can run a node.

2. A Centralized Authority SSL Cert Isn’t Necessary if Everything’s Already Encrypted

The second issue is that the secure connection that HTTPS provides isn’t necessary for the TEA Project. TApps send the result of their calculations encrypted to the end user’s browser. In the world of HTTPS, communication is protected between the browser and the server. In the TEA Project, communication is protected between the browser and the protected enclave of the TEA mining node. Even if someone were able to intercept the transmission, they wouldn’t be able to crack the encryption. The TApp’s output isn’t revealed until it’s decrypted on the end user’s browser. The TEA Project only sends publicly accessible data via plain text between nodes and client wallets. Any dynamic content that requires secure transfer is encrypted between the enclave and the browser.

There’s an important difference between how HTTPS interacts with the currently predominant internet and how the TEA Project uses HTTP over Web3. The HTTPS protocol in the web 2.0 world only protects transmissions between the server node and the browser. The TEA Project is able to use HTTP because the secure layer goes beyond the transmission line deep into the server iteslf. The encryption extends from the hardware protected enclave in the server all the way to the browser. That’s why we imagine that the server is already compromised, in which case using the TEA Project’s architecture would keep everything secure. A compromised server is a scenario that HTTPS can’t protect against.

3. SSL is Secure. But Data Moving Through It Could Be Hacked Data

The third issue is that https secures the pipe, but it doesn’t secure the server sending information through that pipe. HTTPS doesn’t prevent a website from getting hacked or pushing it offline through a DDoS attack. HTTPS will do deliver the sent information securely, whether that information is real or hacked. Just like a Subaru is a safe car to whoever rides inside, criminal or not, the HTTPS protocol is indifferent to how trustable the dat is flowing through its secure channel.

4. Best Security OPs = Assume the Server is Already Compromised

The fourth issue is the difference between encryption in transit vs. encryption at rest. Many large corporations will make sure that their data is encrypted in transit, but will decrypt it and let it sit in a database somewhere unencrypted. Large corporations are often lacking in cybersecurity protocols, and leaving customer databases unencrypted further whets the appetite of hackers to break in. The TEA Project already assumes a web server is compromised and moves onto the next level to ensure everything is secure even if a hacker has infiltrated the server.

The TEA Project doesn’t trust the hardware server. The only hardware we trust is the TPM chip inside, specifically the protected enclave that the TPM chip governs. Any information is decrypted only when it enters this protected enclave, and encrypted again when it leaves the enclave.

It’s unfortunate that HTTPS lulls consumers into a false sense of security. They might be interacting with a website that shows the green padlock in the browser’s omnibar but they still might be unwittingly dealing with a compromised server. We at the TEA Project assume that the server you are connecting to is compromised even though you can still see it’s using HTTPS. That’s why we say HTTPS is not fully decentralized and that we don’t rely on the “S” of HTTPS to get security.