TLS-Proxy - sample with certificate

Question

I'm trying to set up the TLS Proxy where I need to connect from an internal system capable of TLS 1.2 towards an external system only supporting TLS 1.3. I am struggling to get this working.

A first issue I am having is that I can only make configurations where the certificate is stored in a file. If I put my certificate in LocalMachine\My (Computer Account > Personal) and then try to set up the configuration with the thumbprint or common name, I always get key not found. Is there some specific syntax? Is there a specific store the certificate needs to be in?

Second if I use a file based certificate I am not able to get it setup correctly to make the connection work. As an example, I'm trying to set up a proxy towards test.rebex.net using a self-signed certificate and followed the approach from https://forum.rebex.net/22486/bi-directional-tls-proxy

So I am setting this up as follows

tlsproxy certgen -s "CN=test.rebex.net" -a "test.rebex.net" test.rebex.net
tlsproxy tunnel add --in 0.0.0.0:2233 --in-protocol TLS --in-tls-versions TLS12 --out test.rebex.net:443 --out-protocol TLS --out-tls-versions TLS13 --certificate-path test.rebex.net.pfx
tlsproxy run

Either something is wrong with this setup, or with the way I call it using curl but it keeps failing.

I tried looking around but I cannot find a fully worked out example of connecting anywhere to a TLS 1.3 external site from 'on premise'. Any known examples or hints?

I would already be happy even if the sample is not using a certificate and just goes from plain => TLS 1.3. Even there my curl calls seem to fail.

Answer 1

Let solve the issues step by step.

1. If we run curl "https://localhost:2233", we see error: The certificate chain was issued by an authority that is not trusted.
We have to run curl --insecure "https://localhost:2233"
The --insecure parameter must be used here, because we use self-signed certificate, which is not trusted on our system (unless we install it into trusted certificates).

2. Let run the proxy in verbose mode tlsproxy run --verbose and test with curl. In the ClientHello we see:

    ServerName<
      host_names=<localhost>
    >

This means, that the proxy is trying to establish TLS session with target host using invalid SNI. The proxy used SNI received on the inbound tunnel.
To fix this add tunnel with --sni-override test.rebex.net option.

3. After running curl we see error: HTTP Error 400. The request hostname is invalid.
In the verbose log from the proxy we see:

    0000 |47-45-54-20-2F-20-48-54 54-50-2F-31-2E-31-0D-0A| GET / HTTP/1.1..
    0010 |48-6F-73-74-3A-20-6C-6F 63-61-6C-68-6F-73-74-3A| Host: localhost:
    0020 |32-32-33-33-0D-0A-55-73 65-72-2D-41-67-65-6E-74| 2233..User-Agent
    0030 |3A-20-63-75-72-6C-2F-38 2E-34-2E-30-0D-0A-41-63| : curl/8.4.0..Ac
    0040 |63-65-70-74-3A-20-2A-2F 2A-0D-0A-0D-0A         | cept: */*....

The situation is similar. The curl client sent the request to localhost and filled the Host header accordingly. Since the proxy forwards all data as is, the server replied with the 400 error.

If we run curl --insecure -H "Host: test.rebex.net" "https://localhost:2233" we get the requested page.

However, the Rebex TLS Proxy can run in the HTTP aware mode, monitoring and possibly modifying the HTTP traffic. If you change the protocol from TLS to HTTPS you can use the option --http-host-override test.rebex.net

At this moment, you can run curl without the -H "Host: test.rebex.net". But please note that this requires more memory and CPU time to process and modify the traffic. In some scenarios it is easy to ensure that -H Host is used for each request.

4. Now, let install the test.rebex.net.pfx into LocalMachine/My store and delete/move the .pfx file from disk. To locate the certificate use the --certificate test.rebex.net option (instead of --certificate-path test.rebex.net.pfx).
Note that the proxy process must have access to the private key, so you can start by installing into CurrentUser/My store instead.
If you are not able to make this working with LocalMachine/My nor CurrentUser/My try investigate the log for some related errors.

The final configuration for TLS 1.2 to TLS 1.3 proxy is:

tlsproxy tunnel add 
  --in 0.0.0.0:2233 --in-protocol TLS --in-tls-versions TLS12 
  --out test.rebex.net:443 --out-protocol HTTPS --out-tls-versions TLS13 
  --certificate test.rebex.net
  --sni-override test.rebex.net
  --http-host-override test.rebex.net

5. If you want to setup HTTP to TLS 1.3 proxy, use this:

    tlsproxy tunnel add
      --in 0.0.0.0:2280 --in-protocol plain
      --out test.rebex.net:443 --out-protocol HTTPS --out-tls-versions TLS13
      --http-host-override test.rebex.net

And test it just with curl "http://localhost:2280" (note the port change).

Comments

Thanks. Works like a charm.

Answer 2

Hi,
some questions along similar lines:

1. Does "Plain" cater to some sort of "auto-negotiation"?
Or is there some details on how /when "Plain" is to be used?

2. I am trying to tunnel HTTP to HTTPS/TLS 1.3 with
```
tlsproxy tunnel add
      --in 0.0.0.0:2280 --in-protocol plain
      --out test.rebex.net:443 --out-protocol HTTPS --out-tls-versions TLS13
      --http-host-override test.rebex.net
      —-certificate-path D:\test.rebex.net.pfx
      —-certificate-password xxx
```

Upon running with `tlsproxy run`, the following was observed
```
INF.... Fatal Alert:CertificateUnknown was sent.
WRN:... Cannot start outbound tunnel due to: Rebex.Net.TlsException: Unable to perform revocation check of the server certificate.
```
The cert and password specified in the config has been checked. ie. I am able to view/extract cert information from the pfx file with the specified password. The CRL found in the cert is also reachable.
How can I debug this further?

3. How is the value of dhKeySize determined?

Thanks.

Comments

1. `Plain` means "unsecured" - the communication is not modified in any way. So, the answer is no, there is no sort of "auto-negotiation".

2. Your configuration is correct. However please note that `--certificate-path` argument is not needed here. The certificate must be provided if you want to provide TLS (HTTPS) on the inbound tunnel. Since you are using `Plain` for inbound tunnel, the certificate will not be used.

The issue is on the outbound tunnel: "Cannot start outbound tunnel ..." the reason of failure is "... Unable to perform revocation check of the server certificate."
This means that your machine (where TLS Proxy is running) is not able to validate the certificate of `https://test.rebex.net`. Since the certificate uses OCSP, your machine is probably not able to handle OCSP or there is an issue with it.

3. `dhKeySize` is also not needed for you, since it only affects the TLS capabilities on the inbound tunnel. Please see `tlsproxy tunnel add -?` output:

> --dh-key-size <key-size>
>   Size of ephemeral Diffie-Hellman key for DHE key exchange. Optional.
>   Used when inbound protocol is TLS. If not specified, TLS_DHE_ cipher suites are disabled.
>   Supported values: 1024, 2048, 3072, 4096, 6144, 8192.