Home > Uncategorized > #TLS client authentication sends target host as plaintext

#TLS client authentication sends target host as plaintext

TLDR; Github repo is here; https://github.com/infiniteloopltd/SSLTest

First and foremost, I am not highlighting a security flaw in TLS, I’m just pointing out a parameter that should never be “hijacked” for purposes of client identification, since it is sent in plaintext over an TLS (aka SSL) connection, and thus easily read by anyone who may be intercepting the connection.

This example is in C#, and at TCP level, a HTTPS connection needs to call “AuthenticateAsClient” before it can exchange content with the server. This step is where the client can provide to the server an X509 client certificate, to prove who the client is. Often the client does not provide an X509 certificate, and the server must use something else to authenticate the client.

The parameters to AuthenticateAsClient as the TargetHost, and an optional list of certificates. The TargetHost parameter is meant to indicate to the server which certificate to use, but it should never be used to pass any authentication credentials, like a user id – because, as the screenshot shows, the target host is passed in plaintext, and can be intercepted.

Here is my sample client;

client.Connect("", 500);
var s = client.GetStream();
var bMessage = Encoding.UTF8.GetBytes("HELLO WORLD");
var ssl = new SslStream(s);
ssl.AuthenticateAsClient("SOME SECRET INFORMATION", null, SslProtocols.Tls12, false);
ssl.Write(bMessage, 0, bMessage.Length);

Here, I am connecting to a local server on port 500, then using SSL (TLS) to connect to it. I authenticate as a client, passing something I shouldn’t in the Target Host.

On a seperate thread, I am listening for incomming data; and outputting it to screen, and it’s really obvious how the TargetHost appears in plain text. Note that the incomming stream is not decrypting the SSL, it is just printing it raw to the screen.

So, Once again, this isn’t anything to get worried about. By default, Http client libraries won’t expose this property, you need to be down at TCP level to change it, so you’re not likely to “accidentally” leak data this way. Generally if you are writing TCP level code, you’re heading in the wrong direction – but if you do think that this property could be a short-cut to client authentication – don’t do it!

Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: