[feature suggestion] notification for whitelisted item that whitelisting is no longer necessary

[ghost]

over time whitelisted items may move to other (non-proxied) hosts, and albeit rather unlikely but nonetheless possible those MitM hosts may develop a less intrusive behaviour (e.g. with the implementation of TLS 1.3), it could make sense that such whitelisted items to be removed from the whitelist. Thus perhaps a notification, maybe combined with an action (to remove from whitelist) button, to the user that whitelisting is no longer necessary.

[ghost]

Generally I am not much looking at the console and thus from that perpective I would opt for one. Not sure whether it would make sense to somehow (other than the console) to notify the user that a deletion is about to take place or took place.

[nym-zone]

Concept NACK. It’s best to keep things simple—in terms of code, and especially not to multiply options. And if a site moves away from Cloudflare, what harm does it do to leave it whitelisted? It may move back. Or the user may wish to have a handy list of sites they value sufficiently to whitelist, which are or were Cloudflared.

Also, if the user has persistent (not too loud) visual indication such as from #11 that a site is whitelisted/Cloudflared, then they can notice when that indication goes away. If they care to. Or they can simply leave the site whitelisted.

[ghost]

I thought the concept of the extention is about actual MitM and not were. Thus the suggestion to remove. As stated initially the user's memory of what actually been whitelisted may fade over time and thus not compare the visual indication since the whitelisting been made.

But then this is your development.

[nym-zone]

I had intended to address this in my prior response, but forgot:

@n8v8R:

over time whitelisted items may move to other (non-proxied) hosts, and albeit rather unlikely but nonetheless possible those MitM hosts may develop a less intrusive behaviour (e.g. with the implementation of TLS 1.3),

TLS 1.3 has nothing to do with it. It is a significant improvement over TLS 1.2; however, due to Cloudflare’s design, it does not matter what version of TLS is being used.

Cloudflare has been rolling out prerelase TLS 1.3 for something like a year already (I forget exactly when). They love to brag about their secure TLS, which indeed provides a highly secure connection from you to Cloudflare.

[ghost]

@whatsusername

v1.0.9(and above) fixed this by adding new option

lovely, perfect

[ghost]

@nym-zone

About TLS 1.3 and session key I would have thought that this would take of the issue

Secrecy of the session keys. The shared session keys should be known only to the communicating parties and not to the attacker (See [CK01]; defn 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client.

[ghost]

@whatsusername

There seems to be catch of sorts with wildcard whitelisted domains

whitlisted .mozilla.org

Then go to bugzilla.mozilla.org and being presented with Good news screen, clicking on Got it cycles back to the Good news screen

[ghost]

will do something about this in v1.0.9.3

working fine, except it removes the entire wildcard whitelisted domain.

whitlisted domain (with wildcard) .mozilla.org

Then went to bugzilla.mozilla.org and being presented with Good news screen, clicking on Got it removed then .mozilla.org from the whitelist. Could there be a logic to determine whether a subdomain of a whitelisted domain is not prone to MitM?

[ghost]

@whatsusername

TLS1.3, TLS1.4, it doesn't matter at all.

I get your point, but TLS 1.3 is designed to mitigate MitM and to curtail the MitM ability drastically, including the above mentioned secrecy of session keys and the ability to detect forced fallback attacks to 1.2.

If not mistaken TLS 1.3 was supposed to be released in its final specifications about a year ago. One of the reasons it has not yet is that TLS 1.3 prevents Anti-Virus apps of scanning encrypted traffic by acting as MitM (adding their own proxy certificate to the OS/browser/mail store). But at least those AV apps make the user aware during installation and the user has a choice of whether to accept or not. Similar methodology holds probably true for any firewall with DPI capabilities for encrypted traffic. Win 10 with Family options (parental control) is deploying a TLS certificate proxy in a similar fashion.

Hence with TLS 1.3 CF's snooping capability might get servilely curtailed.

With a TLS 1.3 (certificate) belonging solely to the domain, not those SAN certificates deployed/offered by CF, it should be safer than TLS 1.2, imho.

Seems that CF is well aware of the matter considering their statement

Do I need to support TLS 1.3 on my servers to use this feature?

No. CloudFlare terminates client TLS 1.3 connections at our edge, and does not require you to support
TLS 1.3 on your servers. Furthermore, we do not currently support TLS 1.3 from our edge to origins or
plan to support this in the immediate future, so the only reason to enable TLS 1.3 on your servers is if you
wish to do so for your own purposes.

Which makes it clear, if the domain owner do not care about MitM nobody else will.

[ghost]

Now it is getting perhaps confusing the issue. The aim was to remove whitelisted items not to add something !foo.com. Not sure what the meaning of ! is.

Perhaps leave it as it was in 1.0.9.3 in I will whitelist only mozilla.org and not wildcard .mozilla.org