Can TLS proxy be used to add supported ciphers to an unsupported IIS platform?

Question

I have an IIS application running on Windows 2012 Server R2 that performs an HTTPS post to a customer site. Moving the application to a supported platform isn't possible at this time.

The customer site recently deprecated "weak" TLS 1.2 ciphers and Windows 2012 doesn't support any of the available ciphers.

I'd like to set up TLS proxy to forward my HTTPS post to the customer site using the strongest ciphers available. Also, this site sits behind a load balancer that performs SSL offloading, so all inbound requests to IIS are already decrypted.

Would this be the correct config to accomplish this:
tlsproxy tunnel add
--in 0.0.0.0:80
--out clientserver.com:443 --out-protocol TLS --out-tls-versions TLS12

?

Answer 1

I am not sure what architecture you want to achieve, so I will describe all possibilities:

1.
load balancer --80--> TLS Proxy --443--> clientserver.com
In this setup, you will replace your IIS application with TLS Proxy, which will simply forward all traffic from load balancer to clientserver.com.
In this case, the proxy configuration would be:

tlsproxy tunnel add
  --in 0.0.0.0.:80
  --out clientserver.com:443 --out-protocol TLS --out-tls-versions TLS12

However, to make this working correctly, you probably need to override HTTP Host header in HTTP requests, because I suppose that FQDN of the load balance is not clientserver.com.
If overriding the Host header is needed, the proxy configuration would be:

tlsproxy tunnel add
  --in 0.0.0.0.:80
  --out clientserver.com:443 --out-protocol HTTPS --out-tls-versions TLS12
  --http-host-override clientserver.com

2.
load balancer --80--> IIS app --80--> TLS Proxy --443--> clientserver.com
In this setup, your current IIS app must be change to use HTTP instead of HTTPS. It can be done by requesting http://localhost instead of https://clientserver.com. In this case you will very probably need to use the configuration with Host override:

tlsproxy tunnel add
  --in 0.0.0.0.:80
  --out clientserver.com:443 --out-protocol HTTPS --out-tls-versions TLS12
  --http-host-override clientserver.com

Alternatively, you can change https://clientserver.com (HTTPS) to http://clientserver.com (HTTP) and route clientserver.com connections from IIS app to TLS Proxy using DNS or network settings. In this case, the proxy configuration would be:

tlsproxy tunnel add
  --in 0.0.0.0.:80
  --out clientserver.com:443 --out-protocol TLS --out-tls-versions TLS12

3.
load balancer --80--> IIS app --443--> TLS Proxy --443--> clientserver.com
A) In this setup, your IIS app can remain unchanged, you only need to route clientserver.com connections from IIS app to TLS Proxy using DNS or network settings.
The proxy configuration would be:

tlsproxy tunnel add
  --in 0.0.0.0.:443 --in-protocol TLS --in-tls-versions TLS12
  --out clientserver.com:443 --out-protocol TLS --out-tls-versions TLS12
  --certificate clientserver.com

The certificate presented by the TLS Proxy must be issued to clientserver.com, so the IIS app can validate it (it thinks it communicates with clientserver.com).

B) Or you can modify the IIS app to use https://localhost instead of https://clientserver.com.
The proxy configuration would be:

tlsproxy tunnel add
  --in 0.0.0.0.:443 --in-protocol TLS --in-tls-versions TLS12
  --out clientserver.com:443 --out-protocol TLS --out-tls-versions TLS12
  --certificate localhost
  --sni-override clientserver.com
  --http-host-override clientserver.com

The certificate presented by the TLS Proxy must be issued to localhost, so the IIS app can validate it (it is connecting to https://localhost).

Comments

#2 is what I have currently configured, only without overriding the host header. My goal is to route traffic to clientserver.com through the proxy, then send only that response back through the proxy to the web server. The outbound part is working, but the response isn’t being returned to the web server. I’ll see if overriding the host header fixes that problem, but I think the issue lies with either how traffic passes through the firewall to the load-balancer. It’s a one-armed config, so the load-balancer itself doesn’t perform any routing, but it does provide SSL offloading. Client requests pass through the firewall, which performs NAT from my website’s public IP to the virtual server’s private IP on the load balancer. The load balancer handles the SSL decryption then sends the decrypted traffic to the web server.

---

Please note that TLS Proxy does not perform any routing neither. It simply forwards traffic between inbound and outbound tunnels. You have to ensure that packets between TLS Proxy and clientserver.com are routed correctly.

1. At the first, check logs on the proxy to see whether response packets reached it.
Either run `tlsproxy run --debug` or configure debug logging in `config.yaml`
You should see:

  Forwarding X bytes (IN ==> OUT).
  Forwarding X bytes (IN <== OUT).

Also look for premature closure of the inbound tunnel or other kinds of errors.

2. If the log does not indicate that the proxy is receiving responses from clientserver.com, you have to monitor network traffic on your firewall/NAT to ensure reply packets are routed correctly. I would look where the reply packets are routed to (TLS Proxy or Load balancer or IIS app).

Example of IP end points in your configuration:

127.0.0.1:50501 (IIS app) --> 127.0.0.1:80 (TLS Proxy IN)
192.168.0.2:50502 (TLS Proxy OUT) --> 11.22.33.44:443 (clientserver.com)

Where:
- 50501 and 50502 are random ports assigned by OS.
- 192.168.0.2 is private IP assigned to machine with TLS Proxy.
- 11.22.33.44 is public IP of clientserver.com.

---

I was able to get the proxy working using option 2. It turns out that the bulk of my issue was with the cUrl parameters I was using to test, not with the config itself. Thanks for the input!