Action required: Update to TLS version 1.2

[robnicholson]

Several of my clients use Duo Authentication for Remote Desktop Gateway and Duo for Remote Desktop Web Access. They’ve all received the email about TLS 1.0 and 1.1 been depreciated and that they have devices still using these protocols. The email isn’t very useful on narrowing down which devices so I’m a bit lost! AFAIK, there are three possible targets:

1. The Windows 2019 server hosting the above apps for remote desktop services (RDS)
2. Various Android and IOS devices running the Duo app to response to pushes
3. Collection of Windows PCs used to run remote desktop connection to connect to RDS

In terms of #1, I’ve loaded the RDS web console (https://connect.domain.co.uk/rdweb and looked in dev tools. That reports that this connection is secure and using TLS 1.2. That suggests to me that the Windows server is using TLS 1.2.

In terms of phones, there is one phone listed as end-of-life (Android 9 and below) and five out-of-date (all IOS). Would I be right to focus on these?

In terms of #3 endpoints, the clients don’t have the more expensive license which would show information about endpoints. However, they’re all Windows 10 or 11 with regular updates so I’d expect them to be supporting TLS 1.2 or 1.3.

Any help much appreciated!

[robnicholson]

What confuses me is that the email says that all the devices failing are coming from Windows endpoints, I should focus there. So maybe the EOL and out of date phones are not the problem.

[robnicholson]

Later… Googling this, I found the very useful (and free!) IIS Crypto tool. Part of this is a site scanner and this reports that the Windows 2019 Server is still accepting TLS 1.0 and TLS 1.1 protocols. I’m going to try disabling them using IIS Crypto on my test lab.

[DuoKristina]

Please contact Duo Support. they can give you more specific information about the clients and Duo applications for which we still see TLS 1.1 or below used for the outbound connection to Duo.

Note that we are not monitoring nor do we even see inbound TLS connections from clients to the IIS server. We are only trying to warn about the TLS 1.2 requirement for the connections from whatever exists on-premises with a Duo application installed to the Duo API host.

[robnicholson]

Will do. One thing not to do is disable TLS 1.0 and 1.1 on a remote desktop server Although this will instantly expose some of those old applications that don’t support TLS 1.2 like old copies of Act!

I disabled TLS 1.0 and 1.1 on both server and client. I would imagine I could have left the client settings enabled.

Although reading up more on this, it believe that as long as TLS 1.2 is supported, Duo will be fine. The fact that the endpoint and/or server also still supports TLS 1.0 & 1.1 is okay. Older apps with establish a connection with the older versions but newer apps will negotiate to the latest protocol each end supports. Think that’s how this works.

[robnicholson]

Interestingly, when I disabled legacy protocols and ciphers, Duo stopped working through the Remote Desktop Web - it didn’t prompt for Duo push. It kept working through the Remote Desktop Gateway though. So clearly going from this protocol/cipher stack to the one below isn’t the right thing to do! This is a combination of “Best Practises” and also disabling TLS 1.0 and 1.1 on client and server. I suspect this is what broke it. So IIS Crypto best practise is to keep TLS 1.0 and 1.1 supported. Probably still too many apps out there using it. But intrigued why disabling them stopped Duo Remote Gateway Web from working.

If I’ve got time, I’ll do some further tests on my lab. But as I get paid by the hour, I can’t waste client time on this.

[robnicholson]

Whilst I’ve been in this game for many years as developer and support, I’m not 100% familiar with all the terminology. Is my understanding of the above correct?

1. Protocols define how the client and server talk to each other
2. Ciphers are the algorithms used to encrypt the traffic
3. Hashes are used to ensure that the data received is what was actually sent
4. Key Exchanges - don’t know?

At the negotiation phase, the client asks the server what it supports and will uses what’s classed as the highest security? So if the client supports TLS 1.0, 1.1 & 1.2 but the server only supports 1.1, it’ll use TLS 1.1.

So this change with Duo means that it will actively refuse to connect if the client and/or server doesn’t support TLS 1.2. I assume that it’s the operating system/browser that actually does the heavy lifting here in establishing the connection and then Duo checks what it’s got. If it’s TLS 1.0 or 1.1, it’ll not authenticate.

[DuoKristina · Accepted solution]

So this change with Duo means that it will actively refuse to connect if the client and/or server doesn’t support TLS 1.2

Yep, that’s basically it.

Duo installed on RD Web:

1. End-user client connects to RD Web - use whatever TLS/Ciphers the RD Web server accepts.
2. Primary/AD creds auth
3. Duo RD Web module on RD Web server contacts Duo API as a health check - outbound request from RD Web server will need to be TLS 1.2 with allowed ciphers (from the .NET crypto config on that server)
4. If Duo check is successful, client browser loads the interactive prompt from Duo’s service - browser comms from client to Duo will need to be TLS 1.2 with allowed ciphers
5. If the user picks Duo Push the request goes to the user’s phone with Duo Mobile installed - mobile OS much be able to communicate with Duo service using TLS 1.2 with allowed ciphers
6. After Duo success the user continues with remote session

Duo installed on RD Gateway (the difference here is that the RD client never communicates directly with Duo):

1. End-user client connects to RD Gateway - use whatever TLS/Ciphers the RD Gateway server accepts.
2. Primary/AD creds auth
3. Duo RD Gateway module on RD Gateway server contacts Duo API as a health check - outbound request from RD Web server will need to be TLS 1.2 with allowed ciphers (from the .NET crypto config on that server)
4. If Duo check is successful, Duo RD Gateway module on RD Gateway server contacts Duo API again to send the 2FA auth request - outbound request from RD Gateway server will need to be TLS 1.2 with allowed ciphers (from the .NET crypto config on that server)
5. If the auth method is Duo Push the request goes to the user’s phone with Duo Mobile installed - mobile OS much be able to communicate with Duo service using TLS 1.2 with allowed ciphers
6. After Duo success the user continues with remote session

Duo Authentication for Windows logon (RDP to session host with Duo WinLogon installed):

1. If an RDP connection - end-user client connects to RDP server; RDP client uses whatever TLS the server permits
2. Primary/AD creds auth
3. Duo for Windows Logon credential provider on server contacts Duo API as a health check - outbound request from server will need to be TLS 1.2 with allowed ciphers (from the .NET crypto config on that server)
4. If Duo check is successful, Duo for Windows Logon credential provider contacts Duo API again to send the 2FA auth request - outbound request from server will need to be TLS 1.2 with allowed ciphers (from the .NET crypto config on that server)
5. If the auth method is Duo Push the request goes to the user’s phone with Duo Mobile installed - mobile OS much be able to communicate with Duo service using TLS 1.2 with allowed ciphers
6. After Duo credential provider success the user continues with remote session

If Duo WinLogon credential provider and local console access, pretty much the same except the outbound connections to Duo are from the user’s Windows system instead of the server they RDP into.

[robnicholson]

Thanks for the detailed explanation.