Page MenuHomePhabricator

Wikipedia no longer accessible to those using some braille devices
Closed, InvalidPublic


Hello I received an OTRS ticket #2018011810011213 in which the subject states their braille device is no longer able to access Wikipedia. I have received the user's permission to share non identifying information to open this ticket.

The device is a "Braille Sense U2", this device still sold uses Windows CE/IE 6. Per the user the manufacturer does not make new applications for the device. Further this has been occurring since late last year. I'm betting its probably related to dropping support for older browsers.

The user has also tried accessing the mobile site with the same error.

Event Timeline

Cameron11598 renamed this task from Wikipedia no longer accessible to those using braille devices. to Wikipedia & braille devices. .Jan 23 2018, 4:05 PM
Cameron11598 updated the task description. (Show Details)
Cameron11598 renamed this task from Wikipedia & braille devices. to Wikipedia no longer accessible to those using some braille devices.Jan 23 2018, 4:16 PM

The user has also tried accessing the mobile site with the same error.

Which error? You haven't detailed any error....

IE6 should work, without most of the JS things...

I'll follow up and see if I can get a more detailed error message.

Here is the information on the error;

when I go to access Wikipedia I get the error message

"An error occurred in the secure channel support. Error 12157.
Connection Failed. Check Network Status"

This message comes up when I use my Braille Sense notetaker to go to any
site the browser cannot access.

Until November 2017 I was able to access Wikipedia, and then I got a
message to update my browser. I believe this message stopped around 17
November 2017.

matmarex added a subscriber: matmarex.

MediaWiki still has basic support for IE 6, but I think Wikipedia no longer allows IE 6 to connect to it, due to some HTTPS cipher thing.

They actually were receiving a different error and were just able to locate it.

"Browser Connection Security Issues
Your Browser's Connection Security is Outdated
English: Wikipedia does not work with Internet Explorer 8 on Windows XP. Please use a new
operating system or use
Firefox 52 ESR

They might be able to improve the situation by changing the SSL certificates.

Beyond that, there's not much we can do, it's on the vendor of the device

I can confirm that our current SSL settings do not work with IE8 on windows XP. This is due to inherent limitations in windows XP cryptography being dramatically outdated and making browsing inherently insecure for its users. Moreover, supporting it would expose all visitors to some attacks that have been solved in more modern cryptographic settings. I'll let someone from the Traffic team comment further on the issue, but the recommendation would be to either user Firefox, or move to a more updated (and currently supported) operating system.

If that's not possible, as the original ticket suggests, I'm not sure what can we suggest to the user, besides updating their device.

@Cameron11598 I couldn't find on the product page for that device any information on the OS/browser it's using. I see there is a recent firmware update which is supposed to support facebook/youtube; did we ask the user if the device is fully updated?

This won't actually help. SSL 1,2 and 3 are known to be completely broken and are disabled across most of the major websites.

@Joe There's a product specification page (I linked another article I've found but wanted to link this resource) on the device showing it uses Windows CE 6.0.

I've thrown a tweet at HIMS Inc. Maybe they can help.

I doubt we can do anything from our side. Windows CE is pretty dated.

Thanks @TheDJ – I've also sent them an email about the cause with request for participation on this task.

If it's running CE 6.0... I bet it's basically going to be a case of "the OS doesn't support it, buy new hardware"

Mainstream support for it ended in 2013..

Extended support ends this april. But I doubt Microsoft will magically deliver a next gen ssl encryption (though they did for lots of other ancient windows stuff).

Hmm, this seems interesting: Modern HTTP and HTTPS .NET library for legacy systems..

Not sure what's possible in terms of rewriting and updating the software of that braille reader, but this does look like it might be able to help them out on some fronts. Sort of depends on if they rely completely on CE's IE6 or not...

From the Traffic perspective, to recap and clarify some of the bits above from the general/broad perspective:

  • Yes, this is definitely because of deliberate actions on our end to remove support for the DES-CBC3-SHA TLS cipher late last year, which is covered in more detail in T147199 and T163251 . There were intermittent warnings to affected users over a period of months at increasing frequency, culminating in 100% pageview replacement with the warning notice circa Oct 17th (effectively, no real service possible), and then the removal of low-level support on Nov 17th, which replaced the friendlier warning from us with the local connection failure message from the UA observed today.
  • Our focus in terms of affected users was IE-on-Windows-XP users, as these were the bulk of the affected users, and thus our upgrade advice in the warning was mostly targeted at that specific case. There was some recognition that there would also be a long tail of other legacy UAs which would also be affected, and that we wouldn't be able to enumerate all possible cases.
  • This particular case is really unfortunate, and I do want to apologize on our behalf that we didn't foresee this legacy braille reader issue that may be difficult to upgrade or replace. I don't think it would have changed our plans, but perhaps we could/should have tried to identify and support these users better ahead of the change by providing some technical support and guidance on user-side upgrade or workaround paths ahead of the change, or pushed on the vendors where we could perhaps advocate more-technical solutions.

In general, I would advise that these sorts of legacy UA compatibility issues are only going to get worse, not better, on the Internet during 2018, and continuing to use unpatched, legacy, insecure UAs is not a good proposition for users, and thus not a good one for the users' vendors, either. There's a looming deadline coming on June 30th, 2018 from PCI-DSS which will force all websites which process credit cards to drop support for TLSv1.0 in order to maintain compliance, and even as we speak various sites are slowly falling into compliance ahead of the hard deadline.

The requirement to drop TLSv1.0 support is an even stronger requirement (in terms of the exclusion of classes of legacy UAs) than our 3DES change. Our wiki sites don't process payments and thus aren't subject to this deadline, but we can expect the bulk of the commercial Internet to follow this standard and thus these UAs will become increasingly broken by the cutoff date and rare for users to continue using. We'll be monitoring the dropoff in TLSv1.0 usage through the middle of this year to determine our own reasonable timeframe for dropping support, but I expect our cutoff will also end up being sometime during 2018.

As far as actual advice on fixes or workarounds for this particular case:

  • The user interface and user modifiability for this device seems pretty limited, so I'm not sure there will be reasonable solutions the user can implement on the device themselves to install or modify software to fix this.
  • It's definitely worth pursuing whether the user has applied all available software upgrades, and/or whether the vendor can provide additional new software upgrades that help here. If the vendor's looking at new fixes, I'd suggest to them they shouldn't limit themselves to just supporting newer ciphers (to work around this present issue with Wikipedia specifically), but instead find a solution that also supports forward-secret ciphers and TLSv1.2 (or at least, 1.1). Otherwise as outlined above the users will continue to suffer increasing problems like these with various sites around the Internet going forward, and eventually with us again as well by the end of the year.
  • If no vendor solution is possible, probably the next-best bet would be a proxy solution. On a technical level, some other computer, device, or router on the user's home network could act as a trusted proxy which speaks modern TLS to the rest of the internet, and speaks legacy broken HTTPS (or even, unencrypted HTTP) to the Braille reader. There are several free and/or cheap commercial bits of software and hardware out there which can perform this function, but there's probably a lot of support-level details to work out here about this user's particular network setup and what work would best for them and how to configure it.

@Cameron11598 Could you forward Brandon's answer above to the original reporter? Let us know if there is any feedback from him. As i see it now i think that reply is the best we can offer in this case and there isn't much else on this ticket that is really actionable on our end.

Dzahn triaged this task as Medium priority.Feb 1 2018, 11:49 PM
TheDJ closed this task as Invalid.EditedFeb 5 2018, 4:17 PM

I'm hereby closing this ticket as invalid (works as intended), as the communication loop has been closed, we are not likely to revert to a state that will make the device work, we have offered the help we can etc.. Nothing left to do here. But if anyone still has a question, we will be happy to answer of course.

Thanks for helping out @Cameron11598 , these ARE important issues to file, even if we cannot always solve them, we can document the reasons and possible workarounds for users and vendors alike.

Just for completion, I haven't heard back from the company for the last two weeks on the email request.

@TheDJ No problem! I think accessibility is important so I tend to grab these tickets when I see them. @Volker_E thanks for the update.