Microsoft... You Are WEAK!

Link in chain breaking

As one goes about shoring up their IT security, one aspect of the process is limiting (or authorizing) the methods in which a "secure connection" is established. A secured cryptographic connection basically has 2 components, the "protocol" portion, and the "cipher" portion. Together these create what is called a "cipher suite." And, as should be no surprise, as technology advances, these cipher suites fall out of favor and are flagged as being "weak" or "insecure" as vulnerabilities are discovered, and/or computational power renders the security provided as trivial to break. Unfortunately, as I found out this past week, even big players on the block *cough* Microsoft *cough* occasionally don't get the memo about what they should/shouldn't use.

But, before we dive into this past months adventures... first a very rudimentary primer on cipher suites. If you already know about cipher suites... skip this paragraph... otherwise read on...

While this is a great oversimplification, the protocol portion of the process is what sets up the initial hand shake between two systems and negotiates what kind of packet exchange will take place. Think of this a bit like saying you are going to ship packages back and forth via USPS, UPS, FedEx, etc.. The protocol doesn't deal with the data... just how the data is shipped back and forth (again... massive oversimplification). The cipher on the other hand is how the messages will be encoded/decoded... it handles the scrambling/obfuscation of the data so that anyone listening in can't intercept and make use of the data. The cipher could be thought of as a language that both systems agree upon... English, French, Swahili, etc.. But, just because you happen to know Swahili doesn't mean you can watch the traffic and make sense of it... the language (cipher) just sets the ground rules of the language... there's a set of encryption keys that both parties will use to do the actual scrambling of the data. The language (cipher) chosen just tells both sides how to use the keys to encode/decode the data while they are speaking Swahili. Stick with me a minute on this one... In English I say "cat" and you know what that is. Well, if we agreed upon Swahili as our language, I would say "paka" instead. But, I want to obfuscate what I really mean, so my super secret decoder book tells me that when I want to say "cat" in Swahili, what I should really say is "tumbili" (the Swahili word for monkey). That way when someone listens in on the conversation, even though they know Swahili, they won't understand what the conversation is actually about because they don't have a copy of the secret decoder book.

OK... that was a lot of oversimplification... but that helped to bring it down to where most people can understand cipher suites at a base level.

So.. "Fantastic!" you say "We have some cipher suites that are safe and some that aren't. How do we know which ones we can trust to keep us safe?" I'm glad you asked! A great site to check the status of a cipher suite is Ciphersuite Info which will show you the security status for over 300 different common cipher suites. If you visit that site, you can see see the current security status..

I don't want to get into what all the name mean and do a history of each. But, breaking down a few basics from the above screen shot you'll see stuff like CBC which is "Cipher-Block-Chaining" and SHA which is "Secure Hash Algorithms" and the like. If you click on any one of them in the list you'll be presented with a more detailed breakdown of each to include any reasons to hint as why it has been given a particular rating.


As for the general meaning of the ratings... Pulling straight from their FAQ section, here's what each categorization means...

  • Insecure - These ciphers are very old and shouldn't be used under any circumstances. Their protection can be broken with minimal effort nowadays.
  • Weak - These ciphers are old and should be disabled if you are setting up a new server for example. Make sure to only enable them if you have a special use case where support for older operating systems, browsers or applications is required.
  • Secure - Secure ciphers are considered state-of-the-art and if you want to secure your web server you should certainly choose from this set. Only very old operating systems, browsers or applications are unable to handle them.
  • Recommended - All 'recommended' ciphers are 'secure' ciphers by definition. Recommended means that these ciphers also support PFS (Perfect Forward Secrecy) and should be your first choice if you want the highest level of security. However, you might run into some compatibility issues with older clients that do not support PFS ciphers.

The first 3 in the list are fairly self explanatory. It's that last one where they talk about "Perfect Forward Security" (PFS) that throws people off a bit. Not going too deep into the weeds, PFS is basically a mechanism by which if a hacker takes a packet and manages to decrypt it and thereby discover the key being used, that the key cannot be used to decrypt new packets being transmitted... or to determine future keys to allow the decryption of new packets. So, for now, PFS stands at the panicle of encryption techniques.

"Fantastic!" you say. "We know know what's good/bad to use... but, how do we know what we are using?" I'm so glad you asked! 😁 While cipher suites can be used for so many different applications, the one most people use every single day without giving it a second thought is the ones being used to secure your web browsers connection to a given website. Any time you open up a browser and go to "https://www.example.com"... that "S" in "HTTPS" says it should be a secured connection. In many web browsers, if you see a padlock or shield next to the web URL after loading the site, that means the connection has been secured. There's an article by Microsoft that goes over what some of those symbols are and what they mean when visiting a website in Edge...

https://support.microsoft.com/en-us/microsoft-edge/securely-browse-the-web-in-microsoft-edge-c7beb47a-de9e-4aec-839d-28224a13a5d2

Now... that padlock or shield just says it negotiated a secured connection... it doesn't actually mean that the connection is "safe" to use. Why? Well... because the cipher suite that you used to negotiate with may be considered weak or insecure! In fact, at the time of this writing, the Microsoft Support page linked above uses a weak set of cipher suites! 😂 The way that you can see the cipher suite in use is to hit F12 in Edge or Chrome, then go to the Security tab and look at the connection properties. Viewing the Microsoft site in Chrome shows me that I'm connected using a weak suite...



"But, how can this be?!?" you say. "This is Microsoft! Certainly there must be a mistake. Surely you can connect to their site with a more secure cipher suite, right?" I love your optimism. Lets find out! As luck would have it, there's a website that you can use to check on the security of other websites. So, we can go to https://www.ssllabs.com/ and enter in the "support.microsoft.com" URL and it will test what levels of security their website supports. At the time of this writing... they get an "A" for security score. That sound good right? Well... not quite so fast... scroll down in the report to the section where they list cipher suites available for connection and you'll see the following...


You'll notice that they only support TLS 1.2... which is perfectly fine. But, all of the TLS 1.2 cipher suites that they support are flagged as being weak!!! 😲 There are no good/secure connection offerings available. For Shame!

"My organization said we are disabling all weak cipher suites. So, what will happen when I try to visit the Microsoft Support website?" It's funny you should ask! I've already done that myself and it's why I'm aware of the fact that Microsoft's site has all weak cipher suites in use. When I open up Edge and go to the support website I'm presented with the following error message...



So, on one hand, my settings worked exactly as intended. Disabling the known weak cipher suites prevented me from connecting to this site using a weak cryptographic connection. On the down side.... I can't connect to the site because there are no suitable/acceptable cipher suites available to choose from! 😛

Unfortunately, there's not much I can do other than complain. I can't force Microsoft to update their website to use stronger cipher suites. The only solution I have at my disposal is to lower the overall security posture of my browser. Or, in my case, launch an alternative browser that isn't honoring the Group Policy settings that disable the use of weak cipher suites *cough* Chrome *cough*. So... yeah... Edge will honor Group Policy settings that are created to disable specific cipher suites. Chrome on the other hand does not have complementary Group Policy setting. The only way to force Chrome to disable cipher suites is at the command line when you launch/run the browser. You have to pass it in as a command line argument/parameter which from an IT administrator perspective is 1) really annoying to deploy to users, and 2) near impossible to enforce that it always be used. One basically has to find every shortcut created by the system to launch Chrome and replace the run line to look something like this:

C:\Program\ Files\ (x86)\Google\Application\chrome.exe  --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Note: Each one of those hex values (eg. 0x0088) correlates to a cipher suite

And, if Chrome is set to be the default browser, just clicking on a link in an email will cause the program to launch without honoring the black list. As of this writing, there's no way that I'm aware to force the black list to be honored other than by command line arguments. Hopefully that changes some time in the future.

Long story short... nobody is perfect... not even Microsoft. (but, you didn't need me to tell you that, did you! 😉)

Note: Post migrated from old Blogger website.