Rebex TLS Proxy (free)

Simple yet powerful TLS server

Download - TLS Proxy Application
More TLS software

Rebex TLS Proxy is a simple yet powerful TLS server with rich command-line interface. It makes it possible to easily add TLS 1.3/1.2 encryption to existing servers (using HTTP and other protocols), or operate as a TLS 1.0/1.1 proxy for legacy client applications or operating systems with no TLS 1.3/1.2 support.

It's free for commercial and non-commercial use.

Rebex TLS Proxy is built on top of our Rebex TLS library, which is based on our tried-and-tested TLS core that has been powering Rebex FTP since 2004.

On this page:

Download

Download Rebex TLS Proxy 

Checksums of RebexTlsProxy-v1.9.1.zip file:
 SHA-1:   cb484cace08ac1301b58956d30e22551043820c5
 SHA-256: da606fae7d1d6e76b6fda02a5e7af3fd9e24496af87b899ae81720d0116c3ae0

See here how to verify checksums of the installation package.

Getting started

  1. Download the ZIP package.
  2. Unzip it into the directory of your choice.
  3. Run tlsproxy install to install and configure the service.
  4. Run tlsproxy to show a list of supported commands, or check out an example below.
  5. Configure logging by editing Config/config.yaml file.
  6. Add some tunnels using tlsproxy tunnel add command.
    Run tlsproxy tunnel add --help to display possible options.
  7. After each change, restart the service by running tlsproxy svc restart.
  8. To run TLS Proxy in interactive mode, execute tlsproxy run (make sure to stop the service first).

Features

Rebex TLS Proxy features include:

  • TLS encryption wrapper mode - adding TLS layer to non-TLS services
  • TLS decryption wrapper mode - acting as non-TLS endpoint for TLS services
  • TLS adapter wrapper mode - adding TLS layer to TLS services that run a different version of TLS
  • TLS 1.3, 1.2, 1.1 and 1.0 on all supported platforms
  • Fully asynchronous TLS core
  • Unlimited number of connections
  • Rich and easy-to-use command line interface
  • Self-signed certificate issuer
  • Elliptic Curve DSA and Elliptic Curve Diffie-Hellman key exchange
  • AES/GCM AEAD symmetric encryption
  • SHA-256, SHA-384 and SHA-512 hashing algorithms
  • Dozens of modern and legacy TLS ciphers (see Rebex TLS for a list)
  • Renegotiation Indication extension (TLS 1.2)
  • PSK resumption (all modes) (pre_shared_key TLS 1.3 extension)
  • HelloRetryRequest support (TLS 1.3)
  • key_share extension (TLS 1.3)
  • Middlebox Compatibility Mode support (TLS 1.3)
  • Brainpool elliptic curves (TLS 1.2)
  • secp256r1 (NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521) and X25519
  • RSASSA-PKCS1-v1_5, RSASSA-PSS and ECDSA signature schemes
  • Support for deprecated SSL 3.0 protocol (disabled by default)
  • Support for SNI (Server Name Indication)
  • Support for Client Certificate Authentication
  • Certificates hot reload
  • HTTP communication parser (insert/modify Host, X-Real-IP, X-Forwarded-For, X-SSL-CERT request headers)

Example #1 - Add HTTPS encryption (with TLS 1.3/1.2) to an HTTP server

This is the most common usage scenario. Let's say you have a legacy HTTP server running in your DMZ that only supports plain HTTP and HTTPS with TLS 1.0, and that your router is configured to make the HTTPS service accessible to the Internet on port 443.

But TLS 1.0 is rapidly getting deprecated (along with TLS 1.1) by major browsers, and unless you provide TLS 1.3 or TLS 1.2 support, clients will soon be unable to access the legacy HTTP server. Rebex TLS Proxy can help here - install it either alongside the old server, or onto a separate server in your DMZ, and configure it to provide a TLS tunnel with TLS 1.3/1.2 support to your old HTTP server (running at 192.168.1.2, for example): 

tlsproxy tunnel add --in 0.0.0.0:443 --in-protocol TLS --out 192.168.1.2:80 --certificate cert:/User/My/example.com

This will make Rebex TLS Proxy accept TLS connections using TLS 1.3 and 1.2 on port 443. Once each connection has been accepted and a secure TLS session negotiated, the proxy will connect to port 80 of 192.168.1.2 (the old HTTP server) and pass all traffic between the client and the server. Once you configure your router to pass HTTPS connections to Rebex TLS Proxy instead of your old server, clients that no longer support TLS 1.0 or 1.1 will be able to connect again.

Note: Since TLS encryption is now provided by Rebex TLS Proxy, you also need to make an appropriate certificate available to it. In the sample above, we used a certificate stored in a .PFX file. In practice, using Windows Certificate Store might be a better option.

Reverse TLS Proxy

Example #2 - Virtual hosting for HTTPS websites

On HTTP servers, several websites can be hosted on the same IP address. The proper "virtual web" is chosen according to Host header in the HTTP request. A similar technology is also available for TLS (and HTTPS) protocol. It is provided via Server Name Indication extension (SNI).

If your TLS Proxy runs on one specific IP address, you can easily configure it to provide HTTPS access to several HTTP websites: 

tlsproxy tunnel add -i :443 --in-protocol TLS -o 192.168.1.1:80 -c x:\example1.pfx --server-names example1.com,www.example1.com
tlsproxy tunnel add -i :443 --in-protocol TLS -o 192.168.1.2:80 -c x:\example2.pfx --server-names example2.com,www.example2.com
tlsproxy tunnel add -i :443 --in-protocol TLS -o 192.168.1.3:80 -c x:\test.myorg.pfx --server-names test.myorg.com
tlsproxy tunnel add -i :443 --in-protocol TLS -o 192.168.1.3:80 -c x:\help.myorg.pfx --server-names help.myorg.com
tlsproxy tunnel add -i :443 --in-protocol TLS -o 192.168.1.3:80 -c x:\myorg.pfx --server-names *

This is what these commands do:

  • Requests for example1.com and www.example1.com will be routed to a website on IP address 192.168.1.1.
  • Similarly, requests for example2.com and www.example2.com will be routed to a website on IP address 192.168.1.2.
  • Requests for test.myorg.com and help.myorg.com will be provided with appropriate certificates
    and routed to a website on IP address 192.168.1.3 (where they are going to be handled by separate virtually hosted websites).
  • Requests to all other domains will also be routed to a website on IP address 192.168.1.3 and provided with a single certificate.

Reverse TLS Proxy in virtual hosting

Example #3 - Act as 'modern TLS to legacy TLS' adapter

TLS 1.0 and 1.1 are currently being deprecated by major browser vendors, and using them on the Internet is strongly discouraged. However, many existing legacy systems only support these legacy versions and often cannot be easily upgraded. And as long as those systems are operated within safe private networks or DMZs, they don't pose a security hazard. But these systems usually need to communicate with the outside world as well, which will become problematic once Internet-facing endpoints disable support for TLS 1.0 and 1.1.

Rebex TLS Proxy can address these situations as well by serving as an adapter that 'converts' TLS 1.3/1.2 (used by the servers on the Internet) to TLS 1.0/1.1 (used by legacy systems running on your private network): 

tlsproxy tunnel add
  --in 0.0.0.0:443 --in-protocol TLS --in-tls-versions TLS10
  --out test.rebex.net:443 --out-protocol TLS --out-tls-versions TLS13
  --certificate cert:/User/My/test.rebex.net

This will make Rebex TLS Proxy accept TLS 1.0 connections on port 443, and tunnel them to port 443 of test.rebex.net via TLS 1.3.

Note: In order for this to work properly, make sure you are using appropriate host names and certificates. For example, when providing a private 'HTTPS with TLS 1.0' endpoint for a third-party 'HTTPS with TLS 1.3' service, you might have to provide your own replacement certificate signed by a custom certification authority and configure all your legacy HTTPS clients accordingly.

TLS Proxy as TLS to TLS adapter

Example #4 - Enable modern security in legacy mail clients

Legacy mail clients lack support for TLS 1.3/1.2 encryption, which is required by contemporary mail servers such as Microsoft Office 365 or Google Gmail. Legacy mail clients work fine with on-premise legacy servers such as Exchange 2013, but pose a problem when migrating to cloud-based Office 365 or another modern mail server. More details can be found at Enabling TLS 1.2 in legacy mail clients blog post.

The easiest solution is to leave legacy mail clients to communicate with no encryption and configure Rebex TLS Proxy to protect unencrypted communication with TLS 1.3/1.2: 

tlsproxy tunnel add -i 0.0.0.0:143 -o outlook.office365.com:993 --out-protocol TLS
tlsproxy tunnel add -i 0.0.0.0:25 -o smtp.office365.com:587 --out-protocol SMTPE

This will make Rebex TLS Proxy accept plaintext (unencrypted) connections on ports 143 (for IMAP) and 25 (for SMTP), and tunnel them to ports 993 (for IMAP with implicit TLS) and 587 (for SMTP with explicit TLS) of Microsoft Office 365 via TLS 1.3/1.2.

Note: using unencrypted communication can be suitable if TLS Proxy runs on same machine as the mail client, but it can be a security issue if operating on company network. In such case, enable weak TLS 1.0/1.1 on legacy mail clients (if available) and configure Rebex TLS Proxy as shown in Example #3. However, this will require an additional step, which is to setup a certificate for TLS Proxy.

TLS Proxy

Supported platforms

Rebex TLS proxy runs on all recent and some not-so-recent Windows platforms:

  • Windows 11
  • Windows 10 (1607+)
  • Windows 8.1
  • Windows 7 SP1
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2

Both 32-bit and 64-bit platforms are supported.

For older platforms (such as Windows XP or Windows Server 2003), try Rebex Tiny TLS Proxy ( download binaries / source code on GitHub ).

License

Rebex TLS Proxy is free for commercial and non-commercial use. See the End User License Agreement (EULA) for details.

Version history

1.9.1 (2024-09-23)

  • Enabled Brainpool curves in TLS 1.3.
  • Fixed possible error in HTTP logging.

1.9.0 (2024-08-30)

  • Enabled FFDHE named groups and Ed25519 certificates in TLS 1.3.
  • Enabled Brainpool curves in TLS 1.2.
  • Added support for ECDSA with Brainpool curves and EDDSA with Ed25519 curve into certgen command.
  • Improved logging: tunnel duration is logged in access log, and more.
  • Upgraded internal TLS library. Main changes:
    • Fixed signature scheme selection and curve selection in TLS 1.3.
    • Fixed rare wrong final calculation of Poly1305 hash when temporary storage for remaining data is bigger than input block size.
    • Fixed potential repeated clean-up of TLS 1.3 extensions that might cause strange exceptions in the following TLS connection.

1.8.1 (2024-06-05)

  • When running in interactive mode (tlsproxy.exe run) the proxy is stopped when input stream is closed. This is useful when starting the proxy remotely using SSH command in the background, for example like this: ssh user@host "tlsproxy run" > tlsproxy.log &
  • Improved certificate loading and hot reloading (proxy ensures that the certificate is usable before using it for TLS handshake).
  • Improved logging.

1.8.0 (2024-04-03)

Using new syntax to locate certificates. Run tlsproxy certinfo --help for syntax details and examples.
  • Deprecating old syntax of the certificate key. If a certificate cannot be located using new syntax a WARN is logged and old syntax is used to locate the certificate.
  • Deprecating certificatePath, certificateKeyPath and certificatePassword keys. If used a WARN is logged.
  • Added certificatesReloadMinutes config value to enable certificates hot reload (see config-sample.yaml for details).
  • Added tlsproxy certinfo command to display info about certificates (and to validate certificate URI syntax).
  • Added --out-client-certificate option to support client certificate authentication on outbound tunnels using TLS.
  • Improved SMTPE handler to support multi-line welcome messages.
  • Improved logging.
  • Upgraded internal TLS library. Main changes:
    • Fixed possible deadlock.
    • Reduced memory footprint of CNG API interop layer.

1.7.0 (2023-10-31)

  • Upgraded internal TLS library. Main changes:
    • Fixed memory leak for inbound tunnels using TLS.
    • Fixed TLS cipher suite and TLS curve selection.
    • Disabled client-initiated TLS renegotiation.
    • Enabled Ed25519 and ChaCha20/Poly1305 ciphers.
  • Added support for client certificates:
    • Added --http-x-ssl-cert option to control value of the X-SSL-CERT HTTP request header sent on the outbound tunnel.
    • Added --request-client-certificate option to request client certificate on inbound tunnels using TLS.
    • Added --client-certificates-file option to configure rules for accepting/rejecting connections based on the provided client certificate.
  • Improved tlsproxy certgen command:
    • Added support for MD-5 and SHA-1 signature hashes.
    • The .key file is generated as well.
  • Proxy is automatically stopped, if no listener could be started.
  • Improved HTTP parser: speeded up async core.
  • Improved logging.

1.6.1 (2022-11-21)

  • Added --http-host-override option to fully control value of the Host HTTP request header sent on the outbound tunnel.

1.6.0 (2022-11-01)

  • Upgraded internal TLS library.
  • Improved HTTP parser: request and response parsers are better synchronized.
  • Improved tunnel closure routine: waiting for remote end to close the connection politely.
  • Improved logging: common errors moved to Warning level, errors during closure moved to Debug level, and more.

1.5.0 (2022-08-17)

  • Upgraded software framework to .NET 6.0.
  • Upgraded internal TLS library.
  • Fixed key usage in certificates generated using the certgen command: the issued certificate cannot be used as a Certificate Authority to issue other certificates now.
  • Added HTTP capability:
    • Added HTTP and HTTPS protocols to instruct the TLS Proxy to monitor HTTP traffic.
    • Added --http-x-real-ip and --http-x-forwarded-for options to insert corresponding HTTP headers into the communication.
    • The 'HTTP request' (method line) and 'HTTP response' (status line) are logged into Access log in Debug level.
  • Added intermediateCertificates configuration value to fully control certificate chain construction on the inbound tunnel.
  • Added --certificate-key-path option as an alternative to .pfx files: certificate can now be specified by .cer file + .key file.
  • Added --sni-override option to fully control SNI used on the outbound tunnel.
  • Added --debug option and changed behavior of --verbose option: the options determine verbosity of the console logging. File logging verbosity is now determined by the values specified in the config.yaml file only (file logging is now unrelated to --verbose and --debug options).
  • Minor improvements in logging: location of the executable and the config.yaml file is printed to console upon start, details about loaded certificates is logged upon start, better tunnel error reporting, and more.

1.4.0 (2021-07-27)

  • Upgraded software framework to .NET Core 3.1.
  • Upgraded internal TLS library.

1.3.0 (2020-07-07)

  • Improved tunnel closure routine to use less resources.
  • Certificate chain sent to the client during TLS negotiation does not include Root certificate now.
  • Changed behavior of certificate config value to: Thumbprint or Subject Alternative Name (SAN) or Common Name (CN).

1.2.0 (2020-05-25)

  • Fixed bug causing infinite loop when a TLS error occurred.
  • Fixed bug causing tunnel closure when client attempted to resume TLS 1.3 session on inbound channel.
  • Using Rebex components 2020 R2.

1.1.0 (2020-04-15)

  • Added support for TLS virtual hosting via Server Name Indication extension (SNI).
  • Improved configuration file validation.
  • Improved logging.

1.0.0 (2020-03-17)

  • Initial public release.

Contact

Have a feature request or a question? Contact us or ask at Rebex Q&A Forum.