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

From: Kent Watsen <[email-masked]>
Date: Tue, 5 May 2020 17:23:48 +0000

Hi Folks,

This I-D should be of interest to you: draft-ietf-netconf-http-client-server <https://tools.ietf.org/html/draft-ietf-netconf-http-client-server>.   It would be great to get some feedback from the HTTP group!

Mark had asked me to present this work to the HTTP WG @ IETF 107, but I never saw a call for presentations for that meeting.  Upon seeing the recent HTTP virtual interim announcement, I again reached out to Mark, but noting that the VI agenda is packed, he asked me to send an email to the list, which is what this message is about.

Please note that the I-D is being run out the NETCONF WG because it is part of a suite of drafts that have been in progress to configure NETCONF and RESTCONF clients and servers…and HTTP is a base protocol for RESTCONF.  

The NETCONF WG’s goal is for this I-D to be minimally viable.  A previous version had more things in it (e.g., all HTTP authentication schemes), but has since been stripped down to the core.  Its current scope is minimally sufficient for the NETCONF WG's goal…there is no desire to increase its scope on our side.

To get a feel for how the configuration model defined in this draft ties in with the suite of a drafts mentioned above, please see the simplified YANG tree diagrams (RFC 8340) below, pulled from the draft-ietf-netconf-restconf-client-server <https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server> draft.   [Pro tip: the ‘u’ in the diagram stands for “uses”, i.e., where a YANG model pulls in a definition from a grouping.]

FWIW, RESTCONF MUST be layered on top of TLS, as depicted in the “restconf-client” model below but, as a RESTCONF server MAY be fronted by a TLS-terminator (i.e., a load balancer), the “restconf-server” model supports both cases with and 
without the "tls-server-grouping” grouping mixed in.  Important: the ability to mix-in protocol layers as needed is a key aspect of the general approach taken by the NETCONF WG.

   grouping restconf-client
     +-- (transport)
        +--:(https)
           +-- https
              +-- tcp-client-parameters
              |  +---u tcpc:tcp-client-grouping
              +-- tls-client-parameters
              |  +---u tlsc:tls-client-grouping
              +-- http-client-parameters
              |  +---u httpc:http-client-grouping   <-- defined by this I-D
              +-- restconf-client-parameters
                 +---u rcs:restconf-client-grouping

   grouping restconf-server
     +-- (transport)
        +--:(http)
        |  +-- http
        |     +-- external-endpoint!
        |     |  +-- address    inet:ip-address
        |     |  +-- port?      inet:port-number
        |     +-- tcp-server-parameters
        |     |  +---u tcps:tcp-server-grouping
        |     +-- http-server-parameters
        |     |  +---u https:http-server-grouping   <-- defined by this I-D
        |     +-- restconf-server-parameters
        |        +---u rcs:restconf-server-grouping
        +--:(https)
           +-- https
              +-- tcp-server-parameters
              |  +---u tcps:tcp-server-grouping
              +-- tls-server-parameters
              |  +---u tlss:tls-server-grouping
              +-- http-server-parameters
              |  +---u https:http-server-grouping   <-- defined by this I-D
              +-- restconf-server-parameters
                 +---u rcs:restconf-server-grouping

PS:  I’ve CC-ed the NETCONF chairs for visibility, rather than CC the NETCONF list.  If needed, I’ll be the liaison between the two WGs if needed, or we can cross-post if that is deemed better...

Kent (the author of the I-D)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2020 15:07:10 +1000

Hi Kent,

Thanks for that. 

To help people understand what they're looking at, do you have any pointers to documents explaining what RESTCONF is, at a high level? Also, some context on what the model is intended to be used for would be really helpful.

Cheers,

> On 6 May 2020, at 3:23 am, Kent Watsen <[email-masked]> wrote:
> 
> Hi Folks,
> 
> This I-D should be of interest to you: draft-ietf-netconf-http-client-server.   It would be great to get some feedback from the HTTP group!
> 
> To get a feel for how the configuration model defined in this draft ties in with the suite of a drafts mentioned above, please see the simplified YANG tree diagrams (RFC 8340) below, pulled from the draft-ietf-netconf-restconf-client-server draft.   [Pro tip: the ‘u’ in the diagram stands for “uses”, i.e., where a YANG model pulls in a definition from a grouping.]
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 May 2020 17:18:42 +0000

Hi Mark.

> To help people understand what they're looking at, do you have any pointers to documents explaining what RESTCONF is, at a high level? Also, some context on what the model is intended to be used fo…

Yes, of course, silly me!  ;)

RESTCONF (RFC 8040) is an HTTP-variant of NETCONF (RFC 6241, RFC 4741), which is the network management protocol IETF defined roughly 15 years ago to replace SNMP.   Whereas SNMP uses MIBs to define message structures, RESTCONF and NETCONF use YANG (RFC 7950, RFC 6020).   NETCONF is purely an XML-based protocol, whereas RESTCONF uses media-types to define encodings, with current media-types including both JSON and XML.

For years now the IETF has been defining YANG “modules” to describe how to configure and monitor various aspects of a system, with primary emphasis on networking/routing protocols, firewall/ACLs, and the like.  More recently there has been interest in also defining standard modules for system-level management (i.e., how to configure users, access control, Syslog, etc.).  

Thus the desire to define YANG modules for configuring the RESTCONF/NETCONF servers (and clients) running on said networking gear was born.  This is a problem that the NETCONF WG has been working on for nearly 5 years now and, thankfully, it seems that we’re now close to the end of that effort, with the suite of documents nearing a WG last call.

My previous message mentioned how there is a suite of drafts that define “groupings”, snippets of configuration that can be mixed-in to define all the configuration for a protocol stack.  The below diagram depicts the relationship for all 9 IETF drafts in the suite of drafts (simply prefix “draft-ietf-netconf-“ to the name below to get the full draft name).  Notice that the “restconf-client-server” draft depends on the “http-client-server” draft (what this email to the HTTP WG is about).

                                        crypto-types
                                          ^      ^
                                         /        \
                                        /          \
                              trust-anchors       keystore
                                 ^      ^------+    ^
                                 |              \   |
                                 |      +-----------+
                                 |     /          \
 tcp-client-server     ssh-client-server      tls-client-server     http-client-server
       ^      ^              ^                  ^           ^               ^
       |      |              |                  |           |               |
       |      |              |       +----------+           |               |
       |      |              |       |                      |               |
       |      |              |       |                      |               |
       |      +--------------|-------|------------+         |               |
       |                     |       |            |         |               |
       |                     |       |            |         |               |
       +--------------+      |       |            |         |      +--------+
                      |      |       |            |         |      |
                      |      |       |            |         |      |
                   netconf-client-server        restconf-client-server

That’s likely enough context setting.  Of course, please ask questions if there is a desire to know more at this level.   What I think would be more interesting to you all is to see some examples, i.e., where the rubber hits the road…. ;)

Snippet from https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-3.2 <https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-3.2> (please visit to see full example):

   <http-client>
     <client-identity>
       <basic>
         <user-id>bob</user-id>
         <password>secret</password>
       </basic>
     </client-identity>
   </http-client>

This example illustrates how the “http-client-grouping” enables the client’s identity to be configured.  Please recall from my previous message that “basic” is the *only* HTTP authentication scheme supported by the YANG module.  If folks want to use others, whether standards-based or proprietary, they can be “augmented” (a YANG term) as needed. 

Not depicted by this example, is that the “http-client-grouping” also supports the optional configuration of HTTP proxy server settings, in case it is necessary for the HTTP-client to egress thru a proxy server.

And that’s it!  Just the "client-identity" and a "proxy-server” values can be configured in the “http-client-grouping".

PS: in case you’re wondering how the client knows what server to connect to, please note that the remote address/port (which can be a hostname) is configured in the “tcp-client-grouping” mix-in grouping and, likewise, an TLS-level client certificate would be configured in the “tls-client-grouping” mix-in grouping.

Snippet from https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-4.2 <https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-4.2> (please visit to see full example):

   <http-server>
     <server-name>foo.example.com</server-name>
     <protocol-versions>
       <protocol-version>HTTP/1.1</protocol-version>
       <protocol-version>HTTP/2.0</protocol-version>
     </protocol-versions>
   </http-server>

This example illustrates how the “http-server-grouping” enables the HTTP server’s name and supported protocol  versions to be configured.

Not depicted by this example, is that the “http-client-grouping” also supports the optional configuration of HTTP client accounts in order to authenticate incoming HTTP clients against.  Consistent with what was mentioned before, only the “Basic” scheme is supported, while others can be augmented in if needed.

And that’s it!  Just the “server-name”, “protocol-version”, and "client-authentication” values can be configured in the “http-server-grouping".

PS: in case you’re wondering how the server knows what address/port to listen on, please note that the local address/port is configured in the “tcp-server-grouping” mix-in grouping and, likewise, an TLS-level server certificate would be configured in the “tls-server-grouping” mix-in grouping.

Hope that helps!

Kent

> On May 6, 2020, at 1:07 AM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Kent,
> 
> Thanks for that. 
>

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 10 May 2020 11:46:54 +1000

Hi Kent,

Thanks, that's extremely helpful.

Just to be clear, these artefacts are only for configuring their respective components (e.g., http-server-grouping is for interacting with the server to configure it, not for consumption by clients), correct?

Regarding the http-server-grouping - I'm not sure I understand why it's important to configure the version that the server supports. Wouldn't a server just support all of the versions it implements?

Also, what are you using for the values of <protocol-version/>? "HTTP/2.0" is a valid version, but the specification that you're probably referring to is "http/2".

These days, people tend to use ALPN protocol identifiers (which isn't without problem, but it is populated and widely understood): 
  https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Cheers,

> On 7 May 2020, at 3:18 am, Kent Watsen <[email-masked]> wrote:
> 
> Hi Mark.
> 
> Snippet from https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-3.2 (please visit to see full example):
> 
>    <http-client>
>      <client-identity>
>        <basic>
>          <user-id>bob</user-id>
> Snippet from https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-4.2 (please visit to see full example):
> 
>    <http-server>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 11 May 2020 18:57:23 +0000

Hi Mark,

> Just to be clear, these artifacts are only for configuring their respective components (e.g., http-server-grouping is for interacting with the server to configure it, not for consumption by clients), correct?

Correct.  "http-server-grouping" is a building block that is only used to compose a configuration model for an HTTP server.   To develop a configuration model for an HTTP-client, the "http-client-grouping" would be used.

> Regarding the http-server-grouping - I'm not sure I understand why it's important to configure the version that the server supports. Wouldn't a server just support all of the versions it implements?

Maybe.  But my understanding is that older/newer HTTP versions are purposely disabled sometimes for application-level compatibility reasons.  By "application", it may not necessarily be a standard web content server (i.e., it might be an application that uses a REST-based API).

FWIW, the NGINX server configuration file has an "http2" flag in its "listen" directive, and Apache's "Protocols" directive takes values like "h2" and "http/1.1".    To be fair, these directives may only exist to introduce support for new protocol versions (e.g., HTTP/2) in a backwards-compatible manner. 

That said, the NETCONF WG isn't particularly beholden to limiting which HTTP versions a server supports.   If the HTTP WG doesn't think there's any value, then this ability likely should be removed!

> Also, what are you using for the values of <protocol-version/>? "HTTP/2.0" is a valid version, but the specification that you're probably referring to is "http/2".

According to the Section 4.3 in the I-D <https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-02#section-4.3>, the configurable values are "HTTP/1.0", "HTTP/1.1", and "HTTP/2.0".

>  https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

I see "HTTP/1.0" and "HTTP/1.1" in that registry but not "HTTP/2.0".   Regardless, assuming we keep the ability to limit what protocol versions an HTTP server supports (see above discussion), we're happy to use the preferred values (though it seems like that might be the case already).

Thanks for your time engaging in this thread so far.

Kent

> On May 9, 2020, at 9:46 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Kent,
> 
> Just to be clear, these artifacts are only for configuring their respective components (e.g., http-server-grouping is for interacting with the server to configure it, not for consumption by clients), correct?
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 May 2020 10:42:17 +1000

> On 12 May 2020, at 4:57 am, Kent Watsen <[email-masked]> wrote:
> 

I'm not against it per se, it just seems odd to me. 

> According to the Section 4.3 in the I-D, the configurable values are "HTTP/1.0", "HTTP/1.1", and "HTTP/2.0".
> 

HTTP/2 is registered as "h2". You won't see HTTP/2.0 because the protocol is called "HTTP/2" - see RFC7540.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 May 2020 05:44:41 +0200

Hi Kent,

On Mon, May 11, 2020 at 06:57:23PM +0000, Kent Watsen wrote:
> > Regarding the http-server-grouping - I'm not sure I understand why it's
> > important to configure the version that the server supports. Wouldn't a
> > server just support all of the versions it implements?
> 
> Maybe.  But my understanding is that older/newer HTTP versions are purposely
> disabled sometimes for application-level compatibility reasons.  By
> "application", it may not necessarily be a standard web content server (i.e.,
> it might be an application that uses a REST-based API).

As a server-side reverse-proxy developer, I don't think I've ever heard
of a single case where an application required not to use a certain
version due to compatibility issue. Furthermore, applications designed
to work over HTTP/1.1 work pretty fine when the reverse-proxy speaks h2
with the client, and the application doesn't even know, so I'd say this
is totally transparent to the application. The only known interoperability
situation we've found is some rare servers still matching some header
fields in a case-sensitive way, and failing to see them when these
headers come from h2. But this is so rare that a year ago we've switched
everything to lowercase (even HTTP/1) and received extremely few issue
reports (probably a handful among tens to hundreds of thousands of
deployments).

> FWIW, the NGINX server configuration file has an "http2" flag in its "listen"
> directive, and Apache's "Protocols" directive takes values like "h2" and
> "http/1.1".    To be fair, these directives may only exist to introduce
> support for new protocol versions (e.g., HTTP/2) in a backwards-compatible
> manner. 

That's it, and also because the new protocols usually introduce new bugs
that you don't want to expose users to. In haproxy we used to require an
explicit declaration for the first two years, then we've simplified the
configuration and enabled h2 by default, then we recently got caught by a
vulnerability in our implementation, and figured it was so well integrated
that we couldn't disable it anymore! We may reintroduce a tunable for this
but quite frankly, disabling a standard protocol is similar to thinking
about explicitly disabling HTTP/1.1: nobody would find this wise nowadays.

Just my two cents,
Willy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 12 May 2020 20:01:56 +0000

[Top-posting for convenience]

Hi Willy (and Mark!)

Based on yours and Mark's comments, I plan to remove the "protocol-version" field from the "ietf-http-server" YANG module.   As you say, it's seldomly used and, if ever needed, implementations of the "ietf-http-server" YANG module can "augment" (a YANG term) it back in.

Any other comments on draft-ietf-netconf-http-client-server?

Thanks!
Kent

> On May 11, 2020, at 11:44 PM, Willy Tarreau <[email-masked]> wrote:
> 
> Hi Kent,
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 May 2020 22:01:56 +0000

Dear HTTP WG,

I thought that it might be helpful for me to ask a couple specific questions:

1. Supported authentication schemes

My understanding is that there are varying opinions with the schemes listed in the Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry <https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml>.  Partly because some are experimental/historic and partly because some proprietary ones aren’t listed.   Mark impressed upon me before that this draft should try to codify the bare minimum, which I took that to mean just “Basic”, but I’m wondering if there is any harm or even if it would be better, to also support “Digest”?

I’m well aware that both are insecure and require protection from the transport layer, and that Digest really isn’t more secure than Basic but, it seems that they are both pretty much universally supported or, rather, wherever “Basic” is supported, “Digest” seems to be supported also.  Is that in anyway true?

In any case, please be aware the the draft is in no way mandated that any implementation must support any authentication schema.  In YANG terms, the schemes are each individually declared to be supported using a “feature”.  So my question isn’t which schemes must implementations support, but rather which schemes should the standard model make available for implementations to choose to support, knowing that any additional auth schemes (not included in the YANG module) can be “augmented” (another YANG term) in by each implementation per their discretion.   Does that make sense?

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.

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?

Thanks!
Kent

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 16 May 2020 17:17:31 -0400

On Fri, May 15, 2020 at 6:06 PM Kent Watsen <[email-masked]> wrote:

> My understanding is that there are varying opinions with the schemes
> listed in the Hypertext Transfer Protocol (HTTP) Authentication Scheme
> Registry
> <https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml>.
> Partly because some are experimental/historic and partly because some
> proprietary ones aren’t listed.   Mark impressed upon me before that this
> draft should try to codify the bare minimum, which I took that to mean just
> “Basic”, but I’m wondering if there is any harm or even if it would be
> better, to also support “Digest”?
>
> I’m well aware that both are insecure and require protection from the
> transport layer, and that Digest really isn’t more secure than Basic but,
> it seems that they are both pretty much universally supported or, rather,
> wherever “Basic” is supported, “Digest” seems to be supported also.  Is
> that in anyway true?
>
> In any case, please be aware the the draft is in no way mandated that any
> implementation must support any authentication schema.  In YANG terms, the
> schemes are each individually declared to be supported using a “feature”.
> So my question isn’t which schemes must implementations support, but rather
> which schemes should the standard model make available for implementations
> to choose to support, knowing that any additional auth schemes (not
> included in the YANG module) can be “augmented” (another YANG term) in by
> each implementation per their discretion.   Does that make sense?
>
>
>
> 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".  It is a
popular type of proxy but far from the only one.  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.

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 19 May 2020 21:00:22 +0000

Hi Ben.

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

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

> Yes, connections through a Secure Web Proxy have end-to-end TLS "inside" the client-proxy TLS.

Thanks for the confirmation.

Kent

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 May 2020 21:33:36 -0400

On Tue, May 19, 2020 at 5:00 PM Kent Watsen <[email-masked]> wrote:

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

> (including none) is allowed.

Yes.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 May 2020 16:42:13 +0000

Hi Ben,

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

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

> 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