[squid-users] tcp_outgoing_address and HTTPS

[Michael Pro]

Totally agree with you, and at the same time - do not agree. But,
consider the following situation. There is https://site.net/ where
there is 1.jpg and 2.jpg. If I download from this site 1.jpg from the
address 1.1.1.1 and 2.jpg from the address 2.2.2.2. Even more. There
are situations when you need to release a certain connection to the
Internet through a single provider (for example, mobile), but you need
to download the largest file that is never physically downloaded by
this connection. On another no way. Squid theoretically these are
several computers (by the number of incoming connections) and, what
prevents us as different computers from using different outgoing
interfaces even for the same origin address?

I'm not saying that you need to push the unbroken. Look at the problem
from the other side.

For example, in Chrome, I set up a proxy 1.1.1.1 and download
https://site.net/1.jpg. At the same time in Mozilla I set up a proxy
2.2.2.2 and download https://site.net/2.jpg. What's the difference if
you set up the same one squid?
acl 1s-jpg url_regex ...1.jpg
acl 2s-jpg url_regex ... 2.jpg
tcp_outgoing_address 1.1.1.1 1s-jpg
tcp_outgoing_address 2.2.2.2 2s-jpg

Where is the entrance here?

Why do we try to shove it into one hole, if we can divide it into
separate processes. It may even need some new key or ACL to determine
that for these connections to create always new tunnels (TLS, ssl,
certs, ...)
acl separate_this CreateNewTunnelForNewLink

>> Question: how can we break the established channel (unpinn it) along
>> the old route and establish a new channel along the new route, when we
>> already know how.

> Squid supports using multiple sequential connections for the same
> from-client request, but not under the conditions you describe.
> Moreover, the already supported cases are limited to simpler HTTP/TCP
> failures. Complex code modifications would be required to support what
> you want for HTTPS, but it is doable, and others have wanted a similar
> "peek and then start from scratch" feature.


>> I'm willing to pay a large price for traffic congestion in this case,
>> since the goal justifies it.
> Please note that some origin servers may have a different opinion about
> this trade off: Some might view (repeatedly) terminated innocent
> sessions as an attack and block all your traffic.