0 votes
by (210 points)

Thanks to another post I was able to set up the tlsproxy correctly for TLS12 to TLS13.

However, I am now struggling to set up a tunnel where client certificate authentication is requested by the remote server.

When testing without any option set, I am seeing the following in the verbose logs

09:24:41 DBG Tunnel(1)[#3][O]: Client certificate authentication was requested.
09:24:41 DBG Tunnel(1)[#3][O]: No suitable client certificate is available.

when I make a call (Powershell) like

Invoke-WebRequest http://localhost:2283/ -CertificateThumbprint cbc5a1e65cbf35ba1768a644f2cff1040b1c7850

So it looks like tlsproxy sees this correctly. I just don't know where it is looking for the client certificate.

Playing around with --request-client-certificate true and --http-x-ssl-cert doesn't seem to do much. The result is always the same with 'No suitable client certificate is available.'

I'm also not sure how those options would work as the proxy would need access to the private key of the certificate. Without the private key, everything would have to be passed back to the client who has access to the private key.

I don't have a problem exposing my certificate to the proxy (only client passing through the tunnel) so specifying it there would be the easiest.

Any ideas?

Applies to: Rebex TLS

1 Answer

0 votes
by (70.2k points)
edited by

Unfortunately, client certificate authentication is currently supported on the inbound tunnel only. For outbound tunnel the client certificate can be sent to the server using the X-SSL-CERT HTTP header (the public certificate received from the client), see:

--http-x-ssl-cert <format>
    Indicates whether to modify HTTP traffic by including/overwriting the X-SSL-CERT request header with the provided client certificate. Optional.
    Supported values: None, URL-encoded, Base16, Base64.
    Note: To request client certificates on inbound tunnel, use --request-client-certificate true option.
    Note: When using None value, the X-SSL-CERT header is not sent (removed if the client sent it).
    Note: When the client did not provided any client certificate and the connection was not rejected, the empty X-SSL-CERT header is sent.
    Only takes effect when protocol is HTTP capable.

As you correctly wrote:

... the proxy would need access to the private key of the certificate. Without the private key, everything would have to be passed back to the client who has access to the private key.

this is the reason why we hesitated to add support for client certificate authentication on outbound tunnel.

We will now add simple configuration for your use case (within couple days) = ability to specify a fixed client certificate for outbound tunnel. It is up to you whether you will enable/disable client certificate authentication on inbound tunnel.

UPDATE:
From version 1.8.0 you can use --out-client-certificate to specify client certificate for outbound tunnel. Run tlsproxy tunnel add -? for details.

by (210 points)
That would be great. Thx
by (100 points)
>> We will now add simple configuration for your use case (within couple days) = ability to specify a fixed client certificate for outbound tunnel.

Hi, is there any following info regarding usage of client certificate for outbound tunnel?
by (70.2k points)
Hello, the beta version with client certificate authentication for outbound tunnel is available to download at https://www.rebex.net/getfile/11531b2b3cb044a8b59854e23345564d/RebexTlsProxy-v1.8.0-RC1.zip/

Please check out the "changelog.html" in the package to see all changes.

Run "tlsproxy tunnel add -?" to see documentation for new feature:

 --out-client-certificate <uri>
     Client certificate for outbound tunnel. Optional.
     For uri syntax and examples run tlsproxy certinfo --help.
     Only takes effect when outbound protocol is TLS capable.

We plan official release next week.
by (100 points)
Amazing, thank you, we will try it.
by (100 points)
ClientCertificates is looking OK. Thank you for your support.
However, we have another problem with the definition of TrustStore for Server Certificate verification for inbound TLS communication.
 Is it possible with Rebex TLSProxy to set up TrustStore with server certificates or is it possible to set up all server certificates as accepted and verified? In the documentation, I didn't find any information about this.
We have this error now: Received unexpected server certificate while negotiating anonymous cipher.
by (100 points)
All server certificates I imported into the Windows Certificate Store. We are setting communication with the server that has a certificate with the signature algorithm sha256ECDSA - brainpoolP256r1.
When we received (it is from REBEX log)  HandshakeMessage:ServerHello, negotiating TLS 1.2, ECDSA with ephemeral ECDH, AES with 256-bit key in CBC mode, SHA384, we received a Server Certificate. Next action thrown exception : Rebex.Net.TlsException: Received unexpected server certificate while negotiating anonymous cipher.
Could be there a problem with Rebex unsupported ciphers? REBEX is installed on Windows 2016 and I checked that the cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 is enabled or is there a problem with verification of the server certificate - with brainpool cipher? Is it a supported communication scenario with REBEX TLSProxy?
Is it possible to use / to setup the external ECC plugins with TLSproxy (as you describe in your documentation, but only for your TLS libraries and not TLSProxy ..?)

When I used openssl s_client I had to explicitly set up -curves secp256r1:brainpoolP256r1 and handshaking with client certificate authentication was done. Is it possible to define for TLSproxy ecliptic curves? I tried to enable this in Windows using the command enable_tlsecccurve, but without effect.
by (70.2k points)
>> Is it possible with Rebex TLSProxy to set up TrustStore with server certificates
No, you must configure your Certificate Store "manually".

>> is it possible to set up all server certificates as accepted and verified
By accepting any server certificate you discard benefits provided by the TLS layer and make the solution prone to man-in-the-middle attacks.
Moreover, in your case ("verification for inbound TLS communication"), the verification is performed on the client, so the TLS Proxy cannot affect that.
by (70.2k points)
>> Is it a supported communication scenario with REBEX TLSProxy?
Yes, Brainpool certificates are supported, but please make sure that the key-size of the certificate matches the enabled curve on the client. For example: ECDSA certificate with 256 bit, for brainpoolP256r1.

>> Is it possible to use / to setup the external ECC plugins with TLSproxy (as you describe in your documentation, but only for your TLS libraries and not TLSProxy ..?
No, the ECC plugins are available for TLS library only.

>> When I used openssl s_client I had to explicitly set up -curves secp256r1:brainpoolP256r1
I think it necessary (and enough) to use openssl with "-curves brainpoolP256r1" because Brainpool curves are not enabled by default in openssl (at least not in OpenSSL 3.1.1 30 May 2023).
by (70.2k points)
We have released TLS Proxy 1.8.0 (https://www.rebex.net/tls-proxy/)

For further comments please ask new question (https://forum.rebex.net/ask)
...