Base a bypass rule on the request address not the response address?

[Jonathan_Sander]

This is a continuation of the issues described in whitelist AWS S3 buckets using complex URI / URL patterns? With help from Dameon Welch Abernathy‌ and Brian Butts‌, what we have determined is that the issue was never that the firewall was having trouble with the complex URLs for the S3 buckets. Instead, the issue appears to be one with how AWS deals with S3 requests. If you were to make a request to 'bucketname.s3.us-east-1.amazonaws.com', what you would get in response is a reply from 's3.us-east-1.amazonaws.com' (and the certificate will say it's for *.s3-us-west-2.amazonaws.com). This can be seen in an nslookup:

$ nslookup mybucket.s3.us-west-2.amazonaws.com
Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
mybucket.s3.us-west-2.amazonaws.com    canonical name = s3.us-west-2.amazonaws.com.
Name:    s3.us-west-2.amazonaws.com
Address: 52.218.248.56

So the question now becomes: is it possible to create a policy one could use for bypass (specifically bypassing HTTPS Inspection) that is based on the request and not the response? I want to tell Check Point that any time a response is the result of a request to a given URL, that response should get a bypass.

The customer is on R77.30, with plans to upgrade to R80.10 in Q1 2019.

Thanks for any help.

[PhoneBoy]

The only way we could do that, maybe, is in an explicit proxy scenario (where the gateway is an explicit proxy for the request). 

Otherwise, I'm not sure how you could even determine what the original request was to.