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

Kent Watsen <> Wed, 20 May 2020 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C1A43A0C01 for <>; Wed, 20 May 2020 09:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uWWV_ijUp5V8 for <>; Wed, 20 May 2020 09:45:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2CE53A0C00 for <>; Wed, 20 May 2020 09:45:08 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jbRnZ-000180-37 for; Wed, 20 May 2020 16:42:29 +0000
Resent-Date: Wed, 20 May 2020 16:42:29 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jbRnX-00017E-Cd for; Wed, 20 May 2020 16:42:27 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from <>) id 1jbRnU-0003cX-G0 for; Wed, 20 May 2020 16:42:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1589992933; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JzcHMhq7qP+IhPm/VpyKqeUPfGqb1c7MsQq8NLrXlYs=; b=YmSm7wZCPAmf0FrZMRq7J0PLBRxekovM0JLE3wZ+arkAYjUAqkgZ4wJNnRn/3Xfs o9OgxoDoenLCaPk1ZUcrF75WG7vkuXEmpVMLycwiFlO2h8tB+4B0xH92L05F68irL+K z/ltD5bbuSq8n3icM+CTiWIX5l9b9IFJ9Fbjk+JY=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADC9346D-A317-41E6-8DE5-B5623F2C3E59"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 20 May 2020 16:42:13 +0000
In-Reply-To: <>
Cc: HTTP Working Group <>, "" <>
To: Ben Schwartz <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.05.20-
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jbRnU-0003cX-G0 ee2df4b58229ba396c5bb0a51b06d08f
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37683
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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.

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 

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) 

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

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

Secure Web Proxy / HTTPS Proxy
Same as above with only the following difference:
Client connects to proxy via TCP
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).