Subject: Yet another trusted proxy suggestion

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Nov 2013 14:16:25 +0200

So after several threads, both here and and in private, I get a feeling 
that the opposition is more to breaking TLS than to having an HTTP(S) proxy.

Given that, I would like to lay out a a proposal for the flow of proxy 
detection and usage, without getting too low-level.

As an example, we'll assume there's a user, [email-masked], who uses 
her computer to download something from https://download.adobe.com.  
There are two proxies involved in this:
  - one is a next-generation firewall: sslproxy.example.com
  - one is a CDN server called a1953.d.cdn.net

Note that under this scenario, a1953.d.cdn.net resolves to the same IP 
address (192.0.2.5) as download.adobe.com. Maybe this can be improved, 
but that's how CDNs work for now.

Another thing to note is that there are actually two entities in the 
first part. There's the proxy, which deals in HTTP(S), and then there's 
the firewall which prevents E2E communications. They may be co-located, 
but then don't have to be.

Step #1
=======
The browser resolves download.adobe.com, and opens a connection to 
192.0.2.5 port 443. The firewall blocks this. I'm not sure it it's 
preferable to block this with some ICMP or with a new TLS alert (so the 
firewall completes the 3-way TCP handshake, receives the ClientHello and 
only then sends the error), but I'm tending towards the latter. The new 
TLS alert is called "mandatory proxy" and contains the URL of that 
proxy: https://sslproxy.example.com:443

Step #2
=======
The browser consults local policy about whether such a proxy might be 
acceptable, and if so, opens a new TLS connection to the proxy and 
verifies the certificate. This allows adding some clever UX that shows 
the user what device is on-path, and also allows pre-configuring the 
trusted proxy based on name.

Step #3
=======
The browser sends a CONNECT command to the proxy (maybe that has to be 
enhanced as well?) to connect to https://download.adobe.com. The proxy 
tries to connect, and then either of two things happens:
  1. a1953.d.cdn.net has a certificate for download.adobe.com - that is 
what we do today.
  2. a1953.d.cdn.net has a certificate for a1953.d.cdn.net, and issues a 
"mandatory proxy" alert with its name.
In the former case, things will work as today. In the latter case, I'm 
not sure how the proxy (or browser for that matter) can know that 
a1953.d.cdn.net is a trusted proxy for download.adobe.com. Having the 
private key is a good indication, but I think we want to get away from that.
Either way, the connection is established

Step #4
=======
If there is some personalized information, the CDN server can open a 
connection to the real server. This time there is a pre-arrangement, so 
the names in the certificate may be different.

Step #5
=======
Requests and responses go through the series of nodes. We should note 
that things like flow control are hop-by-hop, so the SETTINGS frame is 
not forwarded, but is hop-by-hop. We would also like to have some 
information for both client and server. Here's my suggestion for this:
ClientInfo structure:
  - certificate chain sent by the client (if any)
  - ciphersuite used
  - this)proxy certificate chain.
  - subject (or SKID) of received server (or next proxy) certificate

ServerInfo structure:
  - certificate chain sent by the server (or another proxy)
  - ciphersuite used
  - subject (or SKID) or (this) proxy certificate

Each proxy sends a ClientInfo structure to the server. This could be 
done as a POST to a /.well-known URI or as a new special frame. I prefer 
the latter, but I don't know how well that will sit with several proxies 
trying to push the same resource to the server.
Each proxy also sends a ServerInfo structure to the client. Again, this 
could be a pushed resource or a special frame. Same concern applies.

Step #6
=======
At the end of this, both client and server can construct the chain of 
certificate chains and the ciphersuite used in each leg of the trip.

TLS is not changed by this, but HTTPS is.

I'd love to hear comments on this. If there's interest I could write it 
up in a draft, but having been burned twice, I'd like to know there's 
interest first.

Yoav

---

From: Roland Zink <[email-masked]>
Date: Tue, 26 Nov 2013 13:34:17 +0100

Step #3
>  2. a1953.d.cdn.net has a certificate for a1953.d.cdn.net, and issues 
> a "mandatory proxy" alert with its name.
Is the Connect like in HTTP/1.1 the CONNECT method opening a TLS 
connection from the client to the CDN (TCP from proxy to CDN)? Or is 
this only opening a TLS connection from the proxy to the CDN? I'm 
assuming it is the latter.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Nov 2013 14:49:31 +0200

On 26/11/13 2:34 PM, Roland Zink wrote:
> Step #3
>> =======
>> The browser sends a CONNECT command to the proxy (maybe that has to 
>> be enhanced as well?) to connect to https://download.adobe.com. The 
>> proxy tries to connect, and then either of two things happens:
>>  1. a1953.d.cdn.net has a certificate for download.adobe.com - that 
>> is what we do today.
>> In the former case, things will work as today. In the latter case, 
>> I'm not sure how the proxy (or browser for that matter) can know that 
> assuming it is the latter

I don't think a "trusted proxy" would allow us to just tunnel TLS, so 
it's a different thing. It tells the proxy to open the connection 
onwards. Could be a new method or a special frame.

Yoav

---

From: Patrick McManus <[email-masked]>
Date: Tue, 26 Nov 2013 08:55:35 -0500

Yes, please be explicit on this point - CONNECT currently gives end to end
assurances through a proxy and your proposal turns that on its head. To
ensure clarity I would appreciate it if you didn't reuse CONNECT when
proposing Explicit MITM proxy semantics.

While we're at it, imo, E-MITM is a much clearer term than the trusted
proxy euphemism being used.

IMO and somewhat separately - the notion of a1953.d.cdn.net being able to
present some kind of assertion (outside of the TLS handshake) provably
signed by download.adobe.com that says the cdn host is allowed to serve
content for download.adobe.com is something we ought to explore. I wouldn't
wrap that up in the client side proxy discussions though.

On Tue, Nov 26, 2013 at 7:49 AM, Yoav Nir <[email-masked]> wrote:

>> connection from the client to the CDN (TCP from proxy to CDN)? Or is this
>> only opening a TLS connection from the proxy to the CDN? I'm assuming it is
>> the latter
>>
>
> I don't think a "trusted proxy" would allow us to just tunnel TLS, so it's
> a different thing. It tells the proxy to open the connection onwards. Could
> be a new method or a special frame.
>
> Yoav
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 26 Nov 2013 15:03:24 +0000

in my view a "trusted proxy" should allow to tunnel TLS exactly as a proxy in HTTP1.1
why should behave in a different way in 2.0?

On Nov 26, 2013, at 3:55 PM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

Yes, please be explicit on this point - CONNECT currently gives end to end assurances through a proxy and your proposal turns that on its head. To ensure clarity I would appreciate it if you didn't reuse CONNECT when proposing Explicit MITM proxy semantics.

While we're at it, imo, E-MITM is a much clearer term than the trusted proxy euphemism being used.

no it is not MITM is usually used to talk about a security attack.
Here we are talking of an intermediary that explicit signal the presence and that disclosure somehow whatever it is going to do.
Actually it should be only possible for the proxy to do what the UA agree with it

/Sal

IMO and somewhat separately - the notion of a1953.d.cdn.net<http://a1953.d.cdn.net/> being able to present some kind of assertion (outside of the TLS handshake) provably signed by download.adobe.com<http://download.adobe.com/> that says the cdn host is allowed to serve content for download.adobe.com<http://download.adobe.com/> is something we ought to explore. I wouldn't wrap that up in the client side proxy discussions though.

On Tue, Nov 26, 2013 at 7:49 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
On 26/11/13 2:34 PM, Roland Zink wrote:
Step #3
=======
The browser sends a CONNECT command to the proxy (maybe that has to be enhanced as well?) to connect to https://download.adobe.com<https://download.adobe.com/>. The proxy tries to connect, and then either of two things happens:
 1. a1953.d.cdn.net<http://a1953.d.cdn.net/> has a certificate for download.adobe.com<http://download.adobe.com/> - that is what we do today.
 2. a1953.d.cdn.net<http://a1953.d.cdn.net/> has a certificate for a1953.d.cdn.net<http://a1953.d.cdn.net/>, and issues a "mandatory proxy" alert with its name.
In the former case, things will work as today. In the latter case, I'm not sure how the proxy (or browser for that matter) can know that a1953.d.cdn.net<http://a1953.d.cdn.net/> is a trusted proxy for download.adobe.com<http://download.adobe.com/>. Having the private key is a good indication, but I think we want to get away from that.
Either way, the connection is established

Is the Connect like in HTTP/1.1 the CONNECT method opening a TLS connection from the client to the CDN (TCP from proxy to CDN)? Or is this only opening a TLS connection from the proxy to the CDN? I'm assuming it is the latter

I don't think a "trusted proxy" would allow us to just tunnel TLS, so it's a different thing. It tells the proxy to open the connection onwards. Could be a new method or a special frame.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Nov 2013 10:47:40 -0800

On 26 November 2013 04:16, Yoav Nir <[email-masked]> wrote:
> This allows adding some clever UX that shows the user what device is
> on-path, and also allows pre-configuring the trusted proxy based on name.

I'm interested in learning what that clever UX looks like.  A lot hinges on it.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 26 Nov 2013 20:09:00 +0000

I don't see any point in using a CONNECT style of approach if you trust 
the proxy.  What sort of connection is that? If TLS, then why not just 
use a GET https:// approach.

As for using a mandatory proxy on the server end, I don't really see a 
requirement for that.  People use reverse proxies for sure, but they 
just appear from the outside to be a server.  I think if we allowed 
assertion of mandatory proxy use outside a trusted environment (e.g. the 
user's LAN) then we would have major problems getting it accepted.

As for whether this is a MITM.  I believe it is not, but not for the 
reasons given (in a prev response to this).

It's not MITM, because in this case the proxy is not pretending to be 
the server.  It's not spoofing any certs, it's just accepting a 
connection and making one on behalf.  The only real difference is the 
proxy took on the job of TLS to the server.

Adrien

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "HTTP Group" <[email-masked]>
Sent: 27/11/2013 1:16:25 a.m.
Subject: Yet another trusted proxy suggestion
>firewall completes the 3-way TCP handshake, receives the ClientHello 
>and only then sends the error), but I'm tending towards the latter. The 
>new TLS alert is called "mandatory proxy" and contains the URL of that 
>done as a POST to a /.well-known URI or as a new special frame. I 
>prefer the latter, but I don't know how well that will sit with several 
>proxies trying to push the same resource to the server.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 26 Nov 2013 20:11:14 +0000

I had some thoughts about this.

Chrome has the "incognito" frame.  You could use a different browser 
frame.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Nov 2013 13:10:16 -0800

On 26 November 2013 12:11, Adrien de Croy <[email-masked]> wrote:
> Chrome has the "incognito" frame.  You could use a different browser frame.

So rather than the masked man (or the fancy masquerade sham in
Firefox), you would have what, this:
http://ts2.mm.bing.net/th?id=H.4858996483622041&pid=1.7?

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 26 Nov 2013 21:12:32 +0000

perfect!

---

From: Roberto Peon <[email-masked]>
Date: Tue, 26 Nov 2013 13:13:47 -0800

I like it.

---

From: James M Snell <[email-masked]>
Date: Tue, 26 Nov 2013 13:16:12 -0800

Looks like we've finally reached a consensus.

Mark: is there going to be free beer now?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Nov 2013 23:40:36 +0200

> http://ts2.mm.bing.net/th?id=H.4858996483622041&pid=1.7?
Or this:
http://cyclestuff.files.wordpress.com/2012/11/eye-of-sauron.jpg
Or maybe this:
http://www.calwatchdog.com/wp-content/uploads/2011/07/big-brother-is-watching-you4.jpg

But it is worth considering what a UI tells the user. Certificate errors 
were notoriously ineffective, and part of this is because the message 
had to be ambiguous, like "this site is not certified by a trusted root. 
So, 9 times out of 10 this is just a harmless misconfiguration, or 
they're too cheap to buy a real certificate, but every once in a while 
it's really an attack."

For this we have the luxury of being able to be unambiguous: "The 
network has an HTTPS monitor called sslproxy.example.com that will 
decrypt all HTTPS traffic. Any passwords, credit card numbers and 
personal information will be visible to this proxy. Click <a 
href="https://sslproxy.example.com/.well-known/proxy-terms-of-use.html>here</a> 
to learn more about this proxy.".  It's tempting to add a "Trust this 
proxy" button there, or Firefox's "I understand the risks" (no, you 
don't). But I guess training users to click this button is bad practice. 
Better to give them instructions about how to configure their particular 
browser to trust this proxy through menus or about:config.

But regardless, a visual indication of the existence of the proxy is a 
benefit that we're missing with the MitM we have today. We could have 
warnings before typing in password fields or fields marked as credit 
card number.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Nov 2013 21:49:04 +0000

First, thanks all for being willing to move the discussion
up a layer.

Second, I couldn't resist...

On 11/26/2013 09:40 PM, Yoav Nir wrote:
> "The network has an HTTPS monitor called 
...fe80::aaaa:bbbb:cccc:dddd/64

Hmm. That'll work nicely:-)

Seriously though there are a lot of things to get right,
and things that might be broken by accident, for any
proposal for this http proxying stuff.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Nov 2013 09:49:36 +1100

Hi Yoav,

Thanks for this. A few initial impressions below.

On 26 Nov 2013, at 11:16 pm, Yoav Nir <[email-masked]> wrote:

> So after several threads, both here and and in private, I get a feeling that the opposition is more to breaking TLS than to having an HTTP(S) proxy.
> 
> Given that, I would like to lay out a a proposal for the flow of proxy detection and usage, without getting too low-level.
> 
> As an example, we'll assume there's a user, [email-masked], who uses her computer to download something from https://download.adobe.com.  There are two proxies involved in this:
> Note that under this scenario, a1953.d.cdn.net resolves to the same IP address (192.0.2.5) as download.adobe.com. Maybe this can be improved, but that's how CDNs work for now.

I’m not sure what “improved” is here. What are you trying to fix? 

> Another thing to note is that there are actually two entities in the first part. There's the proxy, which deals in HTTP(S), and then there's the firewall which prevents E2E communications. They may be co-located, but then don't have to be.

Right. Another way to say this is that connections can be refused at the HTTP layer, or at a lower layer, and clients need to deal with both.

HTTP refusals *could* be more information-rich, if we choose to enable that (as I touched upon in draft-notthingham-http-proxy-problem).

> Step #1
> =======
> The browser resolves download.adobe.com, and opens a connection to 192.0.2.5 port 443. The firewall blocks this. I'm not sure it it's preferable to block this with some ICMP or with a new TLS alert (so the firewall completes the 3-way TCP handshake, receives the ClientHello and only then sends the error), but I'm tending towards the latter. The new TLS alert is called "mandatory proxy" and contains the URL of that proxy: https://sslproxy.example.com:443

That seems like it’s changing TLS to accommodate proxying, which Stephen was vehemently against...

When I’ve thought about this use case, I’ve been assuming that the MITM/Portal/Firewall/Whatever would negotiate TLS with its *own* certificate and then present a HTTP status code whose semantic is explicitly “This message is from a part of your network infrastructure; it is not from the origin” so that the client could present/use it as such (importantly, for purposes of cert validity as well as source of content).

That seems to stay in HTTP, making Stephen happy, and also gives a richer, more developer-friendly path to proxy-to-UA communication…

> Step #2
> =======
> The browser consults local policy about whether such a proxy might be acceptable, and if so, opens a new TLS connection to the proxy and verifies the certificate. This allows adding some clever UX that shows the user what device is on-path, and also allows pre-configuring the trusted proxy based on name.

Nod. I get a little nervous about us defining such policy languages (been burned in the past), but OK.

> Step #3
> =======
> The browser sends a CONNECT command to the proxy (maybe that has to be enhanced as well?) to connect to https://download.adobe.com. The proxy tries to connect, and then either of two things happens:
> 1. a1953.d.cdn.net has a certificate for download.adobe.com - that is what we do today.
> 2. a1953.d.cdn.net has a certificate for a1953.d.cdn.net, and issues a "mandatory proxy" alert with its name.
> In the former case, things will work as today. In the latter case, I'm not sure how the proxy (or browser for that matter) can know that a1953.d.cdn.net is a trusted proxy for download.adobe.com. Having the private key is a good indication, but I think we want to get away from that.

See other comments about CONNECT.

WRT #2, this sounds like it’s effectively “certificate delegation,” which has been discussed casually since Berlin (I think you were in on some of those discussions). There are some really interesting use cases for this, but we need to consider the security properties carefully.

> Step #4
> =======
> If there is some personalized information, the CDN server can open a connection to the real server. This time there is a pre-arrangement, so the names in the certificate may be different.

More detail here? 

> 
> Step #5
> =======
> Requests and responses go through the series of nodes. We should note that things like flow control are hop-by-hop, so the SETTINGS frame is not forwarded, but is hop-by-hop. We would also like to have some information for both client and server. Here's my suggestion for this:
> ClientInfo structure:
> Each proxy sends a ClientInfo structure to the server. This could be done as a POST to a /.well-known URI or as a new special frame. I prefer the latter, but I don't know how well that will sit with several proxies trying to push the same resource to the server.
> Each proxy also sends a ServerInfo structure to the client. Again, this could be a pushed resource or a special frame. Same concern applies.

Is this all inside of HTTP/2? I.e., are we talking about new frame types for ClientInfo and ServerInfo (as per previous discussion)?

> 
> Step #6
> =======
> At the end of this, both client and server can construct the chain of certificate chains and the ciphersuite used in each leg of the trip.
> 
> I'd love to hear comments on this. If there's interest I could write it up in a draft, but having been burned twice, I'd like to know there's interest first.

Definitely interesting.

Cheers,

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

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 27 Nov 2013 21:40:19 +0100

> user's LAN) then we would have major problems getting it accepted.

I had the case of an entity that used an authenticating proxy to protect
outside access to their internal webapps. So getting access for our users
to their apps would have required chaining two proxies

web client on corp1 lan → corp1 outbound auth proxy → Internet → corp2
inbound auth proxy → webapp on corp2 land

And of course corp1 and corp2 secrets were not shared, only users with
dual affiliation had a login on both proxies.

This is a real and current use-case, not a though experiment.

Regards,

-- 
Nicolas Mailhot

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Nov 2013 20:58:31 +0000

> dual affiliation had a login on both proxies.

I'm not sure how that actually works with http/1.1 - does it
really?

> This is a real and current use-case, not a though experiment.

Anyway, I'm not sure if you mean HTTP Proxy-Authorization there
or if it can be done another way, but if a side-effect of this
work on proxies is that that header field gets protected by a
TLS session between the client and proxy then that'd be a good
thing since sending Basic or Digest credentials in clear is not
a good thing for sure. (So maybe there will be one thing about
this proxy stuff that I do like:-)

I've never heard of that two-proxies-in-a-row wanting to use
Proxy-Authorization though and didn't think it could work.

S.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Nov 2013 23:05:10 +0200

> I’m not sure what “improved” is here. What are you trying to fix?

Nothing, really. It always seemed like an abuse of DNS, but I don't know 
enough about DNS to make such a statement.
> HTTP refusals *could* be more information-rich, if we choose to enable that (as I touched upon in draft-notthingham-http-proxy-problem).

That is true, but Is a client is trying to open a direct HTTPS 
connection to 192.0.2.5, there are three layers at which the firewall 
might redirect it:

  * At the IP (or is it the TCP) layer via an ICMP message. These
    typically don't carry much information, and getting that information
    through all the layers to the application is hard to standardize (I
    don't think you can even do it with the plain libc APIs).
  * At the TLS layer. To do that, the firewall must pretend to be the
    server for the 3-way TCP handshake. After that, it can respond with
    a TLS alert to the ClientHello, and we can stuff some information
    into the alert.
  * At the HTTP layer. This is the most information-rich, but to get
    there you need to make the TLS handshake succeed. That requires a
    TLS MitM, and I thought that was exactly what we were trying to avoid.

> That seems like it’s changing TLS to accommodate proxying, which Stephen was vehemently against...
Sure. But this step #1 is just a discovery mechanism. Clients that are 
pre-configured can proceed to Step #2. It just becomes messy with 
clients that move around, and don't always have the proxy.
> That seems to stay in HTTP, making Stephen happy, and also gives a richer, more developer-friendly path to proxy-to-UA communication…
Sure, but that can happen only after the client (somehow) found out that 
the proxy is there.
> See other comments about CONNECT.
Yeah. Definitely should be a simple "GET https://download.adobe.com/".
> WRT #2, this sounds like it’s effectively “certificate delegation,” which has been discussed casually since Berlin (I think you were in on some of those discussions). There are some really interest…
And as others have said, this server-side proxy discussion should be 
separate from the client-side proxy discussion.
>> If there is some personalized information, the CDN server can open a connection to the real server. This time there is a pre-arrangement, so the names in the certificate may be different.

I just think that the pipe between CDN and content provider should be 
out of scope. This is not some random https connection with no 
pre-arranged trust. This is a connection between entities that have a 
legal contract between them  - real contract, not the "terms and 
conditions" kind. So whether they use TLS or HTTP over an IPsec tunnel 
is not something that we should be concerned about. In any case, that's 
part of the server-side proxy discussion, so it belongs off of this thread.

> Is this all inside of HTTP/2? I.e., are we talking about new frame types for ClientInfo and ServerInfo (as per previous discussion)?
This could be done either way. It could be new frame types, or it could 
be POSTs and pushed resources to well-known URIs. I can see pros and 
cons either way, but I tend to prefer the latter.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 27 Nov 2013 22:18:15 +0100

> I'm not sure how that actually works with http/1.1 - does it

I freely admit we could not get it to work which made those
dual-affiliated users greatly cross with IT. We would definitely be
interested in upgrading our hardware to http/2 if it could solve such
use-cases, we do not enjoy making users miserable.

Cheers,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 27 Nov 2013 22:24:06 +0100

Le Mer 27 novembre 2013 22:05, Yoav Nir a écrit :

> is not something that we should be concerned about.

However, both the user-agent or any corp proxy would like to differentiate
between cdn-traffic-for-foo and cdn-traffic-for-bar. The trust problem
does not stop at the cdn level.

For one that would allow the proxy operator to special-case
cdn-traffic-for-foo without any side-effect on
cdn-traffic-for-someone-else (for example we definitely want to authorise
our akamaihd videos without having users slurp all the other videos
akaimaihd pushes)

Cheers,

-- 
Nicolas Mailhot

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 28 Nov 2013 11:22:15 +1300

> use-cases, we do not enjoy making users miserable.

HTTP auth framework is quite flexible. Squid can configure exactly this 
in any one of several ways:

* end users have a login to proxy1 in corp1.

method 0)
  corp2 configure their proxy2 as a reverse proxy accepting www-auth 
headers. Login to proxy1 proceeds as normal with proxy-auth headers for 
credentials. Login to proxy2 proceeds as normal with www-auth headers 
for credentials.
  Any separate login within corp2 to the app service itself is corp2's 
problem. But it should not be hard since they control the credentials 
and access to both proxy2 and the app. if not then one of the below 
methods will be needed.

method 1)
  corp1 has an organization level set of credentials to access corp2 via 
proxy2. This is configured in proxy1 along with access controls 
responsible for gatekeeping particular end-users access to corp2 on the 
authenticated channel.

method 2)
   corp1 and corp2 have federated single-sign-on credentials for each 
corp1 user. proxy1 simply passes along the authentication headers 
instead of stripping as hop-by-hop (or re-instates a new hop-by-hop 
header with the same field values.

method 3)
   corp1 and corp2 have fully independent sets of credentials. corp1 
maintains an administrative system for allocating and managing its users 
credentials for corp2. proxy1 is configured such that outgoing traffic 
sent to proxy2 is assigned the credentials from said system based on 
(perhapse even encrypted by) the users authenticated proxy1 credentials.

The particulars are off-topic I think. So drop me a line if you want 
more on specific config.

Amos

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Nov 2013 09:51:49 +0200

Hi,

After receiving some feedback, I'm revising this proposal by removing 
the CDN and CONNECT.

Assume there's a user, [email-masked], who uses her computer at work 
to download something from https://download.adobe.com. Her company hasa 
next-generation firewall called sslproxy.example.com. Alice is aware of 
this proxy, but has been told that the proxy is only used for detecting 
malware and blocking time wasters like Farmville and OKBridge. 
Specifically the IT people and her bosses do not have access to the 
plaintext. This is not enforced in any technical way - but Alice trusts 
the IT department to keep their word.

Another thing to note is that there are actually two components to the 
mandatory proxy. There's the proxy, which deals in HTTP(S), and then 
there's the firewall which prevents E2E communications. They may be 
co-located, but then don't have to be.

Step #1 - Where the browser detects the proxy
=============================================
[If everything is pre-configured, this step may be skipped, but that 
makes moving to another network where that particular proxy is not 
present more difficult.]
The browser resolves download.adobe.com, and opens a connection to 
download.adobe.com port 443. The firewall blocks this. I'm not sure it 
it's preferable to block this with some ICMP or with a new TLS alert (so 
the firewall completes the 3-way TCP handshake, receives the ClientHello 
and only then sends the error), but I'm tending towards the latter. The 
new TLS alert is called "mandatory proxy" and contains the URL of that 
proxy: https://sslproxy.example.com:443

Step #2 - Connecting to the proxy
=================================
The browser consults local policy about whether such a proxy might be 
acceptable, and if so, opens a new TLS connection to the proxy and 
verifies the certificate. This allows adding some clever UX that shows 
the user what device is on-path, and also allows pre-configuring the 
trusted proxy based on name.
I realize that this is where security will be made or broken. It's 
tempting to solve this with some message like this:
+-----------------------------------------------------------------------+
| Warning: an HTTPS proxy was detected on the path to                   |
| download.adobe.com.  The proxy is identified as _sslproxy.example.com_ |
| |
| This proxy will be able to read all traffic, including any passwords, |
| credit card numbers, and personal information. Do not proceed unless  |
| you trust this proxy.                                                 |
| |
|  +-----------------------+  +--------------------------+ +--------+  |
|  | Trust this proxy once |  | Trust this proxy forever |  | Cancel |  |
|  +-----------------------+  +--------------------------+ +--------+  |
+-----------------------------------------------------------------------+

In its favor, it's more clear-cut than certificate warnings that are 
always vague because most certificate errors are misconfiguration rather 
than a real attack. OTOH that "Trust this proxy forever" button is 
really tempting, because it makes the Internet work, as opposed to it 
being blocked. You can send the users off to the browser settings with a 
complex task to perform. This will both give the user time to think if 
it's really OK, and will make wifi providers for places like restaurants 
and airports think twice before deploying this kind of thing.

Step #3 - Connecting to the real server
=======================================
The browser sends requests through the proxy (in HTTP/1 notation: "GET 
https://download.adobe.com"). The proxy tries to connects and does 
whatever verification it is configured to do. We might need some HTTP 
error status codes to indicate SSL failure.

Step #4 - Path information
==========================
As there may be multiple proxies on path, requests and responses go 
through the series of nodes. We should note that things like flow 
control are hop-by-hop, so the SETTINGS frame is not forwarded, but is 
hop-by-hop. We would also like to have some information for both client 
and server. Here's my suggestion for this:
ClientInfo structure:
  - certificate chain sent by the client (if any)
  - ciphersuite used
  - this)proxy certificate chain.
  - subject (or SKID) of received server (or next proxy) certificate

ServerInfo structure:

Step #5 - Conclusion
=====================
At the end of this, both client and server can construct the chain of 
certificate chains and the ciphersuite used in each leg of the trip. 
This allows each of them to make policy decisions about whether the 
certificates on the path are all trusted, and whether the ciphersuites 
are good enough. It also allows the user to show some nifty UI that 
shows the series of proxies on the way.

An advantage for proxy vendors is that this allows the removal of two 
limitations that MitM proxies currently have:

 1. The missing EV indications - by sending the actual certificate chain
    to the user, the browser could verify that an EV indication is
    appropriate (subject to browser policy). It would be strange to have
    both an indication of extended validation and an indication of an
    HTTPS proxy, but sometimes weird things make sense.
 2. Missing support for client authentication - by sending the client
    certificate from the client-side proxy to the server, the server can
    (at an application level) assign a user identity to the session. It
    should be noted that this requires the server to trust the proxy for
    this to work. It might be enough that the client trusts the proxy,
    but it might not be.

TLS is not changed by this proposal except for the alert, but HTTPS is.

I'd love to hear more comments on this. If there's interest I could 
write it up in a draft, but having been burned twice, I'd like to know 
there's interest first.

Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 28 Nov 2013 09:25:24 +0100

> in any one of several ways:

And those all suppose that either corp2 changes its proxy not to use proxy
auth (tells a lot about how broken http1 auth is) or that corp1 takes over
credential management for dual-affiliated users (which won't really work
since the whole point is to have corp1 and corp2 credential organisations
ignore each other, since they both target their own organisation
specifics)

Regards,

-- 
Nicolas Mailhot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Nov 2013 10:28:22 +0100

On 11/26/13 10:40 PM, Yoav Nir wrote:
> don't). But I guess training users to click this button is bad
> practice. Better to give them instructions about how to configure
> their particular browser to trust this proxy through menus or
> about:config.
>

When Mark did his proxy draft, what I was kicking around were scaling
approaches to what you've written above.  What's more, there are often
different proxies in path for different purposes.  The mechanism has to
be both iterative and yet it must not "nag the user".  The permission
model must be robust to such circumstances, especially in a mobile world.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Nov 2013 09:37:22 +0000

Hi Yoav,

> write it up in a draft, but having been burned twice, I'd like to know

I think your caution is wise.

Let me ask one of the possibly many hard questions: say I'm a bank,
wouldn't the result of your proposal be that I'd not be able to
turn on HTTP/2.0 because e.g. one of my regulators somewhere would
forbid me agreeing to exposing my customer's credentials to one
or more such proxies?

I'd love if we had a real bank asking that question btw, since
I'm just guessing, and am not and never have been a bank:-) But
we don't seem to have anyone like that on the list asking.

Ta,
S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Nov 2013 13:15:23 +0200

> forbid me agreeing to exposing my customer's credentials to one
First, nothing in my proposal (except maybe the pushed resource, which 
could be easily replaced with a pulled resource) is unique to HTTP/2. 
This is equally applicable to HTTP/1.

Second, there are now MitM proxies that expose customers' credentials. 
To defend against them, the bank has several options:

  * Deploy HPKP with the "strict" directive. Can't say that's widely
    deployed, although I'm told it is implemented in Chrome. You have
    multiple ways of bricking your site if you're not careful with this,
    so it's WebSec's version of five finger fillet.  But banks can
    afford to do it correctly.
  * Deploy client certificates for users. This defeats all TLS proxies,
    unless you come up with a proxy that somehow gets the user's private
    key. It doesn't get any more "trusted" than that. Very few banks do
    this.

If they have a policy like you suggested, and they don't use the above 
measures, they're not enforcing their policy now.

With this proposal they can enforce their policy, allowing users to 
connect without a proxy, and not allowing them to connect with it. Seems 
like a positive to me.

> we don't seem to have anyone like that on the list asking.

I don't think it counts, but I did interview at a bank before going to 
work at Check Point, although that was for a systems administration job, 
not a security job.

Banks are into cost cutting, and the way to get costs lower is to avoid 
people coming into the bank branch and occupying some of the teller's 
time. To that end, they will allow you to connect with a browser, a 
phone, a kiosk, pretty much anywhere.  They'll weigh the cost of fraud 
from HTTPS proxies against the cost of losing customers to a more 
lenient bank to choose their policy. That of course depends on country 
and regulations, because different jurisdictions have different 
proportions of the cost of fraud falling to the bank and to the customer.

Banks might have policies like refusing to perform high-value 
transactions through a proxy. This doesn't protect regular credentials, 
but it could protect one-time passwords and such.

But again, I don't work for a bank either and never have. I still think 
allowing them to enforce a policy is better than what we have today. 
Having this option on the table may allow (in the far future) browsers 
to stop scaling back security in the presence of MitM proxies.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Nov 2013 11:46:08 +0000

Hiya,

Cutting out lots of bits...

> On 28/11/13 11:37 AM, Stephen Farrell wrote:
[...]
> connect without a proxy, and not allowing them to connect with it. Seems

You're saying that basically a bank with a policy of not agreeing
to expose their customers' credentials to proxies (or with a
regulator who imposes such a policy) would have to turn off
Internet banking for any customer behind such a proxy who uses
HTTP/2.0.

I've no real clue, but I'd worry that'd be a major dis-incentive
for deploying HTTP/2.0 for such a bank. (Is there even a good
way to fall back to HTTP/1.1 in such a case?)

Doesn't that mean that the wg need to know whether or not the
above speculation is real or not before any particular proxy
solution could be adopted? (Or before someone takes the risk
of being burned as you put it:-)

> to stop scaling back security in the presence of MitM proxies.

Yes, current MITM attack boxes are worse. But doing the right
thing of exposing the proxy to the web site might well mean
giving some sites a choice that requires them to not use
HTTP/2.0.

There are real and hard conflicts here between the enterprise
desire to scan stuff and the web site desire for e2e security
and both need to be properly considered.

S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Nov 2013 16:41:22 +0200

> Internet banking for any customer behind such a proxy who uses

No. A bank with that policy would have to turn off Internet banking 
period, because MitM proxies work today with HTTP/1.  HTTP/2 (as opposed 
to /1) does not figure into this.
> of being burned as you put it:-)

Currently, and until HPKP with the strict directive is deployed and 
supported, all HTTPS may be done behind a proxy, and it is invisible to 
the user.

> giving some sites a choice that requires them to not use

Again, there is no difference between the versions of HTTP. This 
mechanism would work for both. We can hope that websites will do the 
right thing and find the correct balance between their desire for e2e 
security and their desire to be always available. I can't see online 
retailers such as Amazon blocking proxied connections. Banks might be 
different, but I don't think so.
> and both need to be properly considered.
By us, or by the bank?

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Nov 2013 15:08:22 +0000

Hi,

On 11/28/2013 02:41 PM, Yoav Nir wrote:
> period, because MitM proxies work today with HTTP/1.  

We disagree. Since the bank server cannot see the current MITM
attack box, they don't have the problem of deciding what to do
about that today, at the HTTP/TLS level. (Unless sites like
that also shove some JS to the browser that does detect the
MITM box - does/could that happen?)

As soon as we standardise proxy behaviour that does allow the
kind of scanning enterprises claim to need then we've handed
that bank and others this problem - they then need to figure
out if they're ok with customer credentials and data being
exposed to proxies or not and if so, when and to whom.

> HTTP/2 (as opposed

Depends. As I understand it the proposal is to define this as
a feature of HTTP/2.0. I'm not clear how it could be done with
HTTP/1.1. But we don't need to figure that out right now, I
think the more interesting question is about the consequences
for sites and if those arise in an HTTP/2.0 version that
supports this kind of proxying then that's enough to know for
this discussion.

> supported, all HTTPS may be done behind a proxy, and it is invisible to

I think the issue of user-visibility is clear. (The answer is not,
but the issue is clear.) But I'm talking about the site and the
consequences of making the proxy visible to the site.

>> and both need to be properly considered.

By the wg. And note that I said "properly considered" which
does not imply that I'm asking that the wg succeed in squaring
the circle. Since we don't seem to have real web sites jumping
in to say what they need, that is definitely tricky.

S.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 28 Nov 2013 09:55:24 -0800

>    key. It doesn't get any more "trusted" than that. Very few banks do

There is an alternative, "detect that TLS security has been compromised, and
switch to end-to-end methods." Suppose that we somehow got a new JavaScript
API that allowed access to some of the TLS data, say looking at the server
certificate that was used in the connection, or maybe computing a secure
hash of an input string with the TLS session key. 

There are many instances in which HTTP connections carries data that is
derived from of “shared secret” between client and server. The obvious
example is the user’s password, but there are other examples. A CAPTCHA, for
example, is effectively a temporary secret between client and server,
because an attacker will need some time to crack it. Validation pictures
used by banks are also a form of shared secret. 

The low tech password verification hash a challenge provided by the server
with the password provided by the client to produce a challenge response.
Suppose we also hash the TLS session key into the response. The server can
now verify the session key is the same at both ends. If it is not, then the
MITM attack is detected.

We can do the same with the response to a CAPTCHA. Instead of sending the
response in the clear, hash it with the session key. Or maybe produce two
hashes, one with a nonce and another with nonce and session key. Again, if
the server cannot verify the result, the MITM is detected.

Something similar could be done for verification images. Instead of looking
for the image by some image identifier, the client looks for the hash of the
image identifier and the session key. If this is not the expected value, the
server returns a “you are being spied upon” image.

Based on that, the server can decide whether to continue the connection, to
tell the customer to switch to a new Internet service, or maybe to use some
form of end-to-end encryption for at least some of the data.

-- Christian Huitema

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 28 Nov 2013 19:32:18 +0000

>From what I understand, it's well known in banks that there are MITM 
proxies, and so TLS is not considered to equal security.

So I agree with Yoav that a bank that truly embraces a policy that it 
shall be impossible to snoop on this data would need to block internet 
banking or use client certs.

The turn a blind eye because it's not explicitly flagged in a http 
request approach is not really defensible as the banks cannot claim 
ignorance.

I think in the end the banks would prefer to know, and would come to 
pragmatic arrangements with clients that minimise client and bank IT 
support pain.

e.g. have a setting in the bank user settings about allowing use via 
particular proxies etc.  So that customers can do banking inside their 
real-world environments, but not be vulnerable to any proxy anywhere.

Adrien

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 29 Nov 2013 10:45:43 +0100

Le Jeu 28 novembre 2013 10:37, Stephen Farrell a écrit :

Hi Stephen,

> forbid me agreeing to exposing my customer's credentials to one

In theory you would be right in practical terms banks care about money and
it's quite clear they've accepted imperfect systems for a long time as
long as the costs of cleaning up after incidents are lower than fixing
technical or organisational problems (see all the not-quite-secured
webshops or credit card systems on the market; the banks love that revenue
and don't look too hard on security).

Besides, all they have to do is to send one-time authorization codes via
other channels for any operation they perceive dangerous. That's what my
bank and Visa do today for example and that was loads easier for them than
to try drilling password discipline in all their customers (and let's be
honest: TLS is useless without a good password)

So unless a bank representative states the contrary, all my technical
experience screams its a non-problem.

Regards,

-- 
Nicolas Mailhot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Nov 2013 11:38:04 +0000

> and don't look too hard on security).

Credit card transaction processing is quite different
from Internet banking in terms of risk IMO.

But even for credit card transactions, I would think
that the PCI-DSS standard might have to change to
cater for the kinds of proxying being discussed here.
v3 of that from this month says that cardholder data
must be encrypted when sent over "open, public networks"
so that'd be badly impacted by proxies that were not
authenticated by the payment processor as being within
an enterprise, and how could that kind of authentication
happen? (I've no idea.) From a quick read of PCI-DSSv3
I would guess that they do assume TLS as being e2e as
well, but that its possible that they might consider
an enterprise proxy as ok.

But again, cardholder data is less sensitive than
credentials for Internet banking.

> honest: TLS is useless without a good password)

So your answer is that that bank has to fairly radically
change their login system due to the existence of such a
proxy? I'd not include that amongst the set of credible
answers;-)

> experience screams its a non-problem.

Mine disagrees. I don't think denying the real requirements
for e2e confidentiality that some sites have for some data
is at all credible.

S.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 29 Nov 2013 13:58:37 +0100

> proxy? I'd not include that amongst the set of credible

My answer is that banks already changed their authentication systems
because the average user can not manage strong passwords

-- 
Nicolas Mailhot

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 30 Nov 2013 07:54:22 -0800

> experience screams its a non-problem.

+1. Stephen's response (that a bank can't currently know if there is a TLS
proxy in HTTP/1.1) ignores what Yoav said, which is that such a bank could
detect that by forcing client auth. Of course they won't do that, but they
of course also won't have to because then they would be forced to not have
internet banking.

Stephen: if you have a real regulation and legal interpretation that we can
look at, we can look at that. "What if someone interprets a law in the way
I want them to because I don't like TLS proxies..." is not a useful
measure.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 30 Nov 2013 16:21:11 +0000

> of course also won't have to because then they would be forced to not have

That's not entirely logical. I agree they won't require TLS client auth.
That's nothing to do with MITM attack boxes though afaik, or do you have
some reason to think it is?

> Stephen: if you have a real regulation and legal interpretation that we can

I made no such claim.

> I want them to because I don't like TLS proxies..." is not a useful

Correct and I'd have been wrong had I said that. Luckily I did not.

But I also wish there were some folks from web sites represented here
that had things to say. But there don't seem to be, so I picked a
non-crazy example of a real e2e confidentiality requirement that poses
a hard question for those who want to develop these proxy solutions.
The answer so far seems to me to be to deny the existence of the
problem, which is not very promising.

Secondarily, that highlights that any proxy solution that claims
to give a site a "choice" has to have a way to authenticate the
proxy to the site. Protocol-wise that might be easy. But I suspect
in practice its very hard. I don't believe I've seen that accepted
or disputed by those in favour of proxies either.

S.