Forum Discussion
AltostratusAny approach to encrypting HSL traffic such that no plain text is ever sniffable?
Hi - we have been asked to integrate a vendor logging solution on our F5s that uses HSL to send information about requests to and responses from our HTTP/HTTPS VIPs on our LTMs. (I describe this configuration in more detail in a post yesterday, with the title "Pool used with HSL::open - what are the requirements? Any way to make it send using TLS?" ... but in summary, they use an iRule with HSL:open against a manually created pool, that uses as members an HTTP VIP created on the same F5; that in turn requires us to use a static route to send the traffic over the management interface, so it can reach the VIP on the same F5).
Though we have a solution for the flow (see other post), it results in the logged content being plain-text on our network, whilst going from the management port to the VIP used as a destination of the HSL pool.
Is there any general solution or design that would permit us to send out HSL logging such that it is TLS encrypted right from the moment it is sent by the F5, never appearing in plain text on our network?
Thank you!
Hi,
I took a look at this in my personal lab today, and I don't think this is possible. With HSL you only have the options of UDP or TCP (but not TLS) in either the iRule HSL::open command or when creating an HSL destination (sys log-config destination remote-high-speed-log).
I tried recreating your configuration. I thought that perhaps adding a clientssl profile to the HTTP VIP would result in the traffic on the client-side from the management port to this VIP being TLS encrypted, but in my packet capture I could still see the logs in plain text. It was only encrypted on the server-side, between the VIP and the back-end syslog server.
So unfortunately, it looks like the F5 BIG-IP can only send HSL traffic in plain text on the client-side. I am not aware of any other configurations that could be leveraged to achieve end-to-end TLS encryption for logs.
- zamroni777
MVP
Hsl isn't using http format, so you must remove http profile from the vserver.
Also remove the client side ssl profile from the vserver. If you put client side ssl profile, the vserver will only accept tls connections.
Good points.
It still means though that we do not have a way of encrypting the HSL on the client-side which is what @daboochmeister2 wants.
- Juergen_Mang
I quickly tested the setup described in this article and it works:
- Create a L4 TCP Virtual Server with a none-floating address with a serverssl profile and the tls syslog server as Pool Member.
- Create a Pool with above Virtual Server as Pool Member.
- Use this Pool as the HSL-Pool or use the Virtual Server directly for syslog messages.
We now have a Virtual Server that listens for plain-text syslog messages and sends this messages encrypted to the tls syslog server. No plain-text packet leaves the f5.
