It turns out that when a browser issues a request, the URL displayed will be the URL requested (unless it has been redirected). In order to do what the customer wants, we would need an iRule that would redirect the first request to an encrypted URL. It would then have to decrypt the URL and ask for the real URL on the back end. It would have to find all links (including absolute and relative links) and replace them with encrypted links in the response. It would then have to know to unencrypt all requests (after the first one) to the back end. We would have to have a fixed starting point to enter the app. Entering from any other starting point would break the app. In addition, the TMM hit would be considerable with any type of load.
The iRule would look something like this:
when HTTP_REQUEST {
set key "ccb69100758cef9b2bb18d7b1df7118b"
if { [HTTP::uri] equals "/" } {
HTTP::redirect [HTTP::host][AES::encrypt $key [HTTP::uri]]
} else {
HTTP::uri [AES::decrypt $key [HTTP::uri]]
}
}
when HTTP_RESPONSE {
set key "ccb69100758cef9b2bb18d7b1df7118b"
need some logic here to scan the HTTP::payload and replace any URI links with AES::encrypt versions of those links
we might be able to go a regex pattern match for href=" until the next "
then loop through the matches doing a regsub for the pattern with the AES::encrypt'ed pattern
get the length of the new payload
then do an HTTP::payload replace 0 $length $newpayload
}
Note that the encryption key must be fixed so thatr the rule will still work during a failover or reboot.