(Universal Procedure Pointers) UPP mzstatic.com's mode of access redirector question

[JonathanLee]

Hello fellow Netgate community members,

I just noticed a different kind of redirect occuring on Squid Proxy.

(UPP IN USE)

Apple Music formally iTunes utilizes a tunnel within a tunnel. Or The coined term could be "Universal Procedure Pointer GET requests."

Example: SSL intercept based proxy in use with certificates installed on all devices the firewall has the itunes and apple music domains configured to be whitelisted such that they bypass the SSL proxy for use with proxy transparent mode. (advanced manually configured)

What occurs: After a request goes to a whitelisted domain such as apple music the same ip directly after is being used as a tunneled redirect right to the image server "mzstatic". Keep in mind mzstatic has not been approved yet for use with the SSL bypass, however it occurs unknowingly and uses that open tunnel.

Proxy config:

acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/pkg/url.nobump"
ssl_bump peek step1
ssl_bump splice splice_only
ssl_bump splice NoSSLIntercept
ssl_bump stare step2
ssl_bump bump step3

The "splice" occurs because the URL is configured as "^.*itunes.apple.com" within the "splice_only" list. This connection stays established and utilizes the same IP address for GET requests into non "splice" approved URLs. UPP forces the firewall to splice the others because the connection is already established. Now any domain can be now accessed in theory as long as it uses that tunnel thats established. It's amazing to watch. The firewall just started doing this. This is without VPN software but it acts like a VPN. WOW

upp.itunes.apple.com UPP Tunnels to:

s.mzstatic.com
is1-ssl.mzstatic.com

If this occurs so easily with itunes apple music what other sites might start using a UPP redirector invasively?

How can Squid be configured to spot such a redirect in and when it is abused?

Keep in mind I do have knowledge of what mzstatic is used for, it's the image server for the music covers etc.

(RESEARCH MZSTATIC BLOCKED)

The concern is the mode of use. This ability to redirect and or piggyback off any whitelisted domain in a firewall, such that the get request starts to use the same ip address for new URLs is essentially a non approved tunnel within a established ssl tunnel.

How can this be set up to block if it was abused by something else outside of Apple? How can this new mode of redirect be proxied when not approved? Simply put yes a firewall can be configured to block the other address. Again, that is after the damage is done and then it's to late. It takes a firewall admin to spot it only after it has already been used several times and only after it's spotted to establish block rules when needed. For an invasive actor it only takes one usage of such a tool to achieve an objective.

Has anyone else seen this outside of apple?

I mean why go through that much trouble to do that over just using the same domain such that it works with apple.music or itunes.com with something like images.itunes.com or images.apple.music.com

This redirect has been configured to use a seperate full domain inside of the established SSL tunnel. The real question is why do that? You could just be using the pre compartmentalized domains.

One can say this can be unethical. It's the mode of redirect that can bypass all security measures. Thus GDPR, CCPA are bypassed with such a redirect model in place.

Again, the question becomes why do it this way? Firewall users can still block the new domain easily. Again how long would it take to notice such a redirect on a Palo Alto or any other enterprise class system.

Just with "peek" configured first and after slice via whitelist list the connection can be establish with its own redirect. It makes no sense why the domain would have been redirected in such a manor.

[JonathanLee]

https://bugs.squid-cache.org/show_bug.cgi?id=432
This might be the reason as the established connection no longer requires the peek and a secondary server now establishes the connection.

It must be taught Phenomenology.

[JonathanLee]

http://www.squid-cache.org/Doc/config/host_verify_strict/

This could be the solution to fixing this...

host_verify_strict on
host_verify_strict off