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

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.

• Bug 20335 has been marked as a duplicate of this bug. ***

• Bug 24239 has been marked as a duplicate of this bug. ***

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.

paxcoder wrote:

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

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.

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]

2. 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)

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

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.

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.)

• Bug 26421 has been marked as a duplicate of this bug. ***

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

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.

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.

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.

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.

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

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!