3

In summary, we need to use Application Request Routing 3.0 to securely reverse-proxy HTTPS requests made to a web server, to the same URL on an application server, where both servers are running Windows Server 2008 R2. The web server is allowed to support incoming and outgoing TLS 1.0 and TLS 1.2 connections, but the application server is only allowed to support TLS 1.2 for incoming connections (outgoing TLS 1.0 is allowed, but probably not relevant to this question).

[Browser] --TLS 1.0/1.2--> [Web server + ARR] --TLS 1.2--> [Application server]

I have configured the SCHANNEL registry settings on the application server as shown below ("HKEY_LOCAL_MACHINE" replaced with "HKLM" for formatting reasons). The web server is similarly configured, but with TLS 1.0 client and server connections enabled as well. The servers were rebooted after the registry change.

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000000

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

For the most part, the SCHANNEL settings seem to work as expected, but ARR will only offer TLS 1.0 in the Client Hello of the SSL handshake with the application server, as observed with Wireshark and NetMon. The connection is then dropped because the application server cannot continue the handshake and ARR returns a Bad Gateway error to the browser. Making a browser (IE 11) request directly from the web server to the application server results in a successful TLS 1.2 handshake.

Disabling TLS 1.0 client connections from the web server results in the web server not even sending a Client Hello (and a Bad Gateway response returned to the browser, with a slightly different reason).

Enabling TLS 1.0 server connections on the application server results in a successful TLS 1.0 handshake and ARR proxies the request as expected.

The servers that I'm trying to use have had all updates installed directly from Windows Update.

Either using an IIS Server Farm or hard-coding the application server name into the re-write rules doesn't appear to make any difference.

The same configuration works fine on Windows Server 2012 and I am able to reproduce the symptoms on Server 2008 R2 VMs that I have created on Azure.

What I'd really like to know is whether this is actually possible with ARR and Windows Server 2008 R2 and if so, what additional configuration steps or patches are necessary. While suggestions of other technologies might be helpful, we are constrained with fairly inflexible requirements at this point.

G C
  • 53
  • 1
  • 7

3 Answers3

3

This will change the OS defaults in a way to allow all TLS versions (or even SSL if you choose). I tested this on ARR Windows 2008 R2. Windows Easy Fix Patch

Brian Cumberledge
  • 46
  • 1
  • Thank you for sharing this. I haven't tested this yet myself, but sounds like it does exactly what's needed. – G C Sep 12 '16 at 03:38
  • As links tend to get broken, answers such as these are discouraged; at least put the relevant bits into your answer, so that future users can benefit from this. Also, you linked to the "Easy Fix" section, which neglects to mention that this registry entry enables a part of a Windows Update; without that update installed, this "fix" won't do much. – DarkMoon Sep 12 '16 at 06:35
2

UPDATE Microsoft has released a patch and associated workaround steps since this answer was submitted. Please see newer answers and comments for details.

It turns out that the answer is no, it is not possible.

The following response from Microsoft IIS/ASP.NET Developer Support clarifies the technical details.

Upon further investigation we have found that the use of Windows Server 2008 r2 and ARR uses WinHTTP to make the outbound request and is thereby bound to the default protocols for the OS. (SSL3 and TLS 1.0) Short Answer - ARR doesn't support WinHttpSetOption with WINHTTP_OPTION_SECURE_PROTOCOLS flag to pass WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2 value

WinHttp!Internet_Session_Handle_Object loads the dwSecureProtocols value directly from %SDXROOT%\net\winhttp\inc\defaults.h Windows Server 2008 r2 only supports SSL3 and TLS 1.0. IIS can be configured to use TLS 1.2, however ARR is bound to the OS defaults, and no matter how configured will always use either SSL 3 or TLS 1.0. Until the OS defaults are changed.

G C
  • 53
  • 1
  • 7
  • Thanks for posting this answer. We are exactly in the same situation, and I was wondering if you could share what you end up doing. – Cla B Feb 23 '16 at 15:04
  • @ClaB I'm glad it helped. It took a while to realise it wasn't something I was doing wrong. We're just trying to get our customers upgraded to Server 2012 when they take our new release that requires ARR, or let them use a reverse proxy of their choice. – G C Feb 25 '16 at 01:56
  • This is incorrect! Yes, this is possible. Please refer to this link: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows 1. Make Sure Service Pack 1 for windows is installed. 2. Download and run the easy fix above. 3. Restart the machine. 4. Test it should works now! – Anass Aug 30 '17 at 10:23
  • @Anass I believe a Windows update (released around 6 months after this post) is required for the "easy fix" to work, in addition to SP1. This is mentioned in linked article and by DarkMoon in a comment. I have updated the answer to make this more clear, rather than deleting (the answer adds context to the original question). – G C Sep 05 '17 at 00:54
2

Yes this is possible.

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows

I deployed the registry keys via GPO to all my Windows 7 2008 r2

The above answer from Microsoft IIS/ASP.NET Developer Support is incorrect. I cant comment yet due to reputation.

This does work. Confirmed on ARR 2008 R2 sp1 with update. Before reg key ARR outgoing (which uses winhttp) is TLS 1.0 After reg key (I used A80 for enable TLS 1.0-1.2) ARR uses TLS 1.2 for outgoing.

mikes-so
  • 21
  • 2