Remote Desktop Stopped Working in May 2018

The Problem

After applying security updates to a Microsoft Windows workstation in May 2018, you now get a peculiar error trying to connect to another Windows computer using Remote Desktop Connection:

RDP Error

The Solution, In Brief

To fix this particular situation, do one of the following, in order of desirability:

  1. Apply Windows security updates through at least March 2018 to the target computer (Windows 7 or Windows Server 2008 or later only).
  2. If you can't update the target computer, you can enable the option to "Allow connections from computers running any version of Remote Desktop" on the target. But, if your connection could possibly be exposed to a man-in-the-middle compromise, plan for updating the target.
  3. If you can't update or reconfigure the target computer, set this registry key on your client computer, and reboot:

    KeyHKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ System \ CredSSP \ Parameters
    DWORD ValueAllowEncryptionOracle
    Data2
    You can also set this via Group Policy (details below). If you ever access computers via Remote Desktop over a connection that could be exposed to a man-in-the-middle compromise, plan for updating the target computers, and remove this registry or policy setting when done.

More Information

In March 2018, Microsoft announced a newly discovered vulnerability in the CredSSP protocol, which is used by Remote Desktop Connection to authenticate your password or smart card using Network Level Authentication (NLA). The flaw could allow someone to capture your credentials if he has access to the traffic between your client computer and the target.

The fix involves:

  1. Updating the CredSSP protocol to enable "encryption oracle remediation", and
  2. Updating the Remote Desktop software to use this new function.

The first security updates were released on March 13, 2018. If both the client and target computers are updated, the connection will be safe. If either client or target are not updated, either the client will connect using the vulnerable older protocol, or the connection will be blocked.

This update provided a new registry setting, and a related Group Policy template item, to control whether an updated computer can fall back to the outdated protocol when making a connection to or from an outdated computer, or whether the connection will fail. The registry key is given above. The Group Policy setting is in Computer Configuration \ Policies \ Administrative Templates \ System \ Credentials Delegation, and the setting itself is Encryption Oracle Remediation. The values and their functions are:

  • Force Updated Clients (registry value 0): This is intended to apply to a target computer. This will only be set if an administrator specifically configures it.

    When set on a target computer, CredSSP will only allow connections from clients using the updated protocol.

    If the target also requires Network Level Authentication (NLA), and you attempt to connect from an unpatched Remote Desktop client, the connection will always fail (time out). If the target allows Remote Desktop connections without using NLA, the connection may or may not succeed (depending on the version of Windows). But, not using NLA for Remote Desktop presents its own set of vulnerabilities, so it would only make sense to enable Force Updated Clients but allow non-NLA connections to the same server in particular situations (mixed environments, third-party applications that use CredSSP, etc.).

    When set on a patched client, the Force Updated Clients setting has the same effect as Mitigated (see below).
  • Mitigated (registry value 1): This setting is intended for the client. On a client, it will block the client from using the outdated CredSSP protocol, meaning it cannot connect to an unpatched target (this would generate the error message shown above). In other words, the vulnerability is mitigated at the client. But, strangely, this setting may still allow a patched client to connect via Remote Desktop to an unpatched target that does not require NLA. So, this setting alone on the client doesn't completely mitigate a client. You have to know that your target is patched, to be completely safe. On a target, this setting has no effect; the target will allow unpatched clients to connect using the prior protocol.
  • Vulnerable (registry value 2): Setting this on a patched computer will allow it to make a connection to or from an unpatched computer in all cases. If the other computer has been patched, of course, the connection will use the updated protocol. If not, the connection will fall back to the outdated protocol.

When the patches were first published, all computers used the Vulnerable setting by default. The update of May 8, 2018, changed this to Mitigated. Looking at the above, you can now see why people who had updated workstations couldn't connect to remote computers that were not updated.

Remember, these registry/policy settings only matter when one computer is patched and the other isn't. When both are patched, they will always connect, using the updated protocol, and you don't need to change anything.

If you use third-party network applications that rely on CredSSP, then in addition to applying the updates as described here to patch the CredSSP software, your application should be updated to utilize the new function of CredSSP (encryption oracle remediation). If not, you will still be able to connect, but your connection will not be secure. And if either computer is set to Force Updated Clients, or your client is set to Mitigated, your application will not connect.

Connectivity Summary

To look at all the above from another angle, here is a summary of how software updates and settings affect connectivity.

  • You cannot connect if:
    • The client is patched and set to Force Updated Clients or Mitigated (the default setting after the update of May 8, 2018), and the target is unpatched; or
    • The client is unpatched, and the target is patched and set to Force Updated Clients.
  • If the client is patched and set to Vulnerable, you can connect to any target, but it will be secure only if the target is patched.
  • If the target is patched and the registry/policy setting was not configured, then any client can connect, but it will be secure only if the client is patched.
  • If both client and target are unpatched, connections will work, using only the vulnerable protocol.
  • If both client and target are patched, connections will work, using the updated and secure protocol, regardless of any registry/policy settings.