Microsoft, keep your hands off my keyboard!

The keyboards connected to our computers are essential to controlling every aspect of our computer experience, and to our communications with everybody we communicate with. A very basic aspect of the keyboard, and of our personal choice (it is really a major aspect of our national identity), is the layout of the keys. In my case, I am using a keyboard with a Norwegian layout, which is essential when writing text in my native Norwegian language.

What happens when someone, or something, changes how the keyboard is working?

About a year and a half ago I started working on a Windows 10 machine at work (having used Windows 7 until then), but after I while I started running into a particularly obnoxious problem: The keyboard layout would, occasionally, automatically be changed to the US layout, instead of my Norwegian layout.

For somebody who is reasonably competent at typing without looking on a Norwegian keyboard (aka. the “Touch” method), that is rather irritating, because keys like “<“, “:”, “-“, “æ”, “ø”, and “å” suddenly produce completely different characters. The result is a disruption of my current activities.

After some searching I discovered this thread about it, started in 2016 (and still active), and there are indications in the thread’s references that the problem first appeared in Windows 8, at least as early as 2012, maybe 2011.

Based on information in the thread and its references, what seems to be happening is that Windows 10, being “concerned” that the user’s configuration might not be correct in the context of his or her environment, scans the other Windows 10 machines on the network, or obtains information from computers it connect to, and possibly other information, such as the machine’s geographical location, and automatically reconfigures the enabled keyboard layout based on this information.

I do not know if this is correct, but the name of a registry value mentioned in this information, “IgnoreRemoteKeyboardLayout”, indicates that there may be something to it.

This problem seems to have been affecting many users from non-English
speaking countries, especially those working in multilingual, global companies, or those having moved to a different country.

In Vivaldi, I work with colleagues from many countries and we are all using different keyboard layouts, including German, Icelandic, and US layouts.

The thread I found discusses various workarounds, some of them requiring
you to edit the registry (one of which I used to fix my problems), which is something the average user should never be required to do.

Recently, though, I have run into this again with my personal laptop, and as far as I can tell the workarounds are not just not working anymore, it seems
that the workarounds I did apply earlier were removed somehow, possibly by the recent major Windows 10 update.

The keyboard layout of my laptop keeps changing to the US layout several times a day, even several times an hour. In fact, I have had it happen in the middle of writing emails!

And what is happening to my laptop is not an isolated case: One of my colleagues has reported the same thing has started happening to his laptop, too.

So, I think Microsoft is being too “helpful” in this case.

I have configured my PCs the way I want them configured, with the UI language I want, and the keyboard layout I want to use, and I did so when I installed Windows on the PC, and I have no plans to change them.

Microsoft, keep your hands off my keyboard!

 

Update June 24: The jury is still out on this, but a couple of days ago I decided to try two changes: I removed all the extra languages and keyboard layout combinations (again), and also disabled the keyboard shortcuts for switching between these settings.

If this continues to work, it may have “solved” my problem.

However, it is still a “solution” for a problem that should never have existed, the automagic addition of languages and keyboard layouts, and it may be that the workaround only hides the issue.

It also points to what I think is a bad design choice by Microsoft: The choices for the keyboard shortcuts are Ctrl+Shift and Left Alt+Shift (never mind that Norwegian keyboards only have one Alt key, the left one; the other is the AltGr key that is an alias for Alt+Ctrl, used to type various characters like “@”, “{“, and “€”). Both of these shortcuts are used as part of various keyboard shortcuts, and the Alt+Shift key variation is part of the “Switch to previous Application” shortcut Alt+Shift+Tab. What happens if you start to press this shortcut, and decides to not change application after the first two keys are pressed? That’s right: The keyboard layout changes!

And even if these two actions “solved” the problem, it should never have been an issue for my systems, since I never added extra languages or keyboards. Microsoft added them without asking, then a bad choice of keyboard shortcuts exacerbated the problem.

And users that, for various reasons, do have multiple languages and/or layouts enabled, may still be having problems.

Update June 27: After rebooting the laptop, the US layout returned, despite having been manually removed, and the keyboard shortcuts being disabled.

Secure online X-mas shopping? Big stores encrypt, the corner-store doesn’t

Encryption usage by Norwegian online shopping sites (2016 edition)

Over the past several years I have performed occasional surveys of Norwegian shopping sites and their use of encryption. I decided to limit my surveys to Norway, because I concluded that limited knowledge would make collecting a representative international list of foreign shopping sites difficult, and would probably only contain large stores, not small ones.

The last survey I wrote about was performed in early 2015, and while I did not publish an article about it, I did perform a second survey a few months later, in order to get an impression of the effects of some actions initiated after my article. The changes at the time were not significant enough to change what I presented in the previous article, so I did not publish an article discussing those updated results. Continue reading “Secure online X-mas shopping? Big stores encrypt, the corner-store doesn’t”

There are more POODLEs in the forest

In December it was announced that several TLS server implementations were affected by a problem similar to an SSL v3 issue called POODLE disclosed by Google researchers in October. This attack worked by modifying the padding bytes of the encrypted SSL/TLS records that are used to make the records into even multiples of 8 or 16 byte blocks of data, checking how the server responded, and used this to deduce the plain text of the transmitted data, one byte at a time, with just a few tries.

Several major vendors were affected by the TLS variant of the POODLE issue, and released patches. Continue reading “There are more POODLEs in the forest”

The POODLE has friends

In October last year, researchers from Google published details about an attack on SSL v3, called POODLE. This attack worked by modifying the padding bytes of the encrypted SSL records that are used to make the records into even multiples of 8 or 16 byte blocks of data, as used by 3DES and AES encryption in the “CBC” mode, checking how the server responded, and used this to deduce the plain text of the transmitted data, one byte at a time, with just a few tries. Continue reading “The POODLE has friends”

Usikker registrering av persondata i mange nettbutikker

[Apologies to my English language readers, as this article mainly concerns encryption in Norwegian online shopping sites, I decided to write it in Norwegian]

Jeg har ved at par tidligere anledninger undersøkt bruken av kryptering av norske nettbutikker, sist i 2013. Konklusjonen begge ganger har vært at kryptering er lite brukt.

I løpet av januar gjennomførte jeg en ny undersøkelse av kryptering i norske nettbutikker. I tillegg til 59 butikker jeg hadde undersøkt tidligere, inkluderte jeg denne gangen 184 nye nettbutikker fra Posten.no‘s liste over nettbutikker, totalt 243 butikker.  Continue reading “Usikker registrering av persondata i mange nettbutikker”

A possible reason why many e-commerce sites do not use encryption?

If you have read my past articles, you may have noticed that I am a little annoyed by the low number of e-commerce sites using HTTPS encryption to protect their customers. While most do use encryption for payments, usually that is because they use the services of a payment processor, and because using encryption for the payment info submission pages is required by the credit card companies. As far as I can tell, very few e-commerce sites use encryption for displaying the shopping cart, collecting customer information about name and address, or the customer login, although I have an impression that larger e-commerce companies are better at this than smaller ones. Continue reading “A possible reason why many e-commerce sites do not use encryption?”

Not out of the woods yet: There are more POODLEs

As I wrote in my previous article about this, in October a group of Google security researchers had discovered a problem, called POODLE, in SSL v3 that in combination with another issue, browsers’ automatic fallback to older TLS and SSL versions, allowed an attacker to quickly break the encryption of sensitive content, like cookies.

The main mitigating methods for this problem are disabling SSL v3 support, both server side (now down to 66.2%, but slowing down) and in the client, and to limit the automatic fallback, either by not falling back to SSL v3 (which is now implemented by several browsers), or by a new method called TLS_FALLBACK_SCSV (introduced by Google Chrome and others). Continue reading “Not out of the woods yet: There are more POODLEs”

Attack of the POODLEs

Three weeks ago a group of researchers from Google announced an attack against the SSL v3 protocol (the ancestor of the TLS 1.x protocol) called POODLE (a stylish abbreviation of “Padding Oracle On Downgraded Legacy Encryption”). This attack is similar to the BEAST attack that was revealed a few years ago, and one of the researchers that found the POODLE attack was part of the team that found BEAST.

POODLE is able to quickly discover the content of a HTTPS request, such as a session cookie, but only if the connection is using the SSL v3 protocol, a version of SSL/TLS that became obsolete with the introduction of TLS 1.0 in 1999. As almost all (>99%) secure web servers now support at least TLS 1.0 (which is not vulnerable to the attack, provided the server is correctly implemented), it might sound like this attack is not very useful. Unfortunately, that is not so. Continue reading “Attack of the POODLEs”

What is tls-testing.tlsprober.net?

Executive summary: The TLS Prober is a tool that gathers information and statistics about the state of the SSL/TLS protocol security features and vulnerabilities across the internet. It does nothing that will harm your server.

The TLS Prober is a tool I developed while I worked I worked at Opera Software, originally to track the progress of the TLS Renego problem, and which I was allowed to take with me when I left Opera in early 2013. It is primarily used to scan a set of 23 million hostnames, most of the names derived from Alexa top million domain names, resulting in tests of about 500000 unique servers, for their support of SSL and TLS features, as well as checking for various interoperability issues and vulnerabilities.

Similar tools are also in use by others, such as the Qualys SSL Labs prober. Continue reading “What is tls-testing.tlsprober.net?”

The OpenSSL CCS vulnerability

Last week, news arrived about a new vulnerability in OpenSSL, which affected all releases of the library. This new vulnerability, frequently referred to as the CCS vulnerability, is a Man In the Middle (MITM) vulnerability, allowing an attacker to listen in on, or modify data on a connection by tricking the client and server to set up their connection using predictable encryption keys. Continue reading “The OpenSSL CCS vulnerability”