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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users