Why do you recommend not using HTTPS/TLS filtering?

Frequently Asked Questions about the Pale Moon browser and their answers.

Moderator: satrow

User avatar
Pale Moon guru
Pale Moon guru
Posts: 21163
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E

Why do you recommend not using HTTPS/TLS filtering?

Postby Moonchild » Thu, 08 Dec 2016, 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 Tue, 17 Apr 2018, 12:34, edited 1 time in total.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"The wisest men follow their own direction." - Euripedes

Return to “Frequently Asked Questions (F.A.Q.)”

Who is online

Users browsing this forum: wicknix and 2 guests