Re: I-D for a YANG data model to configure HTTP clients and servers

Hi Ben,

Thank you for your previous response.  I spent some time reading up on proxies.  A few comments below.


>> What you're describing is usually called a "Secure Web Proxy”.
> 
> Thanks for clarifying my terminology.

Actually, it seems that “HTTPS Proxy” is equally used, perhaps more so…

Additionally, it seems “HTTP Proxy” (without the ’S’) is also a thing…would this be just a “Web Proxy” using your nomenclature?


>> It is a popular type of proxy but far from the only one.
> 
> I don’t understand this comment, especially in context of the next comment…
> 
> 
>> The client always  authenticates the server name (in the usual way with TLS), but servers might or might not require clients to authenticate, and might do so in many different ways.
> 
> 
> This comment was in reference to a Secure Web Proxy.  When using a SOCKS5 proxy, in contrast, there is typically no use of TLS between client and proxy (although there will still be end-to-end TLS if the proxied connection is for HTTPS).

Here’s my current understanding:
   - it's a lot to review, but I’d be incredibly grateful if you could try...


SOCKS4
Very common today still
Client connects to proxy using TCP
Client can send any TCP-based protocol through the proxy, not just HTTP(S)
Ref: "SOCKS", Proceedings: 1992 Usenix Security Symposium.

SOCKS4a
Extends SOCKS4 to enable client to specific a domain name rather than an IP address
A non-standard SSH-originated term for when the proxy resolves the URL hostname 
Ref: https://www.openssh.com/txt/socks4a.protocol

SOCKS5
Builds on top of SOCK4a to add support for UDP and authentication
Notably does NOT enable TLS-connect to the proxy (e.g., to protect the auth)
For UDP, client first connects to proxy via TCP in order to obtain an allocated UDP port to make a subsequent connection to
Various auth mechanisms supported (inc. cleartext username/password) 
Ref: https://tools.ietf.org/html/rfc1928

SOCK5h
A non-standard CURL-specific term for when the proxy resolves the URL hostname
Not an extension of RFC 1928, so much as a CLI-disambiguator
Ref: https://curl.haxx.se/libcurl/c/CURLOPT_PROXY.html

Web Proxy / HTTP Proxy
Client connects to proxy via TCP
Client sends HTTP request to destination webserver
If the “http” scheme is used, then proxy connects to destination server using TCP
If the “https” scheme is used, then proxy connects to destination server using TLS
Proxy MAY auth the destination TLS server’s EE cert
e.g., CURL’s “--ca-cert” parameter 
Proxy MAY send a client-cert to destination TLS server
e.g., CURL’s “--key” and “--cert” parameters still work
HTTP-level auth to the proxy NEVER required?
HTTP-level auth to the destination HTTP server MAY be required
Ref: https://tools.ietf.org/html/rfc7230

Secure Web Proxy / HTTPS Proxy
Same as above with only the following difference:
OLD
Client connects to proxy via TCP
NEW
Client connects to proxy via TLS
Client auths proxy’s EE cert
e.g., CURL’s “--proxy-cacert” parameter
TLS-level client-auth to proxy MAY be required
e.g., CURL’s "--proxy-cert” parameter
SRP-level client-auth MAY be required?
e.g., CURL’s “—tlsauthtype” parameter


PS: It’s also possible for an HTTP client to first connect to a SOCKS server, and then connect to a HTTP(S) Proxy thru the SOCKS server, in order to reach a destination web server (e.g.,CURL’s "--preproxy” parameter).

Kent