Why do you recommend not using HTTPS/TLS filtering?

Frequently Asked Questions about the Pale Moon browser and their answers.
User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35402
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Why do you recommend not using HTTPS/TLS filtering?

Unread post by Moonchild » 2016-12-08, 10:46

Why do you recommend not using HTTPS/TLS filtering?

Plainly put: because it is very bad for your security.

Some antivirus software suites offer this as a "feature" which regularly also includes having to install a global wildcard certificate (one certificate for every domain in the world), so they can perform man-in-the-middle inspection and filtering of encrypted traffic. This is a very, very, very bad idea.
It will break end-to-end encryption and makes it impossible for the client (your browser) to verify that its connection is authenticated or using acceptable levels of encryption. Enabling this actually opens you up to MitM attacks on the 'net!

To demonstrate by example:

Normally, your browser (A) makes a direct, secure, encrypted connection to the server (B):

A ======== B

With the HTTPS-filtering kind of internet security (IS) setup "checking' your HTTPS traffic, they become a man in the middle (because encrypted traffic can't be inspected):

A ======== IS ======== B

The browser in this situation can only see the secure connection to IS, and not beyond that. Usually, trust for this IS is enforced by installing a wildcard certificate that is valid for all hosts. So, it enforces the browser to think A ====== B is always considered completely secure by the browser (and therefore you) even if it isn't, because it's factually A ====== IS.

The problem with this is that you don't have any information about the second part of the connection. There is no information about IS ======== B being secure, of it even being encrypted to begin with, or even knowing if you are actually connected to the correct server.

For example, if there is a MitM attack on the internet (AT) for server B with an untrusted certificate, normally the browser would immediately know it's an untrusted connection and alert you. If the attacker has completely taken over the connection (server hijacking) or redirecting traffic to their own server, there won't be a trust chain either:

A ---------- AT ========= B (MitM)
A ======== AT (hijack)
A doesn't see the expected trusted connection to B, but sees an untrusted connection to AT. This means the browser (and therefore the user) is aware of the attack because it's presented in the browser as insecure or the wrong domain/owner/party.

If you have an IS in place that intercepts your traffic to filter it:

A ======== IS -------- AT ======== B
A ======== IS ======== AT
A sees the trusted connection to IS and doesn't alert you (it looks exactly the same to the browser as a legitimate secure connection to B).

Even something as simple as a downgrade attack making the server connection weaker than the browser would normally accept, and your traffic being intercepted and snooped upon as a result, will go unnoticed:

Code: Select all

A ======== IS ******** B
                ^-------- AT
Last edited by Moonchild on 2018-04-17, 12:34, edited 1 time in total.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked