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