Forum Discussion
AltostratusPool used with HSL::open - what are the requirements? Any way to make it send using TLS?
Hi - we have a vendor integration that captures and logs request and response data for calls to virtual servers via an iRule that uses HSL::open/HSL::send. For this, they have us:
- Creating a local HTTP port 80 virtual server, with an SSL server profile and their TLS collection server endpoints as members; and,
- Creating a logging pool that has that local HTTP virtual server as a member; and,
- Creating an iRule (which they provide) that does an HSL::open on that logging pool, and after formatting request/payload/response data, does an HSL::send
That formatted data then goes to the logging pool entry, which in turn sends it to the port 80 VIP, which in turn sends it, using TLS, to their collection servers.
I'm assuming that their iRule is therefore responsible for formatting the stream sent to the logging pool into valid HTTP, which then just gets passed "raw" to their HTTP VIP, without any processing by the logging pool. (Is that a correct understanding?)
My questions are:
1. Given that scheme, why can't the iRule skip the "logging pool", and just use the pool for the port 80 virtual server directly in the HSL::open? What value is added by having the iRule pass the stream being sent through a separate pool? If the content the iRule will send via the HSL::send is HTTP formatted anyway (my assumption), couldn't the HSL::send just as simply send it right to the pool for the virtual server? And, if it does so, is there any way to configure the virtual server to not even expose a port?
2. Alternatively - and even better - is there any way to configure the "logging pool" created above to send directly to the vendor's TLS collection servers - that is, do a TLS wrapping on the way out? (this may be tantamount to asking, is there any way to attach an SSL server profile to the pool, even though it doesn't have an owning virtual server, causing it to apply TLS)?
The reason I ask is two-fold - their design is clumsy for us in that the logging pool can't directly send to the local VIP via the TMM plane (because of the issue described here), and as a result we have to add a static route to force the traffic out the management interface, increasing network load; and, having another VIP exposing port 80 is undesirable as a security risk (though we can and have blocked access to it ... still, we'll get serious side-eye from cybersecurity)
Thank you for any information!
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
2 Replies
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.
