I am now convinced that Microsoft is purposefully degrading the quality of the cryptography at the behest of the NSA.
It would take a lot to convince me that my position is false.
Think about what that would take: You'd have to explain to me, at length, that no-no-no, Microsoft cares deeply about the security of their customers, they hire professional cryptographers, and that they keep up with the best practices in ciphers, protocols, and configuration defaults.
So let us see what kind of uphill battle that would be:
In 2020, Microsoft products have all of the following current cryptographic problems.
- There is no support for TLS 1.3, either on the server or client.
- HSTS is very hit & miss, with only Windows Server 2019 adding partial support here and there.
- Until very recently, you'd have to jump through hoops to enable TLS 1.1 and 1.2. The operating system had the capability for years, but... Microsoft chose not to enable it. Explain that one without resorting to: "This helps the NSA hack everyone that doesn't know what they are doing."
- Across a forest trust, RC4 is the default cipher.
- If you try to enforce AES ciphers for Active Directory, you'll break some forms of single-sign-on from Azure AD!
- If you use ECC certificates, you're stuck with the handful of now very thoroughly legacy curves. Don't even dream of support for elegant, modern, secure ciphers like Curve25519!
- Keep in mind that Microsoft first implemented ECC ciphers and the associated "modern" Key Storage Provider (KSP) in 2006 for Vista. So you would think that only 2003-era software would still require the legacy CryptoAPI system, right... right? You'd be wrong: Notably, you can't have elliptic curve certificates with: NDES, AD FS, SQL Server, SCCM until very recently, and in fact just about every Microsoft product except for IIS. Which I remind you still can't do TLS 1.3. In Windows Server v2004.
- Azure Key Vault can't issue anything but RSA certificates from third-party CAs.
- Azure's disk encryption similarly refuses to use ECC, and has to use RSA for disk encryption.
- You can't get free certificates in Azure from Let's Encrypt or Microsoft themselves. Because a 1KB file in 2020 should still cost $50 a year, am I right? Otherwise how would VeriSign make their billions!?
- Certificate Services has had nearly zero new features in like a decade. Microsoft could have revamped the web interface, added certificate transparency support, SQL Server database support, PowerShell commands that... do... things, or anything really. Anything at all.
- There's no replacement for AD CS for that matter. It's clearly legacy, but Azure AD or Intune have no replacement. Enjoy your 2000-era interfaces and methodologies. You seriously have to write an INI file and put it into C:\Windows before installation to configure it!
An alternative explanation: Microsoft execs cannot be convinced that the amount of money it would cost to remediate these security risks would not be recouped in extra sales.
But you have no reason to believe a teapot orbits the sun somewhere. There is no reasonable way to believe that a teapot could have "gotten there". No space programs launching teapots just for laughs. Space programs in general being far too expensive for someone to launch something without government oversight.
Etc, etc...
My point is that the NSA does exist. They do degrade cryptographic algorithms, either through national security letters or simply bribery. The Dual_EC_DRBG fiasco happened. It really happened. Private United States based organisations do cooperate with these programs, either willingly or because they are forced to.
Now, ask yourself: What would it look like if Microsoft was -- hypothetically -- cooperating with the NSA?
Since Windows is so widely used, any weakness in its crypto would be a problem for the US itself! There's no separate "export version" any more.
(Which reminds me: "Export-grade crypto". Remember that? That happened too. That was not a "conspiracy"! That was law! Recently.)
Back to my point: how would you degrade the crypto but protect US interests?
Well, one method would be to have strong crypto in the software, disable it by default, and mandate that all US government organisations turn the strong crypto on. Simply rely on IT administrator lazyness and tight budgets of most organisations to ensure that 99% of the world outside of US Government remains on the weak sauce.
Exhibit A: FIPS mode.
Exhibit B: TLS 1.1 and 1.2 available but off by default.
Exhibit C: AES for Active Directory available but off by default.
Now do you get it? It looks suspicious.
It's one thing to accuse a neighbour randomly of murder. It's entirely another thing if you see them putting a shockingly large and heavy rolled up carpet in the boot of their car at three o'clock in the morning.
It would take a lot to convince me that my position is false.
Think about what that would take: You'd have to explain to me, at length, that no-no-no, Microsoft cares deeply about the security of their customers, they hire professional cryptographers, and that they keep up with the best practices in ciphers, protocols, and configuration defaults.
So let us see what kind of uphill battle that would be:
In 2020, Microsoft products have all of the following current cryptographic problems.
- There is no support for TLS 1.3, either on the server or client.
- HSTS is very hit & miss, with only Windows Server 2019 adding partial support here and there.
- Until very recently, you'd have to jump through hoops to enable TLS 1.1 and 1.2. The operating system had the capability for years, but... Microsoft chose not to enable it. Explain that one without resorting to: "This helps the NSA hack everyone that doesn't know what they are doing."
- Across a forest trust, RC4 is the default cipher.
- If you try to enforce AES ciphers for Active Directory, you'll break some forms of single-sign-on from Azure AD!
- If you use ECC certificates, you're stuck with the handful of now very thoroughly legacy curves. Don't even dream of support for elegant, modern, secure ciphers like Curve25519!
- Keep in mind that Microsoft first implemented ECC ciphers and the associated "modern" Key Storage Provider (KSP) in 2006 for Vista. So you would think that only 2003-era software would still require the legacy CryptoAPI system, right... right? You'd be wrong: Notably, you can't have elliptic curve certificates with: NDES, AD FS, SQL Server, SCCM until very recently, and in fact just about every Microsoft product except for IIS. Which I remind you still can't do TLS 1.3. In Windows Server v2004.
- Azure Key Vault can't issue anything but RSA certificates from third-party CAs.
- Azure's disk encryption similarly refuses to use ECC, and has to use RSA for disk encryption.
- You can't get free certificates in Azure from Let's Encrypt or Microsoft themselves. Because a 1KB file in 2020 should still cost $50 a year, am I right? Otherwise how would VeriSign make their billions!?
- Certificate Services has had nearly zero new features in like a decade. Microsoft could have revamped the web interface, added certificate transparency support, SQL Server database support, PowerShell commands that... do... things, or anything really. Anything at all.
- There's no replacement for AD CS for that matter. It's clearly legacy, but Azure AD or Intune have no replacement. Enjoy your 2000-era interfaces and methodologies. You seriously have to write an INI file and put it into C:\Windows before installation to configure it!