Yes, just the open encyclopaedia that lets any user with any IP address to edit any page for any reason, without even having to bother to create an account beforehand, or provide any identifying information other than the IP address assigned by their ISP itself.
Blocking even read-only access, unless a TLSv1.2 or newer device is used (plain-text HTTP access has been blocked a while ago as well).
tl;dr: This would notably block Wikipedia access for many Android and iOS devices — you can no longer use those devices to even read Wikipedia. Yes, if you buy a new device, you can edit any page; but if you have an old device, you can’t even read any of them. Is this a technology limitation? No, it’s pure politics, and www.google.com still works without https, BTW (might depend on your browser).
For Floodgap, since I specialize in old computers and I enjoy it when people access it with old machines, while TLSv1.2 is available and you can facultatively enable HSTS, I’m not going to remove unencrypted HTTP access.
I think for a certain class of very geriatric machine Gopher is a better option, though.
They’re blocking access from old devices for absolutely no technical reason; they’re blocking read-only access from folks that might not have any other devices at their disposal.
If you have an old iPod lying around, why on earth should you not be able to read Wikipedia on it? Absolutely no valid technical reason to deny access. Zilch. None. Nada.
There’s no reason it shouldn’t be possible to read Wikipedia over straight HTTP, for that matter.
I know next to nothing about security so correct me if I’m wrong, but doesn’t leaving old protocols enabled make users vulnerable to downgrade attacks?
You’re applying bank-level security to something that’s public information and should be accessible to everyone without a licence or access control in the first place. I don’t even know what sort of comparison to make here best, because in my view requiring HTTPS in the first place here was a misguided decision that’s based on politics, corporate interests and fear, not on rational facts. Postel’s law is also a well-known course of action in telecommunication, even Google still follows it — www.google.com still works just fine over straight HTTP, as does Bing, no TLS mandated from those who don’t want it.
I agree with you, I’d like to be able to access Wikipedia with HTTP, but this is in my opinion a different issue from disabling old encryption protocols.
Accessing Wikipedia with secure and up to date protocols might not be necessary to you but it might be for people who live under totalitarian regimes. One could argue that said regimes have better ways to snoop on their victims (DNS tracking, replacing all certificates with one they own…) but I still believe that if enforcing the use of recent TLS versions can save even a single life, this is a measure worth taking. It would be interesting to know if Wikipedia has data on how much it is used by people living in dictatorships and how much dropping old TLS versions would help these people.
It’s funny you mention it, because this actually would not be a problem under a totalitarian regime with a masquerading proxy and a block return policy for the https port and/or their own certificates and a certificate authority. See https://www.xkcd.com/538/.
Also, are you suggesting that Wikipedia is basically blocking my access for my own good, even though it’s highly disruptive to me, and goes against my own self-interests? Yet they tell me it is in my own interest that my access is blocked? Isn’t that exactly what a totalitarian regime would do? Do you not find any sort of an irony in this situation?
this actually would not be a problem under a totalitarian regime with a masquerading proxy and a block return policy for the https port and/or their own certificates and a certificate authority.
Yes, this is what I meant when I wrote “One could argue that said regimes have better ways to snoop on their victims”.
Also, are you suggesting that Wikipedia is basically blocking my access for my own good
No, here’s what I’m suggesting: there are Wikipedia users who live in countries where they could be thrown in jail/executed because of pages they read on Wikipedia. These users are not necessarily technical, do not know what a downgrade attack is and this could cost them their lives. Wikipedia admins feel they have a moral obligation to do everything they can to protect their lives, including preventing them from accessing Wikipedia if necessary. This is a price they are willing to pay even if it means making Wikipedia less convenient/impossible to use for other users.
If they left http, yeah, sure. But I don’t think any attack that downgrades ssl encryption method exists, both parties always connect using the best they have. If there exists one, please let me know.
There is no technical reason I’m aware of. Why does wikipedia do this? It’s not like I need strong encryption to begin with, I just want to read something on the internet.
I still have usable, working smartphone with android Gingerbread, it’s the first smartphone I ever used. It’s still working flawlessly and I’m using it sometimes when I want to quickly find something when my current phone has no battery and I don’t want to turn on my computer.
This move will for no reason kill my perfectly working smartphone.
Which exact page you’re looking at may be of interest, e.g. if you’re reading up on medical stuff.
Are you suggesting that we implement access control in public libraries, so that noone can browse or checkout any books without strict supervision, approvals and logging by some central authority? (Kinda like 1984?)
Actually, are you suggesting that people do medical research and trust information from Wikipedia, literally edited by anonymous people on the internet?! HowDareYou.gif. Arguably, this is the most misguided security initiative in existence if thought of in this way; per my records, my original accounts on Wikipedia were created before they even had support for any TLS at all; which is not to say it’s not needed at all, just that it shouldn’t be a mandatory requirement, especially for read-only access.
Are you suggesting that we implement access control in public libraries, so that noone can browse or checkout any books without strict supervision, approvals and logging by some central authority? (Kinda like 1984?)
I’m saying that you may not wish other people to infer what medical conditions you may have based on your Wikipedia usage. So TLS as the default is desirable here, but whether it should be mandatory is another question.
Are you suggesting that we implement access control in public libraries, so that noone can browse or checkout any books without strict supervision, approvals and logging by some central authority? (Kinda like 1984?)
PSST, public libraries in the western world already do this to some extent. Some countries are more central than others thanks to the US PATRIOT Act.
Not my experience at all; some private-university-run libraries do require ID for entry; but most city-, county- and state-run libraries still allow free entry without having to identify yourself in any way. This sometimes even extends to making study-room reservations (can often be made under any name) and anonymous computer use, too.
I still have usable, working smartphone with android Gingerbread, it’s the first smartphone I ever used. It’s still working flawlessly and I’m using it sometimes when I want to quickly find something when my current phone has no battery and I don’t want to turn on my computer.
This move will for no reason kill my perfectly working smartphone.
It’s not working flawlessly, the old crypto protocols and algorithms it uses have been recalled like a Takata airbag, and you’re holding on because it hasn’t blown up in your face yet.
our ire should be directed to the smartphone OS vendor for not providing needed updates to encryption protocols
I think it’s pretty clear that the user does not need encryption in this use-case, so, I don’t see any reason to complain to the OS vendor about encryption when you don’t want to be using any encryption in the first place. Like, seriously, what sort of arguments are these? Maybe it’s time to let go of the politics in tech, and provide technical solutions to technical problems?
I don’t think what passes for “postel’s law” is what Postel meant, anyway.
AFAICT, Postel wasn’t thinking about violations at all, he was thinking about border conditions etc. He was the RFC editor, he didn’t want anyone to ignore the RFCs, he wanted them to be simple and easy to read. So he wrote “where the maximum line length is 65” and meant 65. He omitted “plus CRLF” or “including CRLF” because too many dotted i’s makes the prose heavy, so you ought to be liberal in what you accept and conservative in what you generate. But when he wrote 65, he didn’t intend the readers to inter “accept lines as long as RAM will allow”.
As I understand it, they’re protecting one set of users from a class of attack by disabling support for some crypto methods. That seems very far from “absolutely no technical reason”.
As for HTTP, if that were available, countries like Turkey would be able to block Wikipedia on a per-particle basis, and/or surveil its citizens on a per-article basis. With HTTPS-only, such countries have to open/close Wikipedia in toto, and cannot surveil page-level details. Is that “no reason”?
As for HTTP, if that were available, countries like Turkey would be able to block Wikipedia on a per-particle basis, and/or surveil its citizens on a per-article basis. With HTTPS-only, such countries have to open/close Wikipedia in toto, and cannot surveil page-level details. Is that “no reason”?
I don’t understand why people think this is an acceptable argument for blocking HTTP. It reminds me of that jealous spouse scenario where someone promises to inflict harm, either to themselves or to their partner, should the partner decide to leave the relationship. “I’ll do harm if you censor me!”
So, Turkey wants to block Wikipedia on a per-article business? That’s their decision, and they’ll go about it one way or another, I’m sure the politicians they don’t particularly care about the tech involved anyways (and again, it’s trivial for any determined entity to block port 443, and do a masquerade proxy on port 80, and if this is done on all internet connections within the country, it’ll work rather flawlessly, and noone would know any better). So, it’s basically hardly a deterrent for Turkey anyways. Why are you waging your regime-change wars on my behalf?
Well, Wikipedia is a political project, in much the same way that Stack Overflow is. The people who write have opinions on whether their writings should be available to people who want to read.
You may not care particularly whether all of or just some of the information on either Wikipedia or SO are available to all Turks, but the people who wrote that care more, of course. They wouldn’t spend time writing if they didn’t care, right? To these people, wanting to suppress information about the Turkish genocide of 1915 is an affront.
So moving to HTTPS makes sense to them. That way, the Turkish government has to choose between
allowing Turks to read about the genocide
not allowing Turks any use of Wikipedia
The Wikipedians are betting that the second option is unpopular with the Turks.
It’s inconvenient for old ipad users, but if you ask the people who spend time writing, I’m sure they’ll say that being able to read about your country’s genocide at all is vastly more important than being able to read using old ipads.
So what’s to stop a totalitarian regime from doing the following?
Redirect all DNS queries to their own DNS servers? The root DNS servers use fixed IP addresses, so it would be easy enough to reroute those addresses to return any address they want.
Redirect all DoH to 1.1.1.1 (or other well known DoH addresses) to again, their own server? Is the CloudFlare public key installed on all browsers? How would you know you are hitting CloudFlare, and not TotallyCloudFlare served by TotallyLegitCA?
Given control over DNS, redirect users to TotallyWikipedia? Again, do you know what CA Wikipedia uses? They can then decode (doesn’t matter if it’s SSL/1.0 or TLS/1.3) the request and proxy it or send out security to question the loyalty of the citizen. Or you know, download the entirety of Wikipedia (which anyone can do), and serve up a cleaned up version to their citizens.
The difficulty is to setup/enrole TotallyLegitCA. How do you do that? If TotallyLegitCA is public, the transparency log will quickly reveal what they are doing. The only way to pull that seems to force people to have your CA installed, like Kazakhstan is doing.
That’s actually incorrect. There are various technical reasons. But also remember that they need to operate on a vast scale as a non-profit. This is hard.
Here are some technical reasons. I’m sure others will chime in as there are likely many more.
some attacks on TLSv1.0 can compromise key material which is used for the newer, secure versions of TLS
providing a read-only version without login over HTTP shouldn’t really add any new code except they’d be on a HTTP-2-only webserver if I’m not mistaken.
But I hear all the time that I must ensure my personal site uses HTTPS and that soon browsers will refuse to connect to “insecure” sites. Isn’t this a good thing Wikipedia is doing? /s
I have HTTPS on my completely static website mostly so that no one asks why I don’t have HTTPS, but on the other hand, the “completely static” part is only relevant as long as there are only Eves in the middle and no Mallories.
If serving everything over HTTPS will make the life of ISPs injecting ads and similar entities harder, it’s a good thing, until there’s a legal rather than technical solution to that.
I actually think that HTTPS is reasonable for Wikipedia, if for nothing else to hinder 3rd parties for capture your embarrassing edits to “MLP: FIM erotica” and tracing it to back to you. For a static, read-only site it just adds cost and/or a potential point of failure.
Looking at Transport Layer Security Adoption it looks like the last version not supporting TLS1.2 for Chrome or Firefox is 6 years old and that the last Android not supporting it was Jelly Bean seven years ago. There are been some talks about deprecating both TLS1.0 and TLS1.1 in Google Chrome next year with the argument that less than 1% of connections are made using either of these. However, things as recent as Windows Vista does not support TLS1.2 but migration paths have been proposed, and at least 8% of Android devices seems to not have made the switch to something newer than Jelly Bean. It looks like two third of the internet is still accessible using TLS1.1 or TLS1.0 for now.
Are we sure that’s not only a deprecation warning?
It’s not, it does prevent access and definitely will prevent some users from accessing it, but it’s more user friendly than most SSL_ERROR_PROTOCOL_VERSION_ALERT I’m getting from other sites.
Windows Vista is some 13 years old now. Calling it “recent” isn’t intellectually honest when you’re putting it next to Android which powered the very first phone a year later than Vista launched.
I have an old Android phone that I found in a snowbank and was unable to return to the owner. It can’t access most of the web these days, precisely because of this. Or rather, precisely because the phone can’t be upgraded or even rooted.
It’s just an expensive brick now.
(My 8 year old laptop, on the other hand, works fine.)
Ensuring that eavesdroppers can’t tell what articles you are reading.
First of all, TIL. Didn’t realize https could the path and query params at all, but it totally makes sense. Neat!
Wouldn’t it be possible to gain some idea of what you’re reading based on the amount of data back-and-forth? Now I’m sitting here curious about how many articles have the exact same size for a given size category…. hmmm….
…most stuff has already adopted TLSv1.2? Wikipedia tries to maintain broadest compatibility possible, but even they seem to think the impact is minor to migrate.
I think it’s worth taking a step back from outrage and conspiracy theory mongering to consider what Wikipedia/Wikimedia actually recommends regarding this issue.
Upgrade to the latest version of Android that is possible for your device. Consider a device upgrade if your Android software cannot be upgraded to at least version 4.4, which was initially released by Google in 2013. Check the Play Store (or vendor-specific app store) to ensure you’ve installed the latest updates to core components and the browser (usually Chrome).
For whatever reason, Wikipedia/Wikimedia have made the decision that moving to HTTPS is in the best interests of its users, and those accessing the sites that run on Wikimedia software. Having made that decision, as one of the most visited sites on the internet, it behooves them to follow best practices regarding older encryption standards.
I think it’s entirely fair to deny access to user agents which are vulnerable to MITM attacks. While taking away access to a needed resource may in some ways harm the user, a much greater harm is thereby prevented in that the user cannot be presented with false information.
Yes, it’s harsh; and yes, that security notice could use some editing to highlight some examples of threats. However, in practice, I think it’ll do more good than harm.
I don’t know of any, but the tendency of politicians and organizations to doctor their own Wikipedia articles is well known. Who’s to say that they’ll stop there?
Using MITM attacks seems like quite a jump from editing your own Wikipedia page. Meanwhile, these measures have real measurable impact in people’s ability to access Wikipedia, especially from poorer populations.
There are other ways to serve poorer populations than to compromise security for everyone all at once. After all, it’s neither Wikipedia’s nor its users’ fault that device manufactures are leaving some percentage of their users in the lurch each year. Attack the problem there rather than so far downstream of the original sin.
Consider the “right to repair” movement: they’ve managed to have an impact even on Apple. Similar efforts should be pursuing a right to unlock, right to upgrade, and so on. Those are noble goals worth pursuing for everyone’s good, not a mass capitulation in the face of stubborn vendors who deliver abandonware by the container ship.
I’m not happy with the situation either, and I agree that it sucks that devices are left as “abandonware”. But it is what it is, and I think Wikipedia should deal with the “facts on the ground”, even if it’s stupid that the situation exists in the first place.
From your other comment:
Any weakening of such protocols directly serves the needs of those who are most threatened by public stores of knowledge like Wikipedia.
I don’t agree that security is compromised in a significant enough fashion in this case. You always need to balance several interests such as convenience, cost, freedom, etc. For example, many commonly sold locks can be lockpicked fairly easily even by untrained amateurs like me, and for the most part that’s a reasonable trade-off since high-quality locks are much expensive and are not a good ROI for most homes.
In this case, the risk seems very low to me, and the costs relatively high.
It is better to see nothing than to unknowingly read a planted falsehood.
While I appreciate the sentiment to some degree, this seems a bit too simplistic to me, as you can apply this to pretty much anything: books, newspapers, Wikipedia articles, etc. etc. can always contain “planted falsehoods”.
In the era of “fake news”, “fact-free politics”, and other blatant nonsense like anti-vaccination, there seem to be much bigger fish to fry than Wikipedia MITM attacks. On balance access to Wikipedia probably does more to combat blatant falsehoods than the very small chance of a MITM attack.
a much greater harm is thereby prevented in that the user cannot be presented with false information
Wow. I don’t even know how to respond to all these comments. You do realise this is Wikipedia we’re talking about, right?
A site where literally any user from anywhere in the world, from any of those countries posing the “greatest threat” to the Western democracies, can go and edit pretty much any page at any time, inserting or deleting anything they please?!
Yet everyone is so happy that the “greater harm” of “false information” is being prevented by not letting anyone in the middle of Texas or East Midland read Wikipedia on their old Android and iOS devices?! Seriously?
I don’t know if there’s a point of return from this level of absurdity for our whole industry. Can security theatre get any more ridiculous than this?
Edits to Wikipedia articles are publicly visible, and that’s exactly how self-aggrandizing and whitewashing edits are usually caught. Imagine now a user who is entirely at the mercy of any number of middle parties who don’t even need to bother with edits to the centrally hosted and publicly visible Wikipedia. The site no longer needs to be blocked; an alternate reality can be constructed much more easily, and entirely out of view.
This isn’t security theatre. TLS and similar protocols exist specifically to enable a client (as well as server, if desired) to not only ensure privacy of communications, but to ensure the very authenticity of content. Any weakening of such protocols directly serves the needs of those who are most threatened by public stores of knowledge like Wikipedia. It is better to see nothing than to unknowingly read a planted falsehood.
Tldr removing support for TLSv1.0 and TLSv1.1
Yes, just the open encyclopaedia that lets any user with any IP address to edit any page for any reason, without even having to bother to create an account beforehand, or provide any identifying information other than the IP address assigned by their ISP itself.
Blocking even read-only access, unless a TLSv1.2 or newer device is used (plain-text HTTP access has been blocked a while ago as well).
tl;dr: This would notably block Wikipedia access for many Android and iOS devices — you can no longer use those devices to even read Wikipedia. Yes, if you buy a new device, you can edit any page; but if you have an old device, you can’t even read any of them. Is this a technology limitation? No, it’s pure politics, and www.google.com still works without https, BTW (might depend on your browser).
An excellent point about Google.
For Floodgap, since I specialize in old computers and I enjoy it when people access it with old machines, while TLSv1.2 is available and you can facultatively enable HSTS, I’m not going to remove unencrypted HTTP access.
I think for a certain class of very geriatric machine Gopher is a better option, though.
Maybe some folk don’t understand what’s going on here, but this is in direction violation of Postel’s law:
They’re blocking access from old devices for absolutely no technical reason; they’re blocking read-only access from folks that might not have any other devices at their disposal.
If you have an old iPod lying around, why on earth should you not be able to read Wikipedia on it? Absolutely no valid technical reason to deny access. Zilch. None. Nada.
There’s no reason it shouldn’t be possible to read Wikipedia over straight HTTP, for that matter.
I know next to nothing about security so correct me if I’m wrong, but doesn’t leaving old protocols enabled make users vulnerable to downgrade attacks?
You’re applying bank-level security to something that’s public information and should be accessible to everyone without a licence or access control in the first place. I don’t even know what sort of comparison to make here best, because in my view requiring HTTPS in the first place here was a misguided decision that’s based on politics, corporate interests and fear, not on rational facts. Postel’s law is also a well-known course of action in telecommunication, even Google still follows it — www.google.com still works just fine over straight HTTP, as does Bing, no TLS mandated from those who don’t want it.
I agree with you, I’d like to be able to access Wikipedia with HTTP, but this is in my opinion a different issue from disabling old encryption protocols.
Accessing Wikipedia with secure and up to date protocols might not be necessary to you but it might be for people who live under totalitarian regimes. One could argue that said regimes have better ways to snoop on their victims (DNS tracking, replacing all certificates with one they own…) but I still believe that if enforcing the use of recent TLS versions can save even a single life, this is a measure worth taking. It would be interesting to know if Wikipedia has data on how much it is used by people living in dictatorships and how much dropping old TLS versions would help these people.
It’s funny you mention it, because this actually would not be a problem under a totalitarian regime with a masquerading proxy and a
block returnpolicy for the https port and/or their own certificates and a certificate authority. See https://www.xkcd.com/538/.Also, are you suggesting that Wikipedia is basically blocking my access for my own good, even though it’s highly disruptive to me, and goes against my own self-interests? Yet they tell me it is in my own interest that my access is blocked? Isn’t that exactly what a totalitarian regime would do? Do you not find any sort of an irony in this situation?
“Isn’t that exactly what a totalitarian regime would do?”
I think you may have overstated your case here.
Yes, this is what I meant when I wrote “One could argue that said regimes have better ways to snoop on their victims”.
No, here’s what I’m suggesting: there are Wikipedia users who live in countries where they could be thrown in jail/executed because of pages they read on Wikipedia. These users are not necessarily technical, do not know what a downgrade attack is and this could cost them their lives. Wikipedia admins feel they have a moral obligation to do everything they can to protect their lives, including preventing them from accessing Wikipedia if necessary. This is a price they are willing to pay even if it means making Wikipedia less convenient/impossible to use for other users.
If they left http, yeah, sure. But I don’t think any attack that downgrades ssl encryption method exists, both parties always connect using the best they have. If there exists one, please let me know.
There is no technical reason I’m aware of. Why does wikipedia do this? It’s not like I need strong encryption to begin with, I just want to read something on the internet.
I still have usable, working smartphone with android Gingerbread, it’s the first smartphone I ever used. It’s still working flawlessly and I’m using it sometimes when I want to quickly find something when my current phone has no battery and I don’t want to turn on my computer.
This move will for no reason kill my perfectly working smartphone.
Downgrade attacks are possible with older versions of SSL e.g. https://www.ssl.com/article/deprecating-early-tls/
Which exact page you’re looking at may be of interest, e.g. if you’re reading up on medical stuff.
Are you suggesting that we implement access control in public libraries, so that noone can browse or checkout any books without strict supervision, approvals and logging by some central authority? (Kinda like 1984?)
Actually, are you suggesting that people do medical research and trust information from Wikipedia, literally edited by anonymous people on the internet?! HowDareYou.gif. Arguably, this is the most misguided security initiative in existence if thought of in this way; per my records, my original accounts on Wikipedia were created before they even had support for any TLS at all; which is not to say it’s not needed at all, just that it shouldn’t be a mandatory requirement, especially for read-only access.
P.S. BTW, Jimmy_Wales just responded to my concerns — https://twitter.com/jimmy_wales/status/1211961181260394496.
I’m saying that you may not wish other people to infer what medical conditions you may have based on your Wikipedia usage. So TLS as the default is desirable here, but whether it should be mandatory is another question.
PSST, public libraries in the western world already do this to some extent. Some countries are more central than others thanks to the US PATRIOT Act.
Not my experience at all; some private-university-run libraries do require ID for entry; but most city-, county- and state-run libraries still allow free entry without having to identify yourself in any way. This sometimes even extends to making study-room reservations (can often be made under any name) and anonymous computer use, too.
It’s not working flawlessly, the old crypto protocols and algorithms it uses have been recalled like a Takata airbag, and you’re holding on because it hasn’t blown up in your face yet.
(my emphasis)
So you just use this phone to access Wikipedia, and use it for nothing else?
If so, that’s unfortunate, but your ire should be directed to the smartphone OS vendor for not providing needed updates to encryption protocols.
I think it’s pretty clear that the user does not need encryption in this use-case, so, I don’t see any reason to complain to the OS vendor about encryption when you don’t want to be using any encryption in the first place. Like, seriously, what sort of arguments are these? Maybe it’s time to let go of the politics in tech, and provide technical solutions to technical problems?
As per my comment, I do believe that the authentication provisions of TLS are applicable to Wikipedia.
Besides, the absolute outrage if WP had not offered HTTPS would be way bigger than now.
I find the connection to Postel’s law only weak here, but in any case: This is the worst argument you could make.
It’s pretty much consensus among security professionals these days that Postel’s law is a really bad idea: https://tools.ietf.org/html/draft-iab-protocol-maintenance-04
I don’t think what passes for “postel’s law” is what Postel meant, anyway.
AFAICT, Postel wasn’t thinking about violations at all, he was thinking about border conditions etc. He was the RFC editor, he didn’t want anyone to ignore the RFCs, he wanted them to be simple and easy to read. So he wrote “where the maximum line length is 65” and meant 65. He omitted “plus CRLF” or “including CRLF” because too many dotted i’s makes the prose heavy, so you ought to be liberal in what you accept and conservative in what you generate. But when he wrote 65, he didn’t intend the readers to inter “accept lines as long as RAM will allow”.
https://rant.gulbrandsen.priv.no/postel-principle is the same argument, perhaps better put.
IMO this is another case of someone wise saying something wise, being misunderstood, and the misunderstanding being a great deal less wise.
I can’t really understand advocating laws around protocols except for “the protocol is the law”. Maybe you had to be there at the time.
As I understand it, they’re protecting one set of users from a class of attack by disabling support for some crypto methods. That seems very far from “absolutely no technical reason”.
As for HTTP, if that were available, countries like Turkey would be able to block Wikipedia on a per-particle basis, and/or surveil its citizens on a per-article basis. With HTTPS-only, such countries have to open/close Wikipedia in toto, and cannot surveil page-level details. Is that “no reason”?
I don’t understand why people think this is an acceptable argument for blocking HTTP. It reminds me of that jealous spouse scenario where someone promises to inflict harm, either to themselves or to their partner, should the partner decide to leave the relationship. “I’ll do harm if you censor me!”
So, Turkey wants to block Wikipedia on a per-article business? That’s their decision, and they’ll go about it one way or another, I’m sure the politicians they don’t particularly care about the tech involved anyways (and again, it’s trivial for any determined entity to block port 443, and do a masquerade proxy on port 80, and if this is done on all internet connections within the country, it’ll work rather flawlessly, and noone would know any better). So, it’s basically hardly a deterrent for Turkey anyways. Why are you waging your regime-change wars on my behalf?
Well, Wikipedia is a political project, in much the same way that Stack Overflow is. The people who write have opinions on whether their writings should be available to people who want to read.
You may not care particularly whether all of or just some of the information on either Wikipedia or SO are available to all Turks, but the people who wrote that care more, of course. They wouldn’t spend time writing if they didn’t care, right? To these people, wanting to suppress information about the Turkish genocide of 1915 is an affront.
So moving to HTTPS makes sense to them. That way, the Turkish government has to choose between
The Wikipedians are betting that the second option is unpopular with the Turks.
It’s inconvenient for old ipad users, but if you ask the people who spend time writing, I’m sure they’ll say that being able to read about your country’s genocide at all is vastly more important than being able to read using old ipads.
I can think of several reasons:
So what’s to stop a totalitarian regime from doing the following?
The difficulty is to setup/enrole TotallyLegitCA. How do you do that? If TotallyLegitCA is public, the transparency log will quickly reveal what they are doing. The only way to pull that seems to force people to have your CA installed, like Kazakhstan is doing.
We’re talking about a totalitarian regime (or you know, your standard corporation who install their own CA in the browser).
That’s actually incorrect. There are various technical reasons. But also remember that they need to operate on a vast scale as a non-profit. This is hard.
Here are some technical reasons. I’m sure others will chime in as there are likely many more.
providing a read-only version without login over HTTP shouldn’t really add any new code except they’d be on a HTTP-2-only webserver if I’m not mistaken.
There are arguments for an inverse-postel’s law given in https://m.youtube.com/watch?v=_mE_JmwFi1Y
But I hear all the time that I must ensure my personal site uses HTTPS and that soon browsers will refuse to connect to “insecure” sites. Isn’t this a good thing Wikipedia is doing? /s
Edit also see this discussion: https://lobste.rs/s/xltmol/this_page_is_designed_last#c_keojc6
I have HTTPS on my completely static website mostly so that no one asks why I don’t have HTTPS, but on the other hand, the “completely static” part is only relevant as long as there are only Eves in the middle and no Mallories.
If serving everything over HTTPS will make the life of ISPs injecting ads and similar entities harder, it’s a good thing, until there’s a legal rather than technical solution to that.
I actually think that HTTPS is reasonable for Wikipedia, if for nothing else to hinder 3rd parties for capture your embarrassing edits to “MLP: FIM erotica” and tracing it to back to you. For a static, read-only site it just adds cost and/or a potential point of failure.
dmbaturin just said what the value add is. HTTPS prevents third parties from modifying the content of your static site.
Looking at Transport Layer Security Adoption it looks like the last version not supporting TLS1.2 for Chrome or Firefox is 6 years old and that the last Android not supporting it was Jelly Bean seven years ago. There are been some talks about deprecating both TLS1.0 and TLS1.1 in Google Chrome next year with the argument that less than 1% of connections are made using either of these. However, things as recent as Windows Vista does not support TLS1.2 but migration paths have been proposed, and at least 8% of Android devices seems to not have made the switch to something newer than Jelly Bean. It looks like two third of the internet is still accessible using TLS1.1 or TLS1.0 for now.
Are we sure that’s not only a deprecation warning?
It’s not, it does prevent access and definitely will prevent some users from accessing it, but it’s more user friendly than most SSL_ERROR_PROTOCOL_VERSION_ALERT I’m getting from other sites.
Windows Vista is some 13 years old now. Calling it “recent” isn’t intellectually honest when you’re putting it next to Android which powered the very first phone a year later than Vista launched.
You’re right, seems I’m getting older and didn’t remembered that Vista was, in fact, not recent at all.
I have an old Android phone that I found in a snowbank and was unable to return to the owner. It can’t access most of the web these days, precisely because of this. Or rather, precisely because the phone can’t be upgraded or even rooted.
It’s just an expensive brick now.
(My 8 year old laptop, on the other hand, works fine.)
They are getting a bunch of flack. There’s two things at play here. The first is that wikipedia is public information, not secret.
But there are two big use cases for requiring strong encryption:
First of all, TIL. Didn’t realize https could the path and query params at all, but it totally makes sense. Neat!
Wouldn’t it be possible to gain some idea of what you’re reading based on the amount of data back-and-forth? Now I’m sitting here curious about how many articles have the exact same size for a given size category…. hmmm….
…most stuff has already adopted TLSv1.2? Wikipedia tries to maintain broadest compatibility possible, but even they seem to think the impact is minor to migrate.
I think it’s worth taking a step back from outrage and conspiracy theory mongering to consider what Wikipedia/Wikimedia actually recommends regarding this issue.
Here’s Wikipedia’s announcement about moving to HTTPS (from 2015): https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/
Here’s Wikimedia’s browser recommendations (published in 2016, updated 17 Aug 2017): https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations
For whatever reason, Wikipedia/Wikimedia have made the decision that moving to HTTPS is in the best interests of its users, and those accessing the sites that run on Wikimedia software. Having made that decision, as one of the most visited sites on the internet, it behooves them to follow best practices regarding older encryption standards.
I think it’s entirely fair to deny access to user agents which are vulnerable to MITM attacks. While taking away access to a needed resource may in some ways harm the user, a much greater harm is thereby prevented in that the user cannot be presented with false information.
Yes, it’s harsh; and yes, that security notice could use some editing to highlight some examples of threats. However, in practice, I think it’ll do more good than harm.
Are there documented cases of this happening?
I don’t know of any, but the tendency of politicians and organizations to doctor their own Wikipedia articles is well known. Who’s to say that they’ll stop there?
Using MITM attacks seems like quite a jump from editing your own Wikipedia page. Meanwhile, these measures have real measurable impact in people’s ability to access Wikipedia, especially from poorer populations.
There are other ways to serve poorer populations than to compromise security for everyone all at once. After all, it’s neither Wikipedia’s nor its users’ fault that device manufactures are leaving some percentage of their users in the lurch each year. Attack the problem there rather than so far downstream of the original sin.
Consider the “right to repair” movement: they’ve managed to have an impact even on Apple. Similar efforts should be pursuing a right to unlock, right to upgrade, and so on. Those are noble goals worth pursuing for everyone’s good, not a mass capitulation in the face of stubborn vendors who deliver abandonware by the container ship.
I’m not happy with the situation either, and I agree that it sucks that devices are left as “abandonware”. But it is what it is, and I think Wikipedia should deal with the “facts on the ground”, even if it’s stupid that the situation exists in the first place.
From your other comment:
I don’t agree that security is compromised in a significant enough fashion in this case. You always need to balance several interests such as convenience, cost, freedom, etc. For example, many commonly sold locks can be lockpicked fairly easily even by untrained amateurs like me, and for the most part that’s a reasonable trade-off since high-quality locks are much expensive and are not a good ROI for most homes.
In this case, the risk seems very low to me, and the costs relatively high.
While I appreciate the sentiment to some degree, this seems a bit too simplistic to me, as you can apply this to pretty much anything: books, newspapers, Wikipedia articles, etc. etc. can always contain “planted falsehoods”.
In the era of “fake news”, “fact-free politics”, and other blatant nonsense like anti-vaccination, there seem to be much bigger fish to fry than Wikipedia MITM attacks. On balance access to Wikipedia probably does more to combat blatant falsehoods than the very small chance of a MITM attack.
Wow. I don’t even know how to respond to all these comments. You do realise this is Wikipedia we’re talking about, right?
A site where literally any user from anywhere in the world, from any of those countries posing the “greatest threat” to the Western democracies, can go and edit pretty much any page at any time, inserting or deleting anything they please?!
Yet everyone is so happy that the “greater harm” of “false information” is being prevented by not letting anyone in the middle of Texas or East Midland read Wikipedia on their old Android and iOS devices?! Seriously?
I don’t know if there’s a point of return from this level of absurdity for our whole industry. Can security theatre get any more ridiculous than this?
Edits to Wikipedia articles are publicly visible, and that’s exactly how self-aggrandizing and whitewashing edits are usually caught. Imagine now a user who is entirely at the mercy of any number of middle parties who don’t even need to bother with edits to the centrally hosted and publicly visible Wikipedia. The site no longer needs to be blocked; an alternate reality can be constructed much more easily, and entirely out of view.
This isn’t security theatre. TLS and similar protocols exist specifically to enable a client (as well as server, if desired) to not only ensure privacy of communications, but to ensure the very authenticity of content. Any weakening of such protocols directly serves the needs of those who are most threatened by public stores of knowledge like Wikipedia. It is better to see nothing than to unknowingly read a planted falsehood.