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

Alex Rousskov rousskov at measurement-factory.com
Wed May 24 21:57:47 UTC 2017

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

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

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

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.


More information about the squid-users mailing list