Wikimedia Foundation Enables HTTPS For All Projects

An anonymous reader writes "The Wikimedia Foundation has enabled HTTPS for all of its projects (Wikipedia, Wikimedia Commons, etc.), to enable secure log-in and browsing privacy. Their blog post goes into detail about how the service is configured, linking to configuration files and implementation documentation. It also mentions that HTTPS Everywhere will have updated rules for this change soon."

Comments

Does it support TLS 1.2 or higher?

[Anonymous Coward]

We had a recent story 2 weeks ago (http://tech.slashdot.org/story/11/09/20/1833232/hackers-break-browser-ssltls-encryption) warning us that anything less than TLS 1.1 (aka SSL 3.2) is easily decrypted, but that TLS 1.1 and TLS 1.2 (aka SSL 3.3) aren't widely adopted by servers OR web browsers.

So the question is: does Wikimedia use TLS 1.2 (or 1.3), or are they trying to lull people into a false sense of security?

Re:Does it support TLS 1.2 or higher?

[3nails4aFalseProphet]

en.wikipedia.org is currently using TLS 1.0.

Re:Does it support TLS 1.2 or higher?

[chill]

Chicken, meet egg.

What browser are you using that supports TLS 1.1 or 1.2? IE 8 doesn't. I don't know about 9. Firefox doesn't -- it depends on OpenSSL and the release version of that product doesn't support TLS > 1.0.

Re:Does it support TLS 1.2 or higher?

[Tomato42]

1. Both IE8 and IE9 do support TLS1.1 if run on OS that supports it (read Vista, 7, or server editions of those)
2. Windows 7 brings support for TLS1.2
3. Firefox doesn't use OpenSSL, it uses Mozilla's NSS
4. Newest OpenSSL does have support for TLS1.2, albeit testing only

greeat

[waddgodd]

Of course, wait until after the persistent TLS1.0 connection bug gets exploited. Because, you know, nothing says "we care about security" quite as much as making available an exploited protocol.

It's a good thing.

[Frosty Piss]

Sure. When I look up "Dog Poop Girl" I need to make sure the government isn't tracking it...

Great... Now, if only we could trust EVERY CA.

[Anonymous Coward]

It only takes one CA being compromised to compromise THE ENTIRE SYSTEM of TLS / SSL...
DigiNotar.
Additionally: *.* cert... <- WTF, who's brilliant idea WAS that feature?!

Fact: The biggest problem with the CA system is that any CA can create a cert for ANY DOMAIN even if the domain owner doesn't request the cert first.

Thus, EVERY CA must be 100% secure 100% of the time. TLS / SSL isn't a system that has a single point of failure... It's a system that has many Hundreds of points of failure; Any one of them being enough to cause the whole trust model to fall apart like so many cards stacked in the shape of a house.

Your browser probably doesn't trust DigiNotar, but does it trust CNNIC?
http://yro.slashdot.org/story/10/02/02/202238/mozilla-accepts-chinese-cnnic-root-ca-certificate

FF: Tools/Edit > Options/Preferences > Advanced > Encryption > View Certificates

You trust ALL OF THESE?! Well, enjoy your security theater suckers.

Re:Great... Now, if only we could trust EVERY CA.

[TooMuchToDo]

So could we do something similar to SPF/DomainKeys? You create a public key that you advertise via DNS and require the private key to be uploaded to the CA to get the certificate? That would ensure only the domain owner could request the SSL certificate.

Re:Great... Now, if only we could trust EVERY CA.

[Anonymous Coward]

I just love reading the same post, more or less, in every article.

Re:Great... Now, if only we could trust EVERY CA.

[phantomfive]

You do realize that this has been a problem from the beginning, right? If you sound surprised, it's only because you only recently started paying attention.

In practice, there are multiple layers of security, and this is just one of them.

Re:Great... Now, if only we could trust EVERY CA.

[phantomfive]

How much do you trust your DNS registrar?

Not to mention, DNS can be spoofed (maybe someday it won't be, but ultimately you have to trust someone).

Re:Great... Now, if only we could trust EVERY CA.

[bertok]

Because he's got a good point that the internet community has been ignoring until the Diginotar fiasco. It wasn't that obvious a problem for most people, it was just one of those things that happens "behind the scenes", and nobody except some paranoid security researchers cared.

But really, think about it for a second: why are we allowing a country-specific CAs to issue certificates for a TLD other than their country TLD?

I can understand why a Root CA certificate doesn't have any restrictions in it (that would be annoying for the CA), but why does the browser have to take that certificate at face value?

For example, the Windows operating system can be told to restrict its trust of a Root CA certificate to a specific set of purposes. It's a bit obscure, but it's there. Firefox has a system for this as well, but it just has a set of check boxes: "web", "email", and "software". Neither system is fine-grained or easily customisable.

Why can't web browser developers take a few hours out of their time to add a "list of DNS suffixes" to the restriction options, and populate them when releasing the root CA updates? For example, Firefox trusts "TURKTRUST Elektronik Sertifika Hizmet Saglayicisi" by default -- which I'm perfectly fine with, as long as it's for "*.tr" domains only! I'm not so fine with trusting that organisation for ".com".

Sure, that change would break some websites -- but that's the point.

Re:Great... Now, if only we could trust EVERY CA.

[intiha]

http://yro.slashdot.org/story/10/02/02/202238/mozilla-accepts-chinese-cnnic-root-ca-certificate

FF: Tools/Edit > Options/Preferences > Advanced > Encryption > View Certificates

You trust ALL OF THESE?! Well, enjoy your security theater suckers.

Just checked this out... Damn, I have a gazillion cert authorities from all over the world, in languages I can even recognize. So What THE F**K should we do? any reliable tool to keep working with cert authorities and trusting the green icon on FF. Please some one tell me (is there a FF extension that can help weed out the unsavory CA). This is a shame, since ordinary people were finally getting the message that "Look at the green icon/key/lock before you trust a website", and now that security has proven a mirage... no surprise that the average person if frustated by security and would rather deal with post-phishing problem than have some day-to-day diligence regarding security..

Re:Great... Now, if only we could trust EVERY CA.

[bertok]

In practice, there are multiple layers of security, and this is just one of them.

There really isn't. For web SSL/TLS, there's exactly one layer of trust: the certificate authorities.

There's no other check that the browser performs. If a trusted CA signed a cert, it hasn't expired, and it's not in a revocation list (maintained by the CA), then it's OK.

That's it.

Re:Great... Now, if only we could trust EVERY CA.

[phantomfive]

In addition to what the other poster has mentioned, you can also verify visually that the website you are connecting to is the one you expect. You can use temporary credit card numbers. No method of security is perfect, but if you thought the CA system was, then you were fooling yourself. All security breaks down at trust.

Re:Great... Now, if only we could trust EVERY CA.

[dkf]

How much do you trust your DNS registrar?

What's more, if your DNS registrar is crooked (or broken into), you're stuffed because you can't go to someone else nearly as easily as with a CA.

Re:Great... Now, if only we could trust EVERY CA.

[icebraining]

But really, think about it for a second: why are we allowing a country-specific CAs to issue certificates for a TLD other than their country TLD?

What are the non-country-specific CAs, then? Every company is registered in some country. Being registered in the US doesn't make it less "country-specific".

Unless you propose to eliminate the gTLDs, I don't see why would only some CAs have the power to sign for them.

Re:Great... Now, if only we could trust EVERY CA.

[ObsessiveMathsFreak]

Yes, but this is the layer which causes end users browsers to throw a yellow screaming fit if they try to use an encrypted connection outside of the CA club.

Re:Great... Now, if only we could trust EVERY CA.

[petermgreen]

In practice, there are multiple layers of security

In a normal SSL web browser configuration there are exactly two layers of security, SSL and the security of the underlying network you are using. Break both of those and you can set up as a man in the middle and sniff the user's data.

You do realize that this has been a problem from the beginning, right?

However it is a problem that has got worse over time for several reasons.

Firstly the list of trusted CAs has been ever growing both through the addition of root certs to browsers and through the issuance of "intermediate certs" by the existing CAs. How many people know that their browser trusts the Chinese government?

Secondly people used to access the internet through relatively safe networks (while ethernet isn't secure you at least need a physical connection to mess with it). However there is a trend towards use of wifi hotspots which are usually unencrypted and relatively easy to subject to man in the middle attacks.

Fixed link

[subreality]

Oh, for the love of crypto.

Re:Fixed link

[ThatsMyNick]

https://www.eff.org/https-everywhere

Thank you, thank you very much!

[Anonymous Coward]

Whoa, this is an incredibly neat deed for many wiki-editors out there, including myself. Ever since a neighbouring government passing all my foreign-bound data decided to start reading all my IP traffic to build a comprehensive sociogram of my believes, affiliations and interests, I became increasingly paranoid and afraid of expressing myself online on foreign sites. I tried using secure.wikimedia.org, but the site had unsatisfactory stability and responsiveness compared to the unencrypted site. So I just continued using the unencrypted site, but avoiding sensitive topics.

I hope this decision finally enables us to use Wikipedia even for editing sensitive topics, and more importantly hiding our wiki-identity from the government. Kudos to the Wikimedia technical team, you are doing a great job!

Awesome timing

[Arancaytar]

Public trust in the security of HTTPS and SSL certificate authorities is at a literally unprecedented level right now.

Re:Awesome timing

[petermgreen]

If the choice is being exposed to a passive sniffer vs being exposed to those prepared to perform man in the middle attacks (which carry a far higher risk of getting caught for the attacker) I'd go for the latter.

On the gripping hand

[FatLittleMonkey]

Now I have to remember my damn wikipedia password.

no other checks?

[Onymous Coward]

There's no other check that the browser performs.

My browser has Perspectives and Certificate Patrol. This way I know if other network locations are seeing the same cert that I'm seeing, and whether that cert's changed recently.

https://slashdot.org?

[Anonymous Coward]

So, when will slashdot follow? Currently https://slashdot.org just redirects to http://slashdot.org

Re:https://slashdot.org?

[jones_supa]

Good question. As a geek site, Slashdot should be a pioneer in these things. Full Unicode character support has also been missing for a long time. The box for notification messages on the front page feels a bit old too, something like the Facebook globe icon could be more sleek. Different color themes. Things like that.

Re:https://slashdot.org?

[Jeremy Visser]

It's supported, but only available to subscribers. If you're not logged on as a subscriber, it redirects you to the insecure version.

Nice touch, eh?

Adds to greenhouse problem

[Jimbookis]

How much extra juice does it take for masses of GMail and Wiki and Facebook servers to do the work to encrypt all this data (plus the end use machines)?

Re:Adds to greenhouse problem

[heypete]

Not much:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

Re:Adds to greenhouse problem

[Threni]

Perhaps the browsers can soon start warning users that they've about to visit an insecure site and ask if they wish to continue?

Re:Adds to greenhouse problem

[ledow]

Nowhere near 0.1% of the extra power, bandwidth, etc. caused by compromised machines, virus-ridden-spam-hosts, etc. that *can* be caused by visiting sites that you *think* are Google, Wikipedia, Facebook etc. when in fact they're not.

And anybody who worries about the environment impact of an SSL enablement really needs to go see the size and power requirements of the average ISP's datacentre, let alone someone like Google.

The problem with greenies is *not* their intentions, it's the fact that they choose TOTALLY the wrong targets to cut down on. Energy-saving lightbulbs, clockworks radios, EnergyStar monitors etc. mean *SHIT* compared to one household accidentally leaving the aircon / heating on for an extra hour for one night each decade.

Greenies should be targeting those with swimming pools, hot-tubs, aircon in countries that really don't need it, etc. rather than try to make the average householder feel guilty for his 40W bulb and TV-on-standby. You are literally orders-of-magnitude out in the things you worry about. And also you are targeting USEFUL energy (because the SSL has a purpose) and not useless energy (like that lost because someone didn't bother to close the lid on their hot-tub properly).

Re:Adds to greenhouse problem

[icebraining]

I seriously hope not. SSL adds latency to the connection and is completely useless for a huge number of websites. Why would I need SSL to access a e.g. recipes page which doesn't even have a login page?

Re:Adds to greenhouse problem

[vlm]

I seriously hope not. SSL adds latency to the connection and is completely useless for a huge number of websites. Why would I need SSL to access a e.g. recipes page which doesn't even have a login page?

You want to cook a non-Halal recipe in a Halal nation where improper religious observation will get you killed? Really simple example would be looking up mixed-drinks cocktails in Saudi Arabia...

Re:Adds to greenhouse problem

[Anonymous Coward]

I don't want middlemen tampering with what I see. I don't want my internet censored before it gets to me. That's the reason for HTTPS everywhere.

Re:Adds to greenhouse problem

[Anonymous Coward]

Your reasoning is valid when the only goal is to protect sensitive information, such as banking details or what kind of horse-porn you enjoy.

When looking at the bigger picture, simply seeing the encrypted stream and where it's headed is enough to build a reasonably accurate image of your online habits. I recently heard Stefan Burschka talk about his work with mining encrypted VOIP traffic to determine the content - he does this with an accuracy of 66% per sentence just by knowing the timing between packets and the size of the encrypted payload. I'm convinced similar techniques can be applied to behavioral analysis on networks.

When the FRA-law was passed here in Sweden there was a lot of talk about encryption, and how "terrorists will just encrypt their messages". FRA and politicians essentially said "we don't really give a shit what's in the datastream, we just need to know what hosts talk to each other". As someone who works in a related field (I basically sit around all day and analyze logs from routers to track statistical anomalies in the network) - encryption can only get you so far in protecting your privacy.

Re:Adds to greenhouse problem

[Threni]

> Why would I need SSL to access a e.g. recipes page which doesn't even have a login page?

No no, you've got it backwards. Why shouldn't all communication be secure and encrypted? Latency isn't important unless you're gaming; certainly not the minuscule 1% or whatever it is SSL costs. It's no-one's business which sites you go to and what you do when you get there.

Re:Adds to greenhouse problem

[icebraining]

HTTPS doesn't prevent people from knowing which sites you go to - not only they have its IP, as SNI means the domain is sent in cleartext to make sure the server sends the right certificate.

Domain isn't that irrelevant when you have a bunch of different domains to load on a single webpage, which is extremely common nowadays.

Re:Adds to greenhouse problem

[icebraining]

We should have signed pages without the need for encryption and its inevitable handshake. Like hashing the contents, encrypting it with the personal key of the server's cert and sending it as response header.

As for censoring, they can still ban the domain, with or without HTTPS.

Do some CAs have really cheap certs now?

[Lazy Jones]

I can imagine that the other compromised CAs by the comodo hacker have made Wikipedia an offer they couldn't refuse.

Do you

[xororand]

Do you have curtains?
Surely your life is not interesting enough to require curtains.

Any sysadmins for large web servers out there?

[Lisandro]

I was wondering - Âhow much stress does enabling HTTPs on a huge site like Wikipedia puts on a modern web server? IIRC this was one of the reasons Facebook took quite a while to enable SSL for their users.

Re:Any sysadmins for large web servers out there?

[Carnildo]

It depends on your network infrastructure, especially how CPU-intensive your content is already.

Google's numbers are a 2% increase in network traffic, a 1% increase in CPU usage, and 10kb RAM per connection. Your network numbers will go up if you've got SSL frontend servers talking to content backend servers (Wikipedia's solution), while your CPU numbers will go *way* up if most of what you're serving is static content (this is where SSL's reputation as a CPU hog came from; these days, almost everyone serves CPU-heavy dynamic content and won't notice much of an increase).

Re:Any sysadmins for large web servers out there?

[Lisandro]

Thank you.

If only Google would do this too.

[GargamelSpaceman]

I use HTTPS everywhere, but it sends me to an experimental search page for google that lacks the standard tabs. I mostly want standard tabs, so this is annoying.

Caching?

[chill]

Encrypted connections can't be cached by a proxy, unless the proxy acts as a man-in-the-middle. While this is popular at many companies, I don't see a lot of support for your ISP doing it.

SSL Everywhere, if successful, will be the death of caching. Is that a good thing?

Well, Maybe...

[Nom du Keyboard]

Considering all of the compromised SSL certificates, you may not be any more private with this change than before.

The Latvian thing

[martinve]

Nice to have Wikipedia running on Lativan version of standard HTTP protocol (https). But then again, I am an Estonian who commented on the item 2 days late.