I don't understand the email also... The secure site has been arround for years... 2011/2/13, MZMcBride <z(a)mzmcbride.com>om>: -- Verzonden vanaf mijn mobiele apparaat Regards, Huib "Abigor" Laurens Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

On Sun, Feb 13, 2011 at 1:51 AM, Jay Ashworth <jra(a)baylink.com> wrote: This is something I'd very much like to fix. I had a fairly in depth discussion with the other ops folks about this last week. I think I'm going to put it on my goal list; however, we have a lot of higher priority tasks, so I wouldn't expect anything too soon. - Ryan Lane

When you finally retire https://secure.wikimedia.org/wikipedia/commons/... etc. etc. Have them HTTP 301 permanently redirect to https://commons.wikimedia.org/... etc.

Fine.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <18849937.7157.1297583642909.JavaMail.root(a)benjamin.baylink.com>om>, Jay Ashworth <jra(a)baylink.com> wrote: LVS is in front of Squid, so it would be fairly simple to send SSL traffic (port 443) to a different machine; which is how secure.wm.o works now, except that instead of using LVS, it requires a different hostname. However, I think the idea is not to start allowing https://en.wikipedia.org URLs until there's a better SSL infrastructure which can handle the extra load an easy-to-use, widely advertised SSL gateway is likely to create. secure.wm.o is currently a single machine and sometimes falls over, e.g. when Squid breaks for some reason and people notice that secure still works. SSL certificates aren't that cheap, but only about 8 would be needed (one for each project, e.g. *.wikipedia.org), so the cost isn't prohibitive anymore. - river.

afaik, the serverside encryption hasn't got any mentionable performance penalty. Clients might be a bit slower due to additional roundtrips caused by the handshakes. On Sunday, February 13, 2011 at 4:23 PM, Maury Markowitz wrote:

On Sun, Feb 13, 2011 at 9:23 AM, Maury Markowitz <maury.markowitz(a)gmail.com> wrote: Well, there's nothing we can really do about this. It's better to offer a secure site than to not. If people are having performance issues because of their ISP, they should complain to their ISP. They can also choose to use the http version, if that is the case. Right now people either get to choose between the crappy secure, or the fast insecure version of our site. - Ryan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <CFB39D2BB60F411485D2BE6D9DB072F1(a)gmail.com>om>, Leo <diebuche(a)gmail.com> wrote: I use StartSSL myself, but they don't offer wildcard certificates for free. Using non-wildcard certs would require us to request (and regularly renew) around 1,000 certs, as well as requiring a new cert for each new language project which opens. StartSSL wildcard certs might be cheaper than another provider (it's not very clear from their website), but either way there's a cost involved. - river.

----- Original Message ----- Got it. You did get the "EFF is pushing a Firefox plugin that has a rule that redirects all WP accesses to the secure site" part of that report, though, right? This curve has probably already started to ramp; now might be a good time for someone ops-y to be thinking about this. Cheers, -- jra

On Sat, Feb 12, 2011 at 10:26 PM, Chad <innocentkiller(a)gmail.com> wrote: There was a discussion about this a while back that started in #mediawiki_security and migrated to #wikimedia-operations. The problem right now is that it would require some reconfiguration work and no one's gotten around to it. Currently, secure.wikimedia.org just points to a different host from the rest of the site: $ dig +short secure.wikimedia.org 208.80.152.134 $ dig +short wikipedia.org 208.80.152.2 To put secure and regular at the same domain, they'd also need to be put on the same machine (that is, the same load balancer, which can obviously forward to separate hosts per protocol). Then you'd have the secure site split across several domains, so you'd have the question of which certificate to serve. The best answer to that seems to be putting each second-level domain (wikipedia.org, wiktionary.org, etc.) on a separate IP address, then getting a wildcard certificate for each one and serving that. You'd also want to put each second-level domain itself on a separate IP from all its subdomains, like wikipedia.org on a separate subdomain from *.wikipedia.org, because those again require separate certs. This doesn't require too many IP addresses (which can all be assigned to the same interface anyway) and avoids having to mess with SNI or such. But it would require some amount of effort to set up. Ryan Lane said he'd be interested in working on it when he finds the time. Ideally we'd have all logged-in users (at least) on HTTPS by default. But anyway, the cost of certificates certainly hasn't been an issue for years! On Sun, Feb 13, 2011 at 10:14 AM, River Tarnell <r.tarnell(a)ieee.org> wrote: You'd want two per project so that https://wikipedia.org/ works, right? Lots of sites fail at that, but it's lame: https://amazon.com/ On Sun, Feb 13, 2011 at 10:23 AM, Maury Markowitz <maury.markowitz(a)gmail.com> wrote: SSL adds an extra round-trip or two to each connection, and adds some server-side load. Currently we have much bigger client-side performance issues than this -- Resource Loader is a first stab at fixing some of the worst of those -- so I don't think we need to worry too much about it for now. If enough users used SSL, the server-side computational load might be significant, compared to just serving stuff from Squid. (Google observed almost no load increase when enabling SSL by default for Gmail, but Gmail spends a lot of CPU cycles on each page anyway -- we usually spend almost no CPU for logged-out users, just serve the cached page from Squid's memory or disk.) But not many people will use it until we make it opt-out, so I don't think we have to worry about it for now. I'm not aware of any issue with this.

On Sun, Feb 13, 2011 at 8:48 PM, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: I think most users use secure.wikimedia.org when they are behind an untrusted connection, and don't want to reveal their password, their username or articles they are reading/editing. I once tried changing my default Wikipedia site to secure, but there were more perormance issues both client and server side than unencrypted, so I changed back. However, I would still prefer to send my login details over SSL whenever I need to relogin. Currently, if you login on secure you are not logged-in on the unencrypted site, even if I allow setting third party cookies in the browser settings. I assume the login session is common to both unencrypted and encrypted, so would it be possible to transfer the session from secure.wikimedia.org? This way users could login securely but choose to use the unencrypted site for the normal tasks.

Is that how Facebook™ or Google™ operate, sending every single component via HTTPS? No. Only the vital personal settings, password stuff is done that way. As for not letting people know what pages you are browsing, well, I don't now. Does Google™ offer a way to not let wiretapping people know what pages you are searching? Probably. We Geritol™ Generation users aren't exactly sure to tell you the truth.

On Feb 16, 2011, at 10:21 AM, Brandon Harris wrote: I think y'all should chill and take the tone down from an argument to more of discussion where points of view back up their points with information. Brandon, though perhaps a bit hostile in tone, is backed up by what many consider the best practice after Firesheep. See https://www.eff.org/pages/how-deploy-https-correctly for background and recommendations. Now, in practice implementing this has challenges. I'm the lead developer on Kete, an open source Ruby on Rails app (http://kete.net.nz), and recently wanted to make the switch to fully HTTPS for a site and the Kete app when used with HTTPS. I encountered the headache of mixed content warnings. I found that using // for links I could control mostly did the trick, but external links were problematic. Specifically Google Maps API will answer HTTPS, but delivers Javascript with internal links that triggers the mixed content warning. The only workaround appeared to be pay for premier service from Google. The organization running the site doesn't have the budget for this, is a non-profit and is using the Maps API non-commercially, and wants to continue to use the API. So... I ended up falling back to current "norm" as jidanni outlines. Not happy about it, but my client and my project make use of Maps extensively and it would have been a drag. All this boils down to, yes full HTTPS is best practice, but if you make use of external APIs or services, it may be hard to achieve. Cheers, Walter ----------------------------------------------------------------- Walter McGinnis Kete Project Lead (http://kete.net.nz) Katipo Communications, Ltd. (http://katipo.co.nz) http://twitter.com/wtem walter(a)katipo.co.nz

On Tue, Feb 15, 2011 at 2:06 PM, Ryan Lane <rlane32(a)gmail.com> wrote: There was some discussion on making secure.wikimedia.org full-https functional, as I recall, but it died out. -- -george william herbert george.herbert(a)gmail.com

On 15 February 2011 15:43, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: There are people loading javascript from toolserver: http://en.wikipedia.org/wiki/MediaWiki:Common.js/watchlist.js (I'm sure the toolserver can be fixed to make ssl work in this case, but it seems quite broken for https at the moment) Conrad

Walter McGinnis wrote: Well, as someone else somewhat noted in this thread, Aryeh isn't completely correct. The Toolserver has external APIs and services that are used via JavaScript from Wikimedia wikis. More information is available about the Toolserver here: <https://wiki.toolserver.org/view/FAQ>. I appreciate you sharing your experience. Part of the resourcefulness of this list is learning how others have implemented solutions, including understanding what worked well and what didn't and why. MZMcBride

On 15 February 2011 22:09, &lt;jidanni(a)jidanni.org&gt; wrote: I can't really understand your email. As for having the ability to read Wikipedia trough a HTTPS conexion. I suppose is useful, wen you don't want to use cleartext to broadcast your intention to the worlds. Heres a map: http://en.wikipedia.org/wiki/File:World_homosexuality_laws.svg Homosexuality is illegal on the red and dark red areas. So heres a user case, some homosexual on these countries searching for general information about his homosexuality, that don't want to broadcast in cleartext his navigation trought these links. But can be any reason or none. Maybe some people is "communication sensitive" and just don't want to use cleartext for that. So heres a feature some people would want to use. -- -- ℱin del ℳensaje.

Actually, there's now a setting in Facebook to use https on every single page request. (Account Settings | Account Security | Secure Browsing (https) where there's a check box that says: Browse Facebook on a secure connection (https) whenever possible Mark W.

2011/2/15 Thomas Dalton &lt;thomas.dalton(a)gmail.com&gt;om>: Exactly. We're not gonna force users to use HTTPS for everything, but we should at least offer the possibility to those who want it. Roan Kattouw (Catrope)

On 16/02/11 05:50, Jay Ashworth wrote: I think most load balancer appliances around also handle SSL off-loading. -- Ashar Voultoiz

We use LVS w/ pybal for load balancing, not squid; otherwise, you are right. We don't use hardware load balancers, and likely will not in the foreseeable future. To be a little more on subject: I don't think it'll be a major difference between using ssl for just login, and using it for all logged in user actions. One of the more expensive parts of https is the connection. If we are logging them in, we are already doing the more expensive part, why not continue on and make the site truly secure? But really, I should have just ignored this thread since it was mostly a troll. - Ryan Lane

No. Once a connection is made, requests from the same user should go through the same connection. - Ryan

jidanni(a)jidanni.org wrote: That would mean sending normal pages with http but pretty much all /w/index.php urls using https. Seems odd at first, but it could work. Another option would be to digitally sign every token, which is more geek :) It does https://www.google.com so you only share your searches with Google Brother.