On 01/06/17 14:15, Masha Lifshin wrote:
Thank you, very helpful. Some more clarifying questions for you.
Sorry for the imprecise language, I mean not interception but rather
accepting connections to that port. Our browsers will be explicitly
configured to connect our proxy, so I believe that is not interception?
Yes, however for HTTP/1.x it is also not the same traffic syntax as port
80 or 443. It is a proxy specific syntax which port 3128 is registered for.
If we want to only allow encrypted traffic between the browser and
proxy, does that mean we'd only want to use the following line from
your example?
Depends on what you mean by encrypted in context of the proxy syntax.
# HTTPS proxy; clients establish TLS connections to 31443 (your item #1)
https_port 31443 ssl-bump ...
Once a handshake is done and tls connection is established here, would
it be possible to have all http and https traffic from the browser go
through 31443? So squid would not need to have ports 80 and 443 open?
Think about it as two separate things.
1) the transport used to get HTTP(S) to the proxy.
That can be TCP (http_port) or TLS (https_port).
2) the protocol the browser is talking to some origin on the other
side of the proxy.
That can be HTTP or HTTPS (aka HTTP-over-TLS).
These layers stack. So Squid supports:
http_port 3128
# HTTP-over-TCP
# HTTPS-over-TCP (aka HTTP-over-TLS-over-TCP)
https_port 3129
# HTTP-over-TLS (aka HTTP-over-TLS-over-TCP)
# HTTPS-over-TLS (aka HTTP-over-TLS-over-TLS-over-TCP)
SSL-Bump is about decrypting the HTTPS traffic destined to some origin
(not the proxy itself), it has effectively no relation to the transport
(TCP or TLS) used to send that traffic to the proxy. ie. It peeks down
to get the HTTP message layer in those 'aka' stacks.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
