Disabling WiFi Sense on WiFi in Windows 10

There has been a lot of hullabaloo over Window 10’s WiFi Sense capability. If you aren’t familiar with it, here is ArsTechnica’s definition by Sebastian Anthony:

Windows 10 comes with a neat new feature called Wi-Fi Sense, which lets your PC automatically connect to Wi-Fi networks that your friends and acquaintances have previously connected to, even if you don’t know the network password. — Sebastian Anthony, ArsTechnica

I recommend you read Ars’s write up, it’s a fair and practical argument for why it should be left alone, and that it isn’t such a big deal. Indeed, many people make good arguments to why its a reasonable thing and people shouldn’t be freaking out about it. People have also told me that devices on a network using WiFi Sense can’t access devices on the network, just the default gateway for internet access.

There is only one suitable option for completely disabling it for an entire network: suffix your SSID with “_optout”:

If you run a Wi-Fi network and you want to prevent Windows 10 (or Windows Phone) users from sharing the passkey via Wi-Fi Sense, you can add _optout to the end of the network SSID. — Sebastian Anthony, ArsTechnica

Given all of the arguments as to why it’s a good thing, that it’s secure and all, I am still going to add the _optout to my network.

This isn’t any dig at Microsoft. Microsoft has some really, really smart people there especially security conscience ones. If it were Apple or Google, I would do the same (and I have for other services).

It’s something I just don’t need. Any practical security minded person would tell you, “If you don’t need something, turn it off”. Windows Server has been doing this for years with Roles and Features. One of the primary reasons Windows Server doesn’t come with everything enabled out of the box is so that only features which are actually installed need to be patched. This is one of the reasons I think Windows Nano is fantastic, and is summed up well in this tweet about what Jeff Snover said during MSIgnite:

@nanoserver One 10th the critical patches, dramatically increased security. VHD size 410Mbytes, almost 20 times smaller @jsnover #MSIgnite - @JeffreySchwartz

My point is this: if you won’t use it, turn it off. People can think of really creative vulnerabilities. There are still many concerns that I do have.

Devices that are on a WiFi network via WiFi Sense don’t get access to the whole network, just the default gateway (router in most cases) for internet access, and that is all. So even if WiFi Sense were misused, no one would get access to devices on my network, right? I don’t think so. Consumer router manufactures do a laughable job at security. Who knows what else will turn up. Even if you keep your router patched, there are probably dozens more left to be discovered.

Small businesses are in a bit of a tight spot, too. Most don’t deploy WPA2 Enterprise, they just use their ISPs router with built-in WiFi, or maybe they have a few APs they got from Best Buy, added a WPA2 PSK password, and moved on. How does a small business stop employees from doing this? I’m sure Group Policy can do it (which many small business also don’t deploy), but since WiFi Sense is on Windows Phone, and with BYOD on the rise (both with phones and laptops), it’s only a matter of time before someone uses the company’s WiFi with WiFi Sense.

Even more concerning is this is becoming a convention. Google famously collects information about WiFi SSIDs its streetcars sees. If you don’t want them doing it, you follow a similar approach: add “_nomap” to the end of your SSID. Are these at odds with one another? Probably. I don’t think I can have “_optout_nomap” – one defeats the other, which is disappointing.

Don't Install .NET 4.6 Just Yet

Nick Craver and team at Stack Exchange just published a very interesting bug they uncovered in RyuJIT.

For those that aren’t familiar with RyuJIT, it is a replacement just-in-time compiler that is shipped as part of the .NET Framework 4.6.

I won’t go into detail on the bug, Nick’s blog post does a great job on that, and he includes specific steps to take if you already jumped on the 4.6 train which involves disabling RyuJIT. To summarize it, under the right circumstances, a method may be called with parameter values that aren’t actually correct. What it will look like is happening is a method is being called with bogus parameters. Nick pointed out the specifics on what is actually happening in the comments.

This has pretty strong consequences, which Nick is right to point out. While it might be parameter that is more harmless, like numberOfTimesToBeep, it could be a parameter that has very real-world consequences, like amountOfMoneyToTransfer.

AWS Elastic Load Balancers and HTTPS Healthchecks

I ran into an interesting problem where some HTTPS changes on my servers broke their elastic load balancer. More specifically, I tuned Nginx to not support DHE cipher suites, leaving only ECDHE as the key exchange. The exact cipher suite being used was now:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA    (0xc013)

As a quick refresher, Elliptic Curve Diffie-Hellman Ephemeral is what we are supporting here, and removing the non elliptic curve algorithms. As I wrote a bit in a previous post, I didn’t feel that supporting DHE was worth it anymore.

After a configuration reload, I pulled up the site by going to a server’s IP address (thus bypassing the ELB) and everything looked pretty good. However within a few moments the actual site went down, and the ELB was convinced that all of the servers were unhealthy and took them out of server.

After seeing that the sites were still coming up OK, I refreshed myself as to what the health check in the ELB actually looked like.

Ah OK, so the ELB is checking HTTPS and it isn’t happy about the HTTPS configuration. I haven’t found any specific documentation calling it up, but it appears that the ELB does not support establishing an HTTPS handshake using the limited cipher suites listed above.

After changing my ELB check to use TCP port-establishment as the health check, the ELB was happy to bring the instances back online.

Public Key Pinning Afterthoughts

Not so long ago I decided to use HPKP (Public Key Pinning) on my website and see how it goes. For those curious as to “why”, it’s because I often use my own website to use and learn about new things in the ever evolving world of HTTPS, such as HSTS, HPKP, ECC, etc. Experimenting with these things is not an opportunity I can do at a job, however becoming familiar with them lets me make recommendations to people, including my employer.

After using HPKP for almost half a year, I am happy using it and haven’t run into any significant issues, and no visitors have complained about anything. A visitor shouldn’t see anything different as long as HPKP is working correctly. I do however, wish I had done a few things differently.

I wish I had made more than one backup key. HPKP requires you to have a pinned hash that isn’t in the certificate chain such that the key that hash was created from can be used if the currently deployed key is compromised. I talk about that a bit more in a different post. I created another RSA 2048-bit key and safely stored it elsewhere. In hindsight, I wish I had done more than that. If you are going to deploy HPKP, chances are you are in it for the long haul. As time passes, computers get faster, and people smarter than me think of better ways to factor integers. We don’t know how long RSA 2048 will be around. It’s many, many years out (barring any major discovery like proving N=NP). Using a key that relies on elliptic curves, like ECDSA, has some benefits. Performance is one, and better security is another. This leads me to wish I had also deployed an ECC key.

I’ve since added an ECC backup key for an ECDSA certificate. The process is a little different than I wrote about previously for RSA. To make a backup ECC key, I used this process:

openssl pkey -pubout -outform der -in ecc.key |
openssl dgst -sha256 -binary |
base64

This approach works for RSA and ECC keys. If you have a build of openssl that does not support the pkey command, you can use the ec command:

openssl ec -pubout -outform der -in ecc.key |
openssl dgst -sha256 -binary |
base64

This gives me a hash to pin, but before I can start using an ECC certificate, I must wait the max-age the keys have been pinned for. Currently I had it set to 60 days. In 60 days I’ll be switching to an ECC certificate.

Even if you don’t plan on completely switching to ECC, pinning one as a backup is still advisable if you ever plan on deploying multiple certificates. Apache supports this today, and Nginx is working on it.

Going ECC

For a while now I’ve wanted Nginx to support dual certificates. I don’t mean SNI, I mean the server choosing a different certificate depending on how the negotiation goes for the protocol. The reason I wanted this was to use an ECC certificate for my domain.

After thinking about it though, do I really need dual certificates, or will just going full-ECC be enough? Using the ever resourceful SSLLabs, I looked at the clients I support today. I had already eliminated Windows XP browsers and Java 6 from accessing the site due to a lack of SSLv3 and using 2048-bit DH parameters. So by switching to ECC, what more would I eliminate that I haven’t already? Turns out the list is a bit short:

• Android 2.x
• OpenSSL 0.9.8y

I’m not feeling all that big of a loss by not supporting those clients. Doing so would also allow me to eliminate all DHE ciphers from my cipher suite as well. I have added a new public key to my HPKP header for an ECDSA certificate. Before I can deploy the ECC certificate, I need to wait for my HPKP header to expire, which is at 60 days. In advance though, I’ve eliminated support for DHE in the cipher suite.

Another unrelated change is support for IPv6. The site now has IPv6 addresses. The DNS resolvers are not IPv6, that might be something I tackle later.