Given a situation where legacy technology exists from a system and we don't want to do a complete upgrade (.net in this case w/ version that doesn't have any support for TLS 1.1/1.2) as the product will soon be EOL. However, we are being required to upgrade from TLS 1.0 to 1.1 for some outbound calls. Is there a proxy setup that would allow for such an activity?


  • Sure, let the box do TLS v1.0 inside your trusted network to a trusted box, which acts as an endpoint and re-encrypts the traffic with TLS v1.2, look for "TLS traffic inspection", "TLS mitm box", "TLS man in the middle box" or "HTTPS inspector" – SEJPM Apr 7 '16 at 19:34

Due to the security built into TLS this can not be done by changing the existing TLS handshake in the proxy. Instead a TLS connection between the target server and the proxy and another TLS connection between the proxy and the client must be created. The latter connection cannot get the original certificate from the server, but the proxy must create a new one signed by its own CA. All certificate validations will be done by the proxy, so you need to trust the outbound proxy to do this properly. You also need to configure your application to trust the CA used by the proxy to create the new certificates.

Since TLS is terminated and recreated at the proxy there is no longer an end-to-end encryption. This means, that client certificates will not work in this setup transparently, i.e. you would need to move the sending of the correct client certificate to the proxy. Only few proxies support this.

If you can live with these limitations and if you only care about HTTPS traffic there is a lot of software which can do this. If you have one of the better firewalls or secure gateways the functionality is probably already there in the form of SSL inception capabilities. Apart from that you might use the free squid web proxy or test tools like mitmproxy. But note that especially the test tools not always validate the certificates properly. Also some solutions cannot deal properly with sites using Server Name Indication which makes these products unusable with lots of today's sites.

If your aim is not to deal with HTTPS traffic but with other protocols (i.e. IMAP, SMTP, SIP ... or custom protocols) the choice is much smaller and you might need to develop your own protocol specific version of such a proxy.

| improve this answer | |
  • Steffen - GREAT information! This isn't the norm. The outbound(only) initiation is coming from a server and then connecting to several other(not managed by me) over TLS as well as any number of end points which can be https or simply http. Would it be better to do a transparent proxy w/ the client cert on the proxy? What would be the best type of cert to do this? Then you noted something else, if we did this then there may be no means to connect to non HTTPS sites? These requests are driven by external parties, not controlled by us, as to where/how they connect. Thank you so much! – Travis Howe Apr 9 '16 at 13:34
  • @TravisHowe: It's not clear if you have the choice of transparent or not - if you can configure the clients to use an explicit proxy then this would be better but if you don't then you need to do it transparently. And the questions with "best byte of cert" and "non HTTPS sites" make no sense for me - maybe you should make yourself more familiar first with how SSL interception/inspection/MITM and how transparent and non-transparent proxies work and how a server distinguishes between HTTP and HTTPS. – Steffen Ullrich Apr 9 '16 at 13:59
  • "The outbound(only) initiation is coming from a server" - this does not matter. Even an application server has the role of a HTTP(S) client when initiating the HTTP(S) request. The meaning of "server" and "client" highly depends on the context. – Steffen Ullrich Apr 9 '16 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.