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

Hi Ben.

Thanks for CC-ing netconf-chairs, as I’d forgotten to in my follow up...


> 2. Configuring an HTTP client to connect thru a Proxy
> 
> I think that only once in my career, perhaps a couple decades ago, I had to configure a client to connect thru a proxy.   With that in mind, I ask this question as someone that really doesn’t know what the state of the art is.
> 
> My fuzzy-memory is that, connecting thru an HTTP proxy entailed establishing an HTTP connection to a proxy, and that connection is most likely, if not exclusively, on top of TLS (i.e., HTTPS) and mutually authenticated.
> 
> What you're describing is usually called a "Secure Web Proxy”.

Thanks for clarifying my terminology.


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

Sounds exactly like what the current configuration model enables:

 - client MUST use HTTPS (not HTTP)
 - client MUST auth the secure web proxy's TLS cert 
 - client MAY provide TLS-level client certificate
 - client MAY provide one-of-many HTTP client-auth schemes

To be clear, any combination of TLS-level and/or HTTP-level client-auth (including none) is allowed.

Sounds right?


> That is, in order to configure an HTTP(S) client to connect through a proxy, effectively entails configuring it to establish a second HTTP(S) connection.  That is, a first HTTP(S) connection is *to* the proxy, and a second HTTP(S) connection is *thru* the proxy.   Yes?
> 
> Yes, connections through a Secure Web Proxy have end-to-end TLS "inside" the client-proxy TLS.

Thanks for the confirmation.

Kent