[squid-users] SSL bump, SSL intercept, explicit, secure proxy, what is it called?

[Alex Rousskov]

On 05/24/2017 01:45 PM, Amos Jeffries wrote:
> On 25/05/17 02:17, Alex Rousskov wrote:
>> On 05/24/2017 06:56 AM, Amos Jeffries wrote:
>>> On 24/05/17 13:44, j m wrote:
>>>> So firstly, what is the actual name for what I want (encrypting proxy
>>>> to browser)?

>>> Some people seem to be calling it "HTTPS", but that is not correct and
>>> thankfully makes it difficult to find the bad info.

>> What makes you think that "HTTPS proxy" is an incorrect term? That is
>> the term I have seen used the most, and that is the term I would use.
>> That is also the term that allows to locate relevant documents by
>> googling.
> 
> Two reasons;
> 
> 1) "HTTPS" has a definition (HTTP messages over TLS transport)

... which is exactly what we are discussing: A browser sending HTTP
messages to the proxy, over TLS.


> and a scheme (https://) which explicitly precludes it being used to contact
> forward proxies. 

FWIW, Curl and some other clients use https scheme to configure HTTPS
proxies. Perhaps they are violating some IETF prohibition, but I doubt
that they actually do.


> TLS to a proxy does not have a scheme of its own and
> can carry any protocol the proxy supports, not just HTTP.

Very true and emphasizes why "TLS proxy" does not define much and,
hence, is not a very useful term.


> 2) protocol nesting for HTTPS-over-HTTPS is a very different series of
> layers and message sequence(s) than HTTPS-over-TLS [to a proxy]. In
> particular it is 4 layers deep (one for each "HTTPS").

Yes, but I do not see the relevance. "HTTPS proxy" does not say what is
going on inside the CONNECT tunnels (if any). Yes, supporting HTTPS
proxies/"TLS explicit proxies" in the real world is difficult because
getting HTTPS-over-HTTPS to work is difficult, but what does that have
to do with the terminology?


>>> The current IETF term for it is "TLS explicit proxy".
>> Any supporting references?

> No direct reference sorry - it is not formal and may change

Or it may not be a result of any IETF consensus. Or it may not even exist!


> [a] https://datatracker.ietf.org/doc/draft-loreto-httpbis-trusted-proxy20/

Uses the terms "explicit proxy" and "trusted proxy" not "TLS explicit
proxy".


> [b] https://datatracker.ietf.org/doc/html/draft-rpeon-httpbis-exproxy-01

Uses the terms "configured-proxy" and "trusted-proxy" not "TLS explicit
proxy".

The "explicit" and "trusted" parts are not the problem, of course. It is
the absence of the HTTP part that is a problem IMO when we are trying to
describe a thing that expects [encrypted] HTTP requests.

Alex.