By Gerrit - 10 Jul 2025
Is it possible to use the TCP listener over a SSL / TLS stream? And / or is it possible to use the listener with a client certificate? In that case we can create a log endpoint in our application to enable remote logging.
|
By LogViewPlus Support - 10 Jul 2025
Hi Gerrit,
Thanks for the feedback. This is not currently possible, but I think it's a good idea and something we should look into.
Is your server providing the certificate and you just want the client to understand the datastream? ...or are you doing some kind of authentication?
Thanks again,
Toby
|
By Gerrit - 10 Jul 2025
I would like to setup the server endpoint with a self signed certificate (or one trusted by via a CA). The client needs to trust the server certificate, but this can be handled with the certificate store with trusted root certificates. So a selfsigned, can be trusted when adding the certificate to the trusted roots. So in this case an encrypted ssl stream can be setup.
To ensure not every connection is accepted, and receiving a Log Stream, a form of authentication is required. To keep this universal, without specify or implement a form of protocol, i thought, Client Certificates can be used for this. In the SSL / TLS handshake, a client could sent his certificate to the server, and the server can implement to trust this certificate or not, aka to accept the connection or not. We can create a custom client certificate per user to identify who made the request.
|
By LogViewPlus Support - 10 Jul 2025
Thanks for the feedback.
LogViewPlus listens for log data published by the server. I can undersand why the server would want that information to be encrypted in transit.
From my perspective, LogViewPlus just needs to handle the encryption protocol from the server. It doesn't matter if someone is "pretending to be the server" because the client never sends any data. The worst case is that you are reading fake log entries and I am not sure this is worth the additional complexity required to defend against it (certificate chains, server name validation, etc...).
If the client needs to authenticate then this gets weird for us for two reasons:
1. There are so many ways to authenticate that we would only be able to handle a subset of the possibilities.
2. Now the client is sending data and we need to verify the server. Further increasing complexity.
Given the increased complexity, I am not sure that we have enough demand for this feature to justify the effort.
If authentication is needed, I think a custom reader would be a better solution.
|
|