Provide SSL/HTTPS interface to upload.wikimedia.org and use it for SSL-served pages
Closed, ResolvedPublic

Description

Currently we pull images (and CentralNotice JS) from http://upload.wikimedia.org even for pages accessed over SSL on https://secure.wikimedia.org/

This has a few problems:

  1. An attacker on an open network or MITM can see which images you're loading. Creepy!
  1. A MITM attacker could replace your images with something malicious/nasty (moderately annoying)
  1. A MITM attacker could replace JS files with something malicious (JavaScript injection -> could take over your session)

We didn't pay too much attention to the image issues originally since existing browsers don't seem to care much about images being loaded from an insecure URL; but Firefox 3.1b2 now complains about this and considers your page to be "mixed" secure/insecure, throwing up a dialog box (at least the first time) and giving you a broken lock icon which indicates an insecure page view, which is worrying.

Ideally we could provide an HTTPS proxy on https://upload.wikimedia.org for maximum convenience; alternately a proxy via https://secure.wikimedia.org/upload or such might be easier to set up in the short term.

The CentralNotice JS issue, which affects existing browsers and is more worrying, could be dealt with by providing an alternate location to access the files or a temporary proxy, or via direct hits to Special:NoticeText.


Version: unspecified
Severity: enhancement
URL: https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page

bzimport added a project: HTTPS.Via ConduitNov 21 2014, 10:25 PM
bzimport set Reference to bz16822.
brion created this task.Via LegacyDec 28 2008, 8:35 PM
brion added a comment.Via ConduitDec 28 2008, 8:55 PM

(Running the CentralNotice JS via Special:NoticeText on SSL for now.)

Merl added a comment.Via ConduitMay 12 2009, 12:31 PM

If you are not able to visit http-urls e.g. because of a proxy, it is very annoying to have no images in articles and no special icons in review or edit modus.

TheDJ added a comment.Via ConduitAug 21 2009, 1:36 PM
  • Bug 20335 has been marked as a duplicate of this bug. ***
Peachey88 added a comment.Via ConduitJul 3 2010, 2:50 AM
  • Bug 24239 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJul 9 2010, 5:21 PM

paxcoder wrote:

I would just like to point out this isn't exactly a duplicate of the above stated bugs. The talk exclusively of images, and not from a standpoint of inconvenience, but of security risk for the user. They aren't as mild as this bug would make it seem.

bzimport added a comment.Via ConduitJul 9 2010, 5:32 PM

paxcoder wrote:

Well... "Creepy", but nobody seems to care.

bzimport added a comment.Via ConduitOct 20 2010, 6:39 AM

pyrates wrote:

I use an addon called https everywhere. It automatically changes you to the secure version of any websites it lists, which includes wikipedia. But on wikipedia, it always warns me about parts of the page being insecure. Found it's because of the images that wikipedia shows and came across this bug.

It is extremely annoying and I don't want to have to disable that warning just so that wikipedia won't bug me about it. I'd rather be warned for when I needed it.

Please put the images website on ssl so that this warning stops popping up.

bzimport added a comment.Via ConduitDec 29 2010, 4:24 PM

brian wrote:

(In reply to comment #0)

Currently we pull images (and CentralNotice JS) from
http://upload.wikimedia.org even for pages accessed over SSL on
https://secure.wikimedia.org/

[snip]

  1. A MITM attacker could replace your images with something malicious/nasty (moderately annoying)

    [snip]

It’s more than “moderately annoying” [0]. You said it yourself: the images could be replaced with something “malicious”. It’s more obvious how this could be a security risk when you consider that images could be used by gadgets or user scripts.

[0] “How to Deploy HTTPS Correctly” https://www.eff.org/pages/how-deploy-https-correctly (“Mixed Content” section)

bzimport added a comment.Via ConduitDec 29 2010, 4:30 PM

brian wrote:

(In reply to comment #7)

I use an addon called https everywhere. It automatically changes you to the
secure version of any websites it lists, which includes wikipedia. But on
wikipedia, it always warns me about parts of the page being insecure. Found
it's because of the images that wikipedia shows and came across this bug.

It is extremely annoying and I don't want to have to disable that warning just
so that wikipedia won't bug me about it. I'd rather be warned for when I
needed it.

Please put the images website on ssl so that this warning stops popping up.

The author is using an add-on called HTTPS Everywhere [0] for Firefox.

Importantly, the warning is coming from Firefox itself, not any add-ons, and would still have appeared had they manually, or by any other method, accessed the secure version of a Wikimedia site.

By the way, someone more familiar with the Wikimedia sites than me should keep an eye on the HTTPS Everywhere ruleset for those sites, to make sure it is as secure as possible (and, in particular, to make sure it is updated when the sites are changed).

[0] https://www.eff.org/https-everywhere

bzimport added a comment.Via ConduitDec 29 2010, 6:52 PM

ayg wrote:

(In reply to comment #8)

It’s more than “moderately annoying” [0]. You said it yourself: the images
could be replaced with something “malicious”. It’s more obvious how this could
be a security risk when you consider that images could be used by gadgets or
user scripts.

The images are cross-origin, so they can do basically nothing different from if they were on some totally different site in a different tab. Gadgets and user scripts cannot (AFAIK) access the contents of upload.wikimedia.org files at all. Pretty much anything an attacker could do by MITMing these images, they could do by MITMing some unrelated site you have open, assuming you have at least one unsecured connection open. So that point is, yes, at most moderately annoying.

The issues of replacing the scripts, and snooping on the images to figure out what pages you're viewing, are the significant ones.

bzimport added a comment.Via ConduitDec 30 2010, 12:27 PM

brian wrote:

(In reply to comment #10)

(In reply to comment #8)
> It’s more than “moderately annoying” [0]. You said it yourself: the images
> could be replaced with something “malicious”. It’s more obvious how this could
> be a security risk when you consider that images could be used by gadgets or
> user scripts.

The images are cross-origin, so they can do basically nothing different from if
they were on some totally different site in a different tab. Gadgets and user
scripts cannot (AFAIK) access the contents of upload.wikimedia.org files at
all. Pretty much anything an attacker could do by MITMing these images, they
could do by MITMing some unrelated site you have open, assuming you have at
least one unsecured connection open. So that point is, yes, at most moderately
annoying.

The issues of replacing the scripts, and snooping on the images to figure out
what pages you're viewing, are the significant ones.

True, the images are cross-origin, and cannot in themselves do anything. True, gadgets and user scripts cannot access the contents of upload.wikimedia.org files.

However, gadgets and user scripts can cause these files to be displayed on the current page. Once this is done, the images have meaning to the person viewing the page, who may make important decisions based on them. The EFF gives a nice example:

“Nor is it safe to reference images via HTTP: What if the attacker swapped the Save Message and Delete Message icons in a webmail app?”

So this issue is potentially more than moderately annoying: in fact, it is just as important as the other issues, in general. (However, for most users on the Wikimedia sites, it is probably far less important than the other issues.)

MarkAHershberger added a comment.Via ConduitJan 29 2011, 3:27 AM
  • Bug 26421 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitFeb 2 2011, 10:04 AM

emad wrote:

Hello Guys, Recently I started to use secure.wikimedia.org to surf wikipedia. Why? because in my country they block CSS files and Photos from Wikipedia pages. I was so glad to find about the secure.wikimedia.org but the pictures didn't show up when I inspected the elements I found out that only CSS files where directed to SSL pages, while the photos are still on non-SSL pages. I don't know who should I talk to, to check it and make sure photos are directed to SSL pages.

Any Ideas?

Have a nice day
Black Spider

MarkAHershberger added a comment.Via ConduitMar 6 2011, 9:27 PM

Giving half of Fred's old bugs to Ashar since I trust him to get it done or reassign if he doesn't have time.

brion added a comment.Via ConduitApr 25 2011, 5:54 PM

Any news on this?

The lack of SSL on bits.wikimedia.org and upload.wikimedia.org is considered a factor in secure.wikimedia.org being officially considered "unsupported" by Wikimedia ops.

brion added a comment.Via ConduitJul 15 2011, 11:05 PM

SSL support on upload.wikimedia.org is on now to support use of protocol-relative links to uploads on sites under their regular domains (bug 20643), but it's not yet being used on the existing secure.wikimedia.org.

Reassigning to Ryan, since he's taking care of most of this testing config stuff.

If we feel confident enough with the actual SSL serving on uploads we should be able to switch over the path settings for secure; or it can wait a bit until everything moves to bug 20643 if that ends up being a shorter journey.

RyanLane added a comment.Via ConduitJul 16 2011, 12:54 AM

rlane32 wrote:

I'd prefer to wait on this until everything is switched over to https. The SSL cluster is still being changed frequently, and isn't scaled to the growth needed to serve upload and bits yet.

brion added a comment.Via ConduitJul 16 2011, 1:11 AM

*nod* that's what I figured. :)

TTO added a comment.Via ConduitOct 3 2011, 10:42 AM

https://upload.wikimedia.org now exists, and Firefox doesn't whinge when you visit the fresh new https://en.wikipedia.org site.

Thanks to the techies for this!

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.