Why is much harder to encrypt emails, compared to web pages?

You need to differentiate between data encryption in transit and encryption of data at rest.

We are all used to reading web pages protected by HTTPS.

When you submit a form on a website the data is indeed encrypted using TLS while it is sent to the server. But that doesn't mean that the data is protected once it reached the server. As far as we know, the website could even decide to save the data in a publicly accessible text file.

Mails do also use encryption for data in transit most of the time using TLS. But that doesn't mean the mail is protected on the mailserver itself.

E2ee would require the sender and receiver to manage encryption keys, this is too complex. Especially if you are mailing multiple people or are mailing people using other mail services.

Note that a lot of enterprise packages like Microsoft Office 365 do support e2ee for enterprises, only internal mails are encrypted though. For internal mails it is possible because the certificates can be managed centralized by the enterprise using it.

TLS is used for e-mails. It's common to encrypt e-mails in transit with the SMTPS protocol (SMTP on top of TLS) or opportunistic TLS with the STARTTLS command.

If you're instead talking about end-to-end encryption between sender and receiver, then you can use S/MIME which uses the same trust model and certificate format as TLS. The sender just has to get a certificate of the receiver (e.g., through an address book, a previous e-mail or any other channel) and check that the certificate has been signed by a trusted certificate authority (CA). Then they can encrypt the e-mail based on the public key within the certificate.

Of course the receiver has to obtain a signed S/MIME certificate from a CA, which may or may not be difficult. Some companies, research institutes and universities issue certificates for all employees, in which case there's no effort for the individual person. But in a private context, it's of course entirely up to you to contact a CA and go through their authentication procedure.

Viewing a web page involves a relatively direct, two-way interaction between a computer operated by the publisher of the page (or their chosen representative) and a computer operated by the viewer. In this interaction the two machines can exchange information to negotiate, set up and verify a temporary encryption system. Each side can check what sort of encryption technology the other side supports, to either find something mutually acceptable, or alternatively declare the communication impossible.

Only one of the parties (the publisher) needs to have a secret key set up advance. At the start of the interaction the publisher's machine will share some information related to that secret (a certificate) with the viewers machine, and the viewer can check that, then make their own temporary secret and share information about that with the publisher.

Email does not involve a direct interaction in the same way. It's designed so that the two parties do not have to be online at the same time, and the message can be handled by intermediaries, potentially being delivered a few days after it was sent. This makes it a lot harder to exchange the necessary information to set and verify a secure channel, and a lot harder to give useful feedback to the user(s) in case something goes wrong.

To be clear, you easily can use the same cryptographic technology to encrypt emails and there exist standards and tools for doing this (PGP). But, it's not widely used. Why? Let's see how HTTPS works, very simplified:

• The owner of example.com has registered their public key in a trusted public database (Certificate Authority)
• The reader's browser looks up the public encryption key of example.com in the public database.
• The reader's browser uses this public key to send an encrypted message that only example.com can decrypt. (This message can contain another encryption key that allows arbitrary further encrypted communication.)

So this process relies on public key infrastructure (PKI) where you have a trustworthy way to look up the public key. You could use the same infrastructure for encrypting mail to gmail.com, but you want to send mail to [email protected] that only Alice can decrypt (not Google). That means you need to solve two annoying problems.

1. You need a trustworthy database to look up Alice's specific public key. You really need a whole PKI that average email users like Alice have to deal with, like publishing their public keys.
2. Alice has to manage her private encryption key, i.e. keep it safe, use it across any devices she wants to use email on, transfer it when one device dies and she gets a new one, etc.

My personal opinion is that if Google and Microsoft wanted to make end-to-end encrypted email easy to use and widespread, they could address these challenges to a large extent. But those companies don't benefit by not being able to read their users' email, and they don't want to deal with hassles like users getting locked out of their own email accounts, so they don't.

Your assumption is wrong.

Your e-mails actually are encrypted the same way that web pages are. It's just that there are two hops, not one.

Due to the asynchronous nature of e-mail, it gets delivered first from the sender to an e-mail server(1). This connection is commonly encrypted, with TLS just like your web browser does it.

Then, when you read your mails, your client connects to the server to download the mail, and again this connection is typically encrypted.

What might confuse you is that for e-mail there is also another way to encrypt them, such as PGP or S/MIME. These are end-to-end encryption schemes, and because they are not using a live connection, there is no key negotiation, so you need to exchange keys beforehand or use a PKI to fetch them.

(that's all somewhat simplified, but should cover the main things)

(1) actually often to the sender's e-mail server but again, I'm simplifying things a bit.

For a website, the sender knows the unencrypted data, and encryption can be set up spontaneously when I request the website from the server.

For an email from arbitrary A to arbitrary B you don’t want the server to be able to read the email. And A and B cannot communicate because all that A has is Bs email address; it cannot find Bs computer (and there may be more than one), and the computers are often not turned on and connected to the internet at the same time. So lots of things that https can take for granted are not there for email.