End-to-end encryption is more secure than HTTPS

What is HTTPS/TLS?

If your browser loads web pages over HTTPS, a beautiful lock đź”’ appears in the address bar.

Your browser suggests 'Not Secure' if the page loaded over HTTP.

Without HTTPS/TLS, we cannot buy things on the Internet.

Read introductions on Wikipedia if you like:

That is:

HTTPS = HTTP + TLS

In one word: Others do not know the web content you surf over HTTPS.

NOTE: Do not misunderstand. Websites still know what you navigate. It is the bad guys who cannot know it by hacking wireless routers or other ISP devices.

How does HTTPS/TLS work？

The latest TLS 1.3 works like this:

sequenceDiagram

            participant Browser
            participant Server

            note over Browser: generate Elliptic Curve key pair
            Browser ->> Server: Client Hello + public key
            note over Server: generate Elliptic Curve key pair
            note over Server: calculate shared key
            Server ->> Browser: Server Hello + public key + Certificate
            note over Browser: verify Server certificate
            note over Browser: calculate shared key

            rect rgba(200, 200, 200, 1)
            note right of Browser: encrypted communication
            Browser ->> Server: HTTP Request
            Server ->> Browser: HTTP Response
            end

There are 2 most important mechanisms to ensure security in the protocol.

  1. Key agreement

    A browser and a server can establish a shared secret over insecure channels by using ECDH algorithm, elliptic curve(ECC) Diffie–Hellman key exchange. The shared secret can encrypt messages and cannot be hacked by third parties.

  2. Server authentication

    When a user login Google, how does the browser know the other side is Google? You know, "On the Internet, nobody know you're a dog."

    TLS certificate chain comes to help. It uses Digital Signature algorithm to verify the server certificate. Browsers receive a certificate from Google servers when establishing TLS connection. The certificate is signed by a Certificate Authority, and the Certificate Authority is signed by a root CA which is trusted by the Operating System.

    In plain language: the system knows GlobalSign, a root CA, GlobalSign knows GTS CA, and GTS CA knows Google. So browsers trust the Google server.

However, there are hundreds of Certificate Authorities and they can sign certificates for anyone, literally. It is very very hard, if not impossible to ensure all of them are totally reliable.

Let me tell you a story. Google applied and got certificates from a famous CA, Symantec. One day, Symantec made more Google certificates, but did not tell Google. Those certificates could be abused to steal users' Google passwords.

You think it's just a story? It is a real security incident. Check this out Google Bans Symantec’s SSL Certificates.

TLS Status

There have been 6 versions of TLS since 1995(SSL 1.0 was not officially deployed).

SSL Labs

TLS 1.2 is the most widely used version, though it was defined in 2008. Many algorithms supported by TLS 1.2 are no longer secure today.

End-to-end encryption

Passwords sent to ID Guard Offline extension from mobile app are encrypted with end-to-end encryption technology. That means hackers, or even our own employees, cannot decipher the passwords transported over the network.

Here is end-to-end encryption definition on wikipedia.

End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation.

In a word: service providers cannot view your data encrypted with E2EE.

Why not TLS?

TLS can protect messages sent between clients and servers from being eavesdropped by intermediate devices/services. But cloud services know users' messages.

Hyker Security has some great illustrations in E2EE VS NETWORK SECURITY.

Data is in plain text form in cloud when using hop-by-hop TLS encryption.

Data is in cipher text form in cloud when using E2EE.

E2EE in ID Guard Offline extension

ID Guard Offline enhances E2EE. Check out details in Extension Security Design

Why is E2EE in ID Guard Offline extension more secure than HTTPS/TLS?

  1. Cloud side

    HTTPS/TLS: Hackers or employees might be able to view user data.

    ID Guard Offline: Hackers and employees cannot view user passwords.

  2. Crypto algorithms

    HTTPS/TLS: TLS before version 1.3, can easily be misconfigured to use unsafe crypto algorithms.

    ID Guard Offline: uses the most secure crypto algorithms such as ECC and AES-256-GCM.

  3. Third party dependency

    HTTPS/TLS: The trust mechanism, certificate issued by CA, can be attacked due to third party dependency. As a result, password can be hacked.

    ID Guard Offline: requires manual scan and is not affected by third party security issues.

  4. Private key

    HTTPS/TLS: The private keys are usually stored on hard disk and valid for years. This exposes a large attack surface.

    ID Guard Offline: The private key is non-extractable, transient in runtime memory and valid for 2 minutes only. This exposes a very small attack surface.

More articles about ID Guard Offline extension...