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

[Amos Jeffries]

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) and a 
scheme (https://) which explicitly precludes it being used to contact 
forward proxies. TLS to a proxy does not have a scheme of its own and 
can carry any protocol the proxy supports, not just HTTP.

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").

Both HTTPS and TLS can be used independently to connect to a proxy. The 
differences are discussed at some length in the drafts below [a][b], its 
technically a fine line but the privacy and security implications are 
huge. People talking about one protocol stack while using the terms from 
the other have led to a lot of deadlocked arguments already.



>
>> The current IETF term for it is "TLS explicit proxy".
> Any supporting references? Neither Google nor I remember that term, and
> the term itself seems inferior to "HTTPS proxy" -- the proxy in question
> expects HTTP traffic underneath TLS so "HTTPS proxy" fits better IMHO.his

No direct reference sorry - it is not formal and may change, thus 
"current". It is what the sub-group of the WG have been using to discuss 
the case of "TLS (explicit)" connections made to an explicit proxy (see 
that 4-word -> 3-word redux?) since the long discussions instigated by 
the loreto draft[a] has effectively burned the term "trusted proxy" and 
"HTTPS proxy" into being HTTPS protocol stack to a proxy, and the rpeon 
draft[b] has formalized the term "explicit proxy" as what used to be the 
defacto standard "forward-proxy" with again "trusted proxy" being full 
decryption at the proxy.

[a] <https://datatracker.ietf.org/doc/draft-loreto-httpbis-trusted-proxy20/>
[b] <https://datatracker.ietf.org/doc/html/draft-rpeon-httpbis-exproxy-01>


Amos