back to article Wikipedia to go all HTTPS, all the time

The Wikimedia Foundation has decided the time is right to implement HTTPS on all its projects, for all users, all the time. It's been possible to access the Foundation's works – notably Wikipedia – with HTTPs for a while if you're willing to jump through some hoops. The Foundation's now decided to go all-HTTPs, all the time, …

  1. Rebecca M

    Playing to the gallery

    No doubt this will be hugely popular among editors as a way of sticking it to the man but my initial thoughts are simply "Why?"

    The technical arguments are against it - Wikipedia is already an incredibly slow site thanks to the seemingly infinite number of templates and other elements making up each and every page. If a page consists of 100 or more separate elements (fairly common for WP pages) adding even a small overhead to each and every one adds up to a large amount of additional sluggishness. Reducing the cacheability of the site makes matters even worse.

    The next consideration is what proportion of activity is actually sensitive. The vast bulk is perfectly innocuous. There may occasionally be things you don't want making public, e.g. looking up those genital warts, but is the average spook or fraudster really looking for things like that? How much traffic is actually and genuinely sensitive in nature? Calling for this kind of thing as a universal default strikes me as a poorly considered knee-jerk reaction that can only harm the project in the long term.

    1. John Geek

      Re: Playing to the gallery

      odd, I've nearly always found Wikipedia to be quite fast and snappy. Now, true, my internet connection is just a few hops from the major hubs in the greater SF Bay Area, maybe that has something to do with it.

    2. Kanhef

      Re: Playing to the gallery

      MediaWiki renders each article - including templates used - into a single HTML page, so complex articles won’t be any slower to load than simple ones. Articles with a large number of images may require more connections, but that’s true of any site.

      I agree that most articles aren’t sensitive, but how do you determine which ones are? If someone is at a sensitive page sent through HTTPS and browses to a non-sensitive page sent through HTTP, their history will be revealed through the Referer: header. If the server has any way to say "you’re not looking at a sensitive page, I’m switching back to HTTP", there’s a MITM encryption-downgrade attack waiting to be found. It’s much simpler to just encrypt everything and not worry about the details.

      1. DaLo

        @Kanhef |RE:Referrer

        "HTTPS and browses to a non-sensitive page sent through HTTP, their history will be revealed through the Referer: header"

        Doesn't work like that RFC 2616 deems clients should not include a referrer header when linking or redirecting from secure to unsecure for that reason. I've not come across a client that doesn't abide by this.

    3. Charles 9

      Re: Playing to the gallery

      "Reducing the cacheability of the site makes matters even worse."

      Given how easy it is for any given page of the Wikimedia project to be edited, caching would actually work against you rather than for you since there's a chance you'll miss an edit. If data constraints are such a big issue, perhaps that should encourage browsers to adapt hash requests over HTTPS to compensate.

      1. Michael Wojcik Silver badge

        Re: Playing to the gallery

        caching would actually work against you rather than for you since there's a chance you'll miss an edit

        If only HTTP/1.1 had a dozen mechanisms to address that issue. Oh, wait....

    4. Trevor_Pott Gold badge

      Re: Playing to the gallery

      "Why?"

      Because privacy isn't only for the privileged.

      1. bazza Silver badge

        Re: Playing to the gallery

        Because privacy isn't only for the privileged.

        Hmm, browsing Wikipedia isn't exactly on the same level as Internet banking... I can't see any MITM attacker being delighted to have discovered what embarrassing medical conditions someone has been reading about.

        The only possible motivation is to allow, say, Chinese readers to safely read pages about democracy, etc. Now that really is a noble aim and one worth applauding.

        Unfortunately it will probably backfire. China will simply block access and then everyone is worse off.

        1. Craigness

          Re: Playing to the gallery

          Why did the "Hmm, browsing Wikipedia isn't exactly on the same level as Internet banking..." comment get downvotes? It's obvious that someone going to "https://wikipedia.com/human_rights_in_china" is not at all protected by the HTTPS protocol whereas someone going to "https://mybank.com/viewaccount" is giving away comparatively little information to their ISP and the various public authorities which watch over us.

          1. DaLo

            Re: Playing to the gallery

            "It's obvious that someone going to "https://wikipedia.com/human_rights_in_china" is not at all protected by the HTTPS protocol"

            Eh? Care to explain?

    5. Thought About IT

      Self-censorship

      I just finished watching the first season of Breaking Bad at the weekend and wanted to check what it said about ricin. Then I thought, what if the spooks think I'm planning to murder someone? The insidious process of self-censorship has started. Anyway, I tried sticking https in Wikipedia's URL and it worked, so I carried on and looked up ricin and even followed the link to lily of the valley. Nothing to hide? Sure, but nothing to fear ...

      1. Solmyr ibn Wali Barad
        Big Brother

        Re: Self-censorship

        "so I carried on and looked up ricin"

        ...over the reliably fingerprinted connection. Thank you, citizen.

    6. Anonymous Coward
      Anonymous Coward

      Re: Playing to the gallery

      >The next consideration is what proportion of activity is actually sensitive.

      If you only encrypt sensitive activities then that highlights them with a big sign reading "THIS PERSON IS CARRYING OUT A SENSITIVE ACTIVITY HERE". You need to encrypt everything, all the time.

    7. Michael Wojcik Silver badge

      Re: Playing to the gallery

      my initial thoughts are simply "Why?"

      Because all-HTTPS is the religion of the month, as the many downvotes to your post attest.

      The cryptofanatics brand all threat models but their own as heresy. Everything must be encrypted! Do not question it!

  2. John H Woods Silver badge
    Joke

    Everybody's doing it ...

    ... El Reg will be next!

    1. Marco Fontani

      Re: Everybody's doing it ...

      Soon®

    2. Yes Me Silver badge
      Meh

      Re: Everybody's doing it ...

      All the information on Wikipedia, like all the information on El Reg, is freely available to the public. So you have to ask very carefully what is gained by encrypting the payload. It's well established that traffic analysis works quite well on HTTPS headers. if you doubt that, see https://arxiv.org/pdf/1403.0297. A user under a repressive regime can't conceal very much of what they're doing at all by preferring HTTPS. For a quite passionate debate on this, look at the thread starting at http://www.ietf.org/mail-archive/web/ietf/current/msg93261.html

      1. Anonymous Coward
        Anonymous Coward

        Re: Everybody's doing it ...

        You log on to El Reg. It should have use SSL for that at least! Without it your employer (sometimes the one you are using in an anecdote or even criticising) can make a case for dismissal against you.

        IDS can also flag up every time a plaintext password is used. As the login field is called "password" then it will be picked up without even needing heuristics. So a nice little alert bounces to your sysadmin every time you log in to The Register using your work PC rendering anonymous postings pointless for that scenario.

        1. Angus Ireland
          Coat

          Re: Everybody's doing it ...

          Ian Duncan Smith is flagging up my plaintext logins?!

  3. Mark 85

    Will there now be a "cash call" for implementing this?

    Seems like every time one turns around, they're asking for money. Would all funds raised actually go towards the implementation since there's been many questions in the past about fund-raising efforts and few answers.

    I'm sure I'll get downvoted but I think it's a valid question.

    1. Anonymous Coward
      Trollface

      Re: Will there now be a "cash call" for implementing this?

      Seems like every time one turns around, they're asking for money

      One could read the article and one could also read the blog post that it references but I suspect one just wanted to whinge a bit about a very useful free service.

    2. Lars Silver badge

      Re: Will there now be a "cash call" for implementing this?

      I won't downvote you but somehow I would consider your questtion more valid if you had given them some money. I have not, but I hope there are those who do, we are better off with the Wiki than without one.

      1. Mark 85
        Facepalm

        Re: Will there now be a "cash call" for implementing this?

        I have given money in the past several times and I've been hit for more also. I probably should have mentioned that in my post.

    3. Anonymous Coward
      Stop

      Re: Will there now be a "cash call" for implementing this?

      I use Wiki, but have not donated. Until they are more transparent I have no intention of doing so.

      The same reason I don't give to 90% of charities that I would otherwise consider.

    4. DropBear
      Mushroom

      Re: Will there now be a "cash call" for implementing this?

      "Will there now be a "cash call" for implementing this?"

      Why, did the previous one end yet? Wouldn't know, considering I explicitly filter anything that sounds like a 'fund-raising' or 'central message' div for that site on all my computers ever since the latest missive of that useless bunch of money-wasting bureaucrats (who could easily run the servers for another decade with what they already have) covered over half of my entire screen. When they'll downsize to the personnel strictly needed to run the hardware and manage to prove they've spent all they had on strictly running the hardware and they stop using huge-ass banners 24/7/365 (once a year as in all throughout the year) I'll be happy to reconsider.

  4. Anonymous Coward
    Anonymous Coward

    HTTPS and slow speeds

    It's all very well for someone in CA to decide that "it won't slow things down much", but they've probably never tried to settle a family argument whilst on a dodgy GPRS connection on a B road in West Wales.

    The point being - is this move to HTTPS-only a benefit to solve first-world problems, to the detriment of rural communities?

    1. Solmyr ibn Wali Barad

      Re: HTTPS and slow speeds

      Lost packets & retransmits are a major pain. With plain HTTP they are barely noticeable, whereas secur-ish connections will suffer badly.

      But hey, HTTPS is the next best thing after thorium (or was it sliced bread), so we should bow to the consensus here.

  5. John Robson Silver badge

    Hmm...

    "Accounts may also be hijacked, pages may be censored, other security flaws could expose sensitive user information and communications"

    Accounts may be hijacked - well clearly logins should always have been be over HTTPS

    Pages may be censored - well, they still can - just go and edit it!

    Security flaws - might still exist, so there is no net gain there...

    Not quite sure about the justification here...

    1. Charles 9

      Re: Hmm...

      "Not quite sure about the justification here..."

      With ANY in-the-clear transmission, your stuff can be altered in-flight by any relay. That's how the Chinese Cannon works, and Verizon's session tagging, and that's why Telnet and rlogin were abandoned for Secure Shell. Using HTTPS blocks this in situ modification unless the relay can masquerade as the source site.

      1. Michael Wojcik Silver badge

        Re: Hmm...

        With ANY in-the-clear transmission, your stuff can be altered in-flight by any relay.

        And MY threat model is the BEST threat model and everyone must subscribe to it.

        But, sure, use HTTPS for everything. Given the hundreds of dodgy CA certificates present in the popular browsers, and the constant stream of other HTTPS vulnerabilities, all you'll accomplish is slowing things down for everyone. And gaining an opportunity for vapid self-congratulation and corporate PR, of course.

        1. Charles 9

          Re: Hmm...

          It's STILL better than having all your dirty laundry out for the world to see...AND MODIFY ON THE FLY. Got any better ideas besides just hanging our butts in the breeze?

        2. John Robson Silver badge

          Re: Hmm...

          @Charles 9 - With ANY in-the-clear transmission, your stuff can be altered in-flight by any relay.

          I don't need to modify Wikipedia on the fly - I can just edit the page directly, that's kind of the point of a wiki.

          And if I'm doing on the fly modification - I can probably make a nice certificate as well anyway - when did you last check the CAs on your browser?

          Additionally HTTPS isn't the best solution for ensuring that data isn't modified in flight - that only requires (signed) hashes (which could be included in the page).

          Just because you have a hammer in your hand doesn't make everything a nail.

          1. Charles 9

            Re: Hmm...

            "I don't need to modify Wikipedia on the fly - I can just edit the page directly, that's kind of the point of a wiki."

            Don't think the content itself. Think hostile script injection like the Chinese Cannon.

            "And if I'm doing on the fly modification - I can probably make a nice certificate as well anyway"

            That would take a lot more resources than just a relay. You'd need to plunk down for the certificate and to make it a dead ringer for Wikimedia would likely take state-level resources, in which case they'll just attack you directly if they REALLY want you. In which case you're staring down the barrel and are screwed anyway.

            "Additionally HTTPS isn't the best solution for ensuring that data isn't modified in flight - that only requires (signed) hashes (which could be included in the page)."

            But if the hashes are in the clear, THEY can be modified on the fly, too, to match, and if you have to transmit the hash encrypted, why not the whole page?

            Let me put it this way. Why else were telnet and rlogin abandoned for ssh?

            "Just because you have a hammer in your hand doesn't make everything a nail."

            And just because not everything is a nail doesn't mean there are no nails at all. And some of them might have been nailed from the other side, leaving the room with a serious tetanus risk if you don't start nailing those points back down.

  6. Mr Miser

    I really appreciate them doing things in house. The more sites are dragged in, the more dodgy it gets. Even with a handy add-on like noscripts, at a certain point i can't even figure out what parts contribute positively and what parts are cruft. Sites like wikipedia just give me what I want. Only occasionally will I block their scripts because the "$3 per person please" banner gets annoying.

  7. dephormation.org.uk
    Gimp

    Excellent.

    Ecryption is essential to negate the effects of mass surveillance, and scams like Phorm.

  8. Old Handle

    Censorship Angle

    So, if this had been place however many years ago that was, would it have stopped IWF from meddling with album art?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon