[squid-users] Help troubleshooting proxy<-->client https

[Amos Jeffries]

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