Forum Discussion
AltostratusPool used with HSL::open - what are the requirements? Any way to make it send using TLS?
Hi,
if you would point the HSL::send directly to the pool with the endpoint servers the BIG-IP will send the data in plain text.
You will always need a virtual server with a server ssl profile to perform the SSL client hello.
It would be nicer if the HSL::send would have the -virtual switch to point to a virtual server.
You can add an irule to the port 80 VS (or AFM policy) to only allow the management ip addresses.
Cheers,
Kees
Hi,
if you would point the HSL::send directly to the pool with the endpoint servers the BIG-IP will send the data in plain text.
You will always need a virtual server with a server ssl profile to perform the SSL client hello.
It would be nicer if the HSL::send would have the -virtual switch to point to a virtual server.
You can add an irule to the port 80 VS (or AFM policy) to only allow the management ip addresses.
Cheers,
Kees
daboochmeister2Thank you for replying, Kees. I experimented with having the HSL::open work directly against the pool in use by the port 80 VIP in the scheme I described. But in that configuration, the HSL::send does send the traffic through a pool member, and that traffic gets proxied to the real server represented by the pool member - BUT, no TLS occurs, the real server refuses the connection because no TLS handshake was attempted.
My assumption is that, because the HSL::send bypasses being a true client of the VIP, none of the processing associated with profiles is applied to the stream (including no TLS on the outbound connection to the real server, since the SSL server profile is being bypassed).
That's unfortunate for us - i simplified, but with the scheme above, which requires a static route to force the traffic out the management interface to the port-80 VIP, we end up with plain-text content on the network, which creates a sniffing risk (especially because the data being logged contains sensitive information).
I'm going to create a separate question to see if anyone has found a way to do encrypted HSL such that the content is never on the network plain text.
Thanks again! I'll mark your answer as a solution, since it is perfectly viable functionally, whatever its acceptability in our context.
