[squid-users] i have two question about https_port tproxy

[Amos Jeffries]

On 12/04/2016 7:04 p.m., johnzeng wrote:
> 
> Hello Dear Sir :
> 
> i will optimize https traffic recently at bridge tproxy environment , i
> know squid will https_port tproxy ,
> 
> question one : Whether the feature ( https_port) will be stable at squid
> 3.5 ?

https_port is not a feature. It is a config directive used by many
features. So feature stability depends on how you will be using it.

If you mean MITM - then no. The SSL-Bump feature which does that MITM is
still being stabilized.

The TPROXY feature usually can be considered stable, but depends on the
specific environment you use it in. Regardless of which Squid port type
you use it on.

> 
> question two : https_proxy will optimize special website url via acl or
> https_proxy can optimize full https website .

That is a statement. If I assume you mean *can* it optimize? the port
directive itself does not do any optimizing. It is simply telling Squid
what type of traffic will be arriving there. The features using it or
the features applied to the traffic after it has arrived through a port
(any port) may or may not optimize.


Squid (as a whole) does optimization. But "optimize" may not mean what
you think it does. What happens to traffic arriving at a partiular port
changes depending on what a) could be done with that traffic, and b)
been configured to be done.

Optimize could mean anything from simply re-arranging message headers
into a format that is faster to process at the server end. Through to
dropping requests as they arrive. Or many other things in between.

Processing the traffic also has a cost. So optimizing for one thing may
make other things get worse.


> 
> Sorry , i have't more experience about https_port .
> 
> Which direction will be suitable for small isp environtment
> 
> if possible , please give me some advisement .


An ISP usually does not have the ability (both technical and legal
abilities are required) to install self-signed custom CA certificates
onto all the client devices and/or software. That means that full HTTPS
interception cannot be performed by ISP. They are usually limited to
doing splice or block that traffic.
 That limited amount of action is enough to perform some types of
optimization such as rejecting traffic based on SNI values. But not
sufficient to do others such as caching.

Amos