Page MenuHomePhabricator

Varnish-triggered CN campaign about browser security
Closed, ResolvedPublic

Description

We'd like to start planning a CentralNotice campaign targeting users of very ancient, insecure browsers, the canonical example being IE-on-XP. The real measure we want to target on isn't the UA so much as the TLS cipher choice, which Varnish is aware of and can regex-filter on. The message in the campaign banner would be some kind of warning to the user that thier connection and/or browser is insecure and/or outdated, and link them to an informative page like https://wikitech.wikimedia.org/wiki/HTTPS:_Browser_Recommendations .

The outstanding questions right now are these:

  1. How can we communicate selectivity for a CN campaign from Varnish to CN, with Varnish making the call on whether the user belongs to the set to show the campaign to? Is there a generic mechanism for CN to trigger on seeing a special Cookie value that Varnish could set, for instance?
  2. Alternatively, could we have CN make the decision for itself based on the client's User-Agent string (navigator.userAgent)? That might be an acceptable alternative as well, if we could construct regular expressions that reliably target only the oldest popular browsers/platforms (e.g. IE-on-XP, Android 2.x, etc). The downside is this wouldn't catch some edge cases we know of where e.g. a modern User-Agent gets downgraded cryptographic negotiation due to a poorly-configured corporate TLS proxy, but it would still be better than nothing.
  3. Are these older UAs (IE[78]/XP? Android 2.x?) even capable of displaying CN notices, or does the CN JS face some compatibility issues there? Related: does CN work on mobile, and for these older edge cases?

Event Timeline

CentralNotice is reliant on JavaScript, and doesn't work on browsers where MediaWiki only offers "Basic" support. That includes IE8 or below, and old versions of Android (I'm not sure where the cutoff is exactly)

Ah, that probably puts a fork in this for notifying truly-outdated clients this way, then. The only case we could capture with CN would be the "good browser + awful downgrade from corporate TLS proxy" case, which would have to be gleaned from Varnish rather than the UA (e.g. by Varnish setting a special Cookie value that CN triggers the campaign on).

FWIW, MediaWiki has a built-in sitenotice (https://www.mediawiki.org/wiki/Manual:Interface/Sitenotice) functionality that is not reliant upon JS. We could add something for that in the WikimediaMessages extension, but the pages with that sitenotice shouldn't be cached by varnish.

FWIW, MediaWiki has a built-in sitenotice (https://www.mediawiki.org/wiki/Manual:Interface/Sitenotice) functionality that is not reliant upon JS. We could add something for that in the WikimediaMessages extension, but the pages with that sitenotice shouldn't be cached by varnish.

That seems like a reasonable method forward. We could go ahead and stop caching said requests soon(ish), along with setting some kind of header or cookie. At the same time add a standard WikimediaMessage that we can get translated. Finally once both are in place, we could hack up something in MW to make that conditionally display based on said header/cookie. It would suffice to hack this onto WMF branches for the $period_of_time, such a kludge doesn't need to hit core.

Well, if varnish doesn't cache those requests couldn't we just UA sniff in MW config and conditionally set the sitenotice based on that?

If we want to go down that kind of road, it would probably be better efficiency-wise to have varnish set simpler request-side headers/flags conditional on the connection security and/or UA, and then use those to both (a) trigger the SiteNotice in MW and (b) Vary the cache (within varnish in vcl_hash()).

I still think for the 3DES case, we're better off with a full page replacement at increasing percentage of pageviews, as discussed in T147199. It's more blaringly-obvious and less likely to be ignored/dismissed. We'd want something like that in the end-game period where we're blocking all real traffic anyways (but still allowing the connection to get far enough to show the message about switching browsers).

For the other cases beyond 3DES, normal CN campaigns are probably doable, I think.

BBlack claimed this task.

Not much left to discuss in this stale ticket. We have the information we need, and were able to proceed on T147199 by using direct Varnish-level page replacements and/or redirects.