Subject: What will incentivize deployment of explicit proxies?

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 2 Dec 2013 23:37:33 -0800

Pardon me if this is obvious, but it's not immediately obvious to me what
will cause people to use explicit proxies instead of MITM proxies? Who is
going to deploy them? The 2 cases I can think of are:

(1) People who are using HTTP interception ("transparent") proxies
(2) People who are already using SSL MITM proxies

In case (1), it appears to me that proxy operators may want explicit
proxies, because theoretically those interception proxies provide vital
functionality that they don't want to lose if more things go over HTTPS.
Because if not, their alternative is to use a SSL MITM proxy, which
requires them to own the client devices so they can administratively
install additional root certificates. This bears a high cost, both in
perceived privacy impact and in requiring administrative maintenance. By
this description, I suspect this group probably consists of network
operators, like mobile network operators or ISPs or what not. I suspect
it's very costly for them to have to administrate customer devices.

But I don't see what an explicit proxy will help with here. Is the
requirement that there be a way to automagically configure the explicit
proxy *and* default to giving up one or more of the confidentiality,
integrity, and authentication guarantees normally provided by TLS? I can't
see a browser defaulting into letting automatically letting an explicit
proxy MITM them. Will it just be opt-in (which, given how much browser
vendors "love" presenting UI to end users, is also controversial...)? If
so, is that good enough for whoever is deploying these proxies? I have to
imagine that's very unsatisfactory for them. What's the vision here?

Now, as far case (2), if the proxy operators can already deploy their MITM
certs on client devices, then they already own those devices. This sounds
like enterprise computing devices or schools or prisons or what not. Now,
if they already own the devices on this network, what incentive do they
have to adopt explicit proxies? It sounds like they would just lose power.
Is there a carrot here? SSL MITM proxies are already transparent to the
client and origin server, so I don't see what leverage either entity has
here.

Would love to hear peoples' thoughts here.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Dec 2013 00:02:45 -0800

CDNs, accelerators/caches, traffic-optimizers/traffic-shapers have usecases
that wouldn't require the browser to give up any confidentiality (that the
site didn't direct them to do, at least).
For enterprises, the new trend is apparently to allow users to use their
personal devices. These devices would be outside the normal administrative
chain and would likely cause headaches.

-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 00:09:25 -0800

On Tue, Dec 3, 2013 at 12:02 AM, Roberto Peon <[email-masked]> wrote:

> CDNs, accelerators/caches, traffic-optimizers/traffic-shapers have
> usecases that wouldn't require the browser to give up any confidentiality
> (that the site didn't direct them to do, at least).
>

I'm going to ignore the CDN case, since I don't think they're explicit
proxies from a UA's perspective (unless I'm misunderstanding). How do you
serve cached content without knowing the URL of the resource? Are you
differentiating between object confidentiality and metadata (URL/headers)
confidentiality here? I think these questions apply to the other use cases
you refer to, but am not completely sure.

> chain and would likely cause headaches.

I agree using personal devices would likely cause headaches. But you're not
saying explicit proxies solves this somehow, do you? If so, I missed it.

>
> -=R
>
>
> On Mon, Dec 2, 2013 at 11:37 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>> Now, as far case (2), if the proxy operators can already deploy their
>> MITM certs on client devices, then they already own those devices. This
>> sounds like enterprise computing devices or schools or prisons or what not.
>> Now, if they already own the devices on this network, what incentive do
>> they have to adopt explicit proxies? It sounds like they would just lose
>> power. Is there a carrot here? SSL MITM proxies are already transparent to
>> the client and origin server, so I don't see what leverage either entity
>> has here.
>>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Dec 2013 00:28:14 -0800

> you refer to, but am not completely sure.

As proposed in one of the drafts, if the content-provider provides metadata
indicating that a resource can be served from a cache and a means of
authenticating it, then the UA can access a proxy via a TLS connection.
Only the proxy and the site and the UA thus know what was being requested.
If we wish for these requests to be made via HTTP/2, then, for the
web-browsing case over the internet, then we'll be extremely likely to be
using TLS
Since one would like to retain as much confidentiality as possible, sending
a request for the resource completely in the clear would not be optimal,
even if deploying HTTP/2 in the clear works for the web-browsing case over
the internet on port 80.

> I agree using personal devices would likely cause headaches. But you're
> not saying explicit proxies solves this somehow, do you? If so, I missed it.
>

Enterprises like these have three choices:
1) Disallow access to such devices
2) Force users to install root certs
3) Force users to configure a proxy explicitly.

Arguably #3 is the best, from both the enterprise, site and user
perspective as setting up an explicit proxy should be easier than
installing a root cert for both enterprise and user, and the site now gets
signaled about the presence of a proxy.

-=R

>
>>
>> -=R
>>
>>
>> On Mon, Dec 2, 2013 at 11:37 PM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>
>>> Pardon me if this is obvious, but it's not immediately obvious to me
>>> what will cause people to use explicit proxies instead of MITM proxies? Who
>>> is going to deploy them? The 2 cases I can think of are:
>>>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 3 Dec 2013 10:02:07 +0100

Hi William,

> (2) People who are already using SSL MITM proxies

(...)

There are several use cases. First, explicit proxies commonly require
authentication. This cannot be *cleanly* done using MITM, you generally
have to hack with cookies and redirects, and it's often not compatible
with a number of browser plug-ins or even software updates.

Second, you forget one growing deployment case which is the external
filtering proxy. Many companies provide this nowadays. Zscaler is one
of them, but I'm also seeing small companies order such services for
internal use and propose them to their employees for free to use from
home, simply because that helps them protect their PC against malware.
Again here we're talking only about explicit proxies, since there's
nothing on the network between the browser and the origin server.

Third, a long time ago when the internet started to reach joe user,
all ISPs provided some connection kits which pre-configured their
local proxies in the browser. The goal was to save on bandwidth costs.
This disappeared when ISP's bandwidth became much larger than what they
offer to their customers. But in mobile environments there's still a
benefit for this : you save the DNS round trip, and I'm quite sure
that if explicit proxies could be used safely, they would be more
commonly used in mobile environments because you can typically save
about 1 second in an average page load time due to the many hosts on
a page (interestingly, domain sharding has hurt page load time there).

Then you have anonymizers that some people use for whatever reason
(paranoia, illegal activities, political reasons, etc...).

I expect that use of explicit proxies will significantly raise after
adoption of proxies over TLS because one of the problem explicit
proxies are currently facing is the lack of confidentiality when used
in clear (eg: CONNECT host:port, SNI in clear text, credentials in
clear text).

Hoping this helps,
Willy

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 11:49:05 +0200

On 3/12/13 10:28 AM, Roberto Peon wrote:
>
>         For enterprises, the new trend is apparently to allow users to
>         use their personal devices. These devices would be outside the
>         normal administrative chain and would likely cause headaches.
>
>
>     I agree using personal devices would likely cause headaches. But
>     you're not saying explicit proxies solves this somehow, do you? If
>     so, I missed it.
>
>
> installing a root cert for both enterprise and user, and the site now 
> gets signaled about the presence of a proxy.
>
As you said, BYOD is the new trend (this email written on my Mac rather 
than a company laptop), so #1 is out. #2 is what we have now, and this 
applies not only to people who bring their own device, but also to 
people who use Firefox (a non-negligible group). They handle it by 
either searching for "install CA certificate on xxx" in a search engine 
and pasting the result on an intranet page, or by sending the users to 
do the search themselves.

#3 is preferable for administrators, sites and users by making the UX 
for it the browser vendor's problem. Because "get the CA certificate 
from this wiki page, send it to an email account that you can access 
with your phone, double-tap the attachment on the phone, etc." - all 
this is a form of user experience, just not a good one.

So if deploying an explicit proxy can get the BYOD people off of IT's 
back, it's a win for them.

Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 10:53:06 +0100

> going to deploy them? The 2 cases I can think of are:

I think browser and privacy people really need to remove their 'us vs
them' blinders and the debate will be much more constructive.

The protocol in itself is not going to change power repartition by itself.
The past proved it. Generalized TLS only resulted in generalized hostile
MITM and everyone lost (intermediaries did let TLS pass blindly as long it
was limited to clear needs like banks; they will let end-to-end http/2
encryption pass for the same needs in http/2; they won't allow it for the
streams that made them deploy TLS MITM today, it's as simple as that). So
please stop thinking about http/2 as a way for one party to force its will
on others and things will be a lot easier to design and discuss.

Once you've acknowledged that in real life the ietf and the w3c don't have
some magic powers even the UN or the USA lack today, things are a lot
easier to contemplate.

A good http/2 protocol would give visibility on the nodes that process
http traffic to everyone (web client, intermediaries, web sites). A good
http/2 protocol would give everyone the means to authenticate every other
party and communicate with it. A good http/2 protocol would give the
choice between three modes (in clear with anti-tampering signatures,
chained hops with either hop-by-hop or hop-to-end encryption with
anti-tampering signatures, end-to-end stream encryption with just enough
routing info for intermediaries to route envelopes, with possibility to
authenticate itself at every node involved).

Then, the exact mode used is negotiated between all parties (and in case
of negotiation failure the connexion fails and can be retried on another
network path later).

If browser people do their part and implement the (admittedly non-trivial)
UI to manage that, there will be a strong incentive to deploy because you
can't imagine how sick operators are of all the ways browsers screw up
http/1 by refusing to admit intermediaries exist. Browsers are by no means
pure and innocent maidens and they bear a large part of responsibility for
the current mess. Other parties are not evil monsters, by and large the
only reason they've configured MITM is because you gave them no other
choice (and then when the equipments become largely available they were
abused, they would not have been if browsers had not forced development of
stealth mode in the first place). And the correct UI is non trivial
because the real word is non-trivial, live with it reality denial will get
you nowhere.

Furthermore there will be a strong incentive for privacy people to require
from their law-maker the deployment of http/2 intermediaries because
(unlike http/1) a good http/2 protocol will enable proper communication of
terms of use between intermediaries and end-users, and clarify things
enough non-browsers get a chance to connect even in presence of
intermediaries.

And then privacy people can lobby to forbid the terms they don't like in
the same way they can lobby for anything else, and in lawful countries
whatever law is passed will be applied. Democracy strives on transparency,
not on sleight of hands (be them intermediary, web site or browser
initiated).

There is no incentive for http/2 only if you think in terms of malfeasance
and trickery, and frankly both those accusations, and the conceit you can
do anything about social contracts, are getting old fast.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 11:00:14 +0100

> chain and would likely cause headaches.

I'd temper the enthusiastic reporting of BYOD by consulting entities a lot.

BYOD is a way to allow VIPs to bring their own status-enhancing
gold-plated trendy devices at work instead of being limited to the
dirt-cheap greyboxes they allowed their IT services to purchase for
everyone else. For the average enterprise minion BYOD does not exist or is
strictly limited to configurations that are affectively identical to
whatever those enterprises used to provide.

The first answer an helpdesk will give to anyone that brought its own
device and can't communicate with the enterprise Intenet gateway will be
"you bought the device, buy the dataplan it needs"

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 11:02:37 +0100

Le Mar 3 décembre 2013 09:09, William Chan (陈智昌) a écrit :

> not

Explicit auto-configured proxies allow plugging in devices which have not
been mastered by the IT department. They don't require the user to hunt
for the MITM certificate, or the pacfile that enables external
communication on corporate premises.

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 3 Dec 2013 10:34:35 +0000

On Dec 3, 2013, at 9:37 AM, William Chan (陈智昌) <[email-masked]> wrote:

> Pardon me if this is obvious, but it's not immediately obvious to me what will cause people to use explicit proxies instead of MITM proxies?

you have also an answer to the question below in your own mail.

I would prefer to use explicit proxies, because at least I become conscious that there is some box in between me and the content provider.
Of course I would prefer also to be offered a mechanism to opt in (the proxy) or to opt out … (if I am in by default)
in this way we let the people to choose or if you prefer the market to decide
if the explicit proxys really offer extra services/advantages then maybe people will start to use it more and more, if not…
I would disagree with you, that would not be unsatisfactory, but that is my personal view as individual :-)

Moreover at the same time, in a perfect world, it would be really nice also to become aware of the existence of an SSL MITM 
especially in the case the user has decided to opt out from the usage of explicit proxy, but also in the case the have opt in.

Both the user or the content provider may decide to act in a different way when they become aware that there is something in between

Coming to the use cases there are severals and of course they are different for different providers.

for mobile network operators the main high level use case is to operate the network so to offer a great user experience to
their customers (btw this is something that is also considered acceptable by draft-farrell-perpass-attack-00),
then there is the one Willy is describing in its mail…

caching is another one,
and I am not talking of caching in CDN based on reverse proxy, I am talking about caching in forward proxy:
caching content as closer as possible to the user… (i.e. as closest as possible to an antenna in the case of mobile network for example)

filtering/anti malware (as Willy is also describing) is also an important use case that is becoming more and more important also in the mobile world.

about the enterprise use case you have already received comments...

br
Salvatore

> Who is going to deploy them? The 2 cases I can think of are:
> 
> In case (1), it appears to me that proxy operators may want explicit proxies, because theoretically those interception proxies provide vital functionality that they don't want to lose if more things go over HTTPS. Because if not, their alternative is to use a SSL MITM proxy, which requires them to own the client devices so they can administratively install additional root certificates. This bears a high cost, both in perceived privacy impact and in requiring administrative maintenance. By this description, I suspect this group probably consists of network operators, like mobile network operators or ISPs or what not. I suspect it's very costly for them to have to administrate customer devices.
> 
> But I don't see what an explicit proxy will help with here. Is the requirement that there be a way to automagically configure the explicit proxy *and* default to giving up one or more of the confidentiality, integrity, and authentication guarantees normally provided by TLS? I can't see a browser defaulting into letting automatically letting an explicit proxy MITM them. Will it just be opt-in (which, given how much browser vendors "love" presenting UI to end users, is also controversial...)? If so, is that good enough for whoever is deploying these proxies? I have to imagine that's very unsatisfactory for them. What's the vision here?
> 
> Now, as far case (2), if the proxy operators can already deploy their MITM certs on client devices, then they already own those devices. This sounds like enterprise computing devices or schools or prisons or what not. Now, if they already own the devices on this network, what incentive do they have to adopt explicit proxies? It sounds like they would just lose power. Is there a carrot here? SSL MITM proxies are already transparent to the client and origin server, so I don't see what leverage either entity has here.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 03:03:02 -0800

> with a number of browser plug-ins or even software updates.

Sorry, I'm having difficulty understanding this case. Can you explain
further? Just to be clear, what I was describing above was a transition
process. I tried to highlight known existing proxy deployments and tried to
see how the new proposals would fit in. Can you explain what this use case
you're describing is more precisely, how it's solved (perhaps poorly!)
today, and how one of the new proposals have the appropriate incentives
from the various players to adopt it? When you say requires authentication,
to me that is a configured proxy that a browser is already aware of. If
it's already configured, then the browser already has the functionality to
talk to it, and the client administrator already has the power to configure
the client browser to speak to the proxy, and could already install MITM
certs (which I assume is what happens today). I suspect I got something
wrong in that understanding, so please correct me. I'm trying to understand
what would motivate an administrator who already has control over the
client devices and the proxy deployment to want to switch to an explicit
proxy instead.

> nothing on the network between the browser and the origin server.

I feel like "explicit" has been overloaded here. Looking at the issue for
explicit proxies, the first sentence of
https://github.com/http2/http2-spec/issues/316 says: "In some use cases,
the network requires that traffic between a user agent and servers be
visible to it (e.g., for application of policy, filtering, compliance
requirements)." This seems to be referring to entities in the network
between the browser and the origin server.

In any case, how does Zscaler work today? It appears to already install
MITM certs. If that works great for them already, what's contained in the
new proposals that they need and would see better adoption?

> a page (interestingly, domain sharding has hurt page load time there).

I agree that proxies can improve on these situations. And historically,
interception proxies do a lot of this.

> in clear (eg: CONNECT host:port, SNI in clear text, credentials in

Just to be clear, if all we're talking about is a configured HTTPS proxy,
as opposed to existing configured HTTP/SOCKS proxies, then I totally see
the incentive for it. The browser<=>proxy connection is not secured and
it'd be nice to secure it. I guess I was lumping in the "trusted" bit too
that I see in lots of proposals.

>
> Hoping this helps,
> Willy
>
> I'm finding this helpful, thanks.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 13:14:55 +0200

On 3/12/13 11:53 AM, Nicolas Mailhot wrote:
> http/1 by refusing to admit intermediaries exist.
The UI is extremely important here. If we create this protocol that 
allows both client and server to be aware of the proxy, and allows them 
to authenticate the proxy, a good UI (and I don't claim to know how this 
can be done) will let the user know that (a) her traffic is being 
decrypted on the way, and (b) by whom. If we can get to the position 
that she would accept this at her workplace, but would not accept this 
at, say, a coffee shop or airport, this will influence the decision made 
by websites a lot.

If customers can be trusted to not allow decrypting proxies everywhere, 
then banks will not prohibit online banking with proxies present. If the 
UI looks like this, they might:

  +-----------------------------------------------------------------------+
  | A decrypting proxy called 'sslproxy.localhost' was detected.          |
  | |
  |  +----+ +---------------------------------------------------------+  |
  |  | OK |  | Nah, I'm so over this whole browsing the Internet thing |  |
  |  +----+ +---------------------------------------------------------+  |
  +-----------------------------------------------------------------------+

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 13:19:05 +0200

On 3/12/13 12:00 PM, Nicolas Mailhot wrote:
> everyone else.
Looking around IETF meetings, I see a lot of Macs and quite a few 
machines running Linux, even with people from big companies. Are we all 
VIPs? There are not the dirt-cheap greyboxes.
> For the average enterprise minion BYOD does not exist or is
Mostly true for laptops, but people's phones are very often tolerated.

Yoav

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 3 Dec 2013 12:18:58 +0100

Hi William,

On Tue, Dec 03, 2013 at 03:03:02AM -0800, William Chan (?????????) wrote:
> process.

Yes of course, no problem.

> I tried to highlight known existing proxy deployments and tried to
> to me that is a configured proxy that a browser is already aware of.

The issue is that currently we don't have the ability to use proxies over
TLS. So in places where using the proxy requires some authentication, it
is not acceptable to pass proxy credentials in clear text. Thus you have
the awful dance consisting in redirecting to the auth URL, and assigning
a cookie for the site being visited. The same awful mechanism is usable
for both explicit and intercepting proxies since the proxy auth is not
used at all there.

Standard proxy authentication (where the browser is aware of the proxy's
presence and sends the credentials with all requests) is clean and reliable
and totally avoids the issue above, but provides no confidentiality.

> If
> certs (which I assume is what happens today).

Yes but here I'm only talking about user authentication which already is a
problem and is slowing down adoption of external proxies as well.

> I suspect I got something

Again, intercepting proxies cause a lot of trouble. I've been running an
obsolete flash plugin in Firefox 3.6 under windows in a corporate environment
just because I couldn't upgrade it there. Upon every start it said "your
version is obsolete, please upgrade", and when I clicked on the upgrade
link it said "cannot connect".

What happens is that in order to avoid credentials to pass in clear, the
proxy first gets your request. It sees it doesn't contain a specific cookie,
so it responds with a 302 to an https login page. You enter your login/passwd
there (there are variants with http pop-up and 401 but that's the same). Then
in response it gives you a URL pointing to the original site and an argument
in the query string to identify you. Your browser then follows this second
redirect, the proxy detects the argument and sends you a cookie in response
with a redirect to the original URL. Then your browser finally goes to that
URL with the cookie delivered by the proxy.

And for each new host you visit, you have no cookie so the browser does that
awful dance over and over. There are variants but you basically get the idea.
Once you're on a site, you can browse it without problem as long as the cookie
remains valid for the proxy.

As you can see in this process, no explicit proxy features are used, what is
important is that the request reaches the proxy. The difference will happen
on https because explicit proxies will be able to forward CONNECT requests
that match the white list without delivering a fake SSL cert, while an
intercepting proxy cannot do that.

Users experience a lot of issues with these methods. Some CSS sometimes
appear broken, some images as well. Sometimes you can't see some videos,
etc... It all depends at what step you're required to authenticate and
when your browser will correctly follow the dual-redirect dance and let
you enter your credentials.

So the admin's goal here is just to get rid of end users complaints and
trouble to upgrade deployed software by simply setting up an explicit
proxy with native proxy auth, which all products support. But this is
only acceptable if this proxy is used over an encrypted channel because
of the credentials.

(...)
> that I see in lots of proposals.

In my opinion, explicit proxies only have a future with HTTPS now, and
they will definitely be useful and will solve a number of issues users
face today.

Regards,
willy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 03:21:27 -0800

On Tue, Dec 3, 2013 at 1:49 AM, Yoav Nir <[email-masked]> wrote:

> applies not only to people who bring their own device, but also to people
> who use Firefox (a non-negligible group). They handle it by either
> searching for "install CA certificate on xxx" in a search engine and
> pasting the result on an intranet page, or by sending the users to do the
> search themselves.
>
> #3 is preferable for administrators, sites and users by making the UX for
> it the browser vendor's problem. Because "get the CA certificate from this
> wiki page, send it to an email account that you can access with your phone,
> double-tap the attachment on the phone, etc." - all this is a form of user
> experience, just not a good one.
>

OK, I think I see what you're saying. IIUC, you say that the setup UX sucks
right now for MITM proxies, and browsers should make it better by providing
an explicit configuration UI for this. I think that's an interesting point,
that IT departments would prefer an explicit proxy if its setup were easier
than the MITM proxy setup. I'm going to sleep on this one. The only thing
that pops to mind for me is currently most browsers (mod Firefox only I
think) generally delegate to the system preferences, so it'd be interesting
to hear what an OS vendor (like Microsoft) has to say about this.

Cheers.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 13:24:43 +0200

> communication on corporate premises.
I don't want to get too far down the UX rat-hole, but I wonder what 
steps 3-9 in the following story look like

 1. Got myself a new tablet/laptop/SmartWig
    <http://gizmodo.com/sonys-play-for-elderly-tech-fans-a-wearable-smart-wig-1471023561>.
 2. I brought my new device to work (where there is this new HTTPS proxy)
 3. ..
 4. ..
 5. ..
 6. ..
 7. ..
 8. ..
 9. ..
10. I can now surf to https://www.paypal.com *and* I see the green EV
    indication

What steps does the user need to take.

Yoav

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 03:27:45 -0800

On Tue, Dec 3, 2013 at 1:53 AM, Nicolas Mailhot <[email-masked]

> them' blinders and the debate will be much more constructive.

Wow, this is fairly aggressive. Did my email really prompt this? I was
mostly trying to walk through the incentives for all the different players
in the ecosystem that would need to change and see if the incentives were
appropriately aligned to do so.

> on others and things will be a lot easier to design and discuss.

Hm, I don't think there's anything I've said in this email thread about
doing this. Perhaps you are replying to an opinion I stated in a different
thread?

> do anything about social contracts, are getting old fast.

Oh wow, I read through the rest of this email and...I don't know how to
respond really.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 03:37:22 -0800

On Tue, Dec 3, 2013 at 2:02 AM, Nicolas Mailhot <[email-masked]

> communication on corporate premises.

I think I've heard people reference this auto-configuration stuff, but I
haven't seen any concrete proposals around it. Did I miss it? I'd like to
see one. The main thing I don't understand about something like this is,
auto-configuration seems to imply that the user doesn't have to configure
anything. In that case, where does the user indicate that it's OK to
"trust" this proxy and let it examine the HTTPS traffic? Because I can't
imagine browsers defaulting to allowing HTTPS traffic to being examined by
intermediaries in the network. Does that seem unreasonable?

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 12:41:58 +0100

> VIPs? There are not the dirt-cheap greyboxes.

The other historical exception is R&D people with some IT knowledge ("mad
scientists" helpdesks loath with all their heart) and I'd expect to see a
lot of them at IETF meetings.

Regards,

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 13:47:20 +0200

On 3/12/13 9:37 AM, William Chan (陈智昌) wrote:
> MITM certs on client devices, then they already own those devices. 
> This sounds like enterprise computing devices or schools or prisons or 
> what not. Now, if they already own the devices on this network, what 
> incentive do they have to adopt explicit proxies? It sounds like they 
> would just lose power. Is there a carrot here? SSL MITM proxies are 
> already transparent to the client and origin server, so I don't see 
> what leverage either entity has here.
>
As a vendor of such solutions, I'll share with you the #1 complaint we 
get from customers: the green EV indication is gone. It's very likely 
that administrators are more concerned about EV than their users, but as 
it is, not letting the browser see the real server certificate is 
definitely not a good thing.

Yoav

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 03:46:38 -0800

> and totally avoids the issue above, but provides no confidentiality.

Gotcha. So Chromium supports HTTPS proxies today via PAC scripts. Please
see http://www.chromium.org/developers/design-documents/secure-web-proxy. I
think it could be improved. I think standardizing something for configuring
an HTTPS proxy would be cool. If that's what people mean by "explicit"
proxies, at least from my standpoint, it seems like the confidentiality
wins for both the browser and the proxy are clear.

> problem and is slowing down adoption of external proxies as well.

Gotcha, OK.

> only acceptable if this proxy is used over an encrypted channel because

OK, please correct me if I'm wrong, but this is more detail about why we
need HTTPS proxies, right? If so, it sounds reasonable to me.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 12:49:04 +0100

> URL with the cookie delivered by the proxy.

We have basically the same setup except with 307, no cookie and timeout (a
successful auth authorises the whole ip for some time, which is less
secure but permits using a browser to unblock naïve http clients). Works
fine in ie when you disable the https redirect blocking.

The browser is aware of the proxy (via pacfiles) but not for auth purpose
as, like Willy stated, standard proxy auth is unsecure and we do not wish
for it to be intercepted inside our networks (huge imperfectly secured
internal networks)

Cheers,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 12:56:06 +0100

Le Mar 3 décembre 2013 12:27, William Chan (陈智昌) a écrit :
>> what
> Wow, this is fairly aggressive. Did my email really prompt this?

Sorry if it was aggressive, I was trying to kill this argument once and
for all.

The incentive to adopt http/2 instead of existing systems is to play nice
with browsers and users (assuming http/2 is well designed). Existing
systems do not play nice with users and browsers. If you integrate the
fact that operators do want to play nice with users and browsers, you'll
realise your question answers itself.

Cheers,

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 13:58:54 +0200

> lot of them at IETF meetings.
Can't stand those :)

But I thought it was those artistic graphic designer types who just had 
to have their Freehand/Illustrator/Photoshop run on a Mac, because it 
was just not the same running on a PC.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 04:08:02 -0800

Oops, sorry I missed this in my FIFO. My bad.

On Tue, Dec 3, 2013 at 2:34 AM, Salvatore Loreto <
[email-masked]> wrote:

> what will cause people to use explicit proxies instead of MITM proxies?
>
> I would prefer to use explicit proxies, because at least I become
> conscious that there is some box in between me and the content provider.
>

When you say "I" here, you mean yourself as an end user, right? So, does
this mean you want a UI indicator of some sort? Can you explain how this
would work? I suspect Chromium would have an issue with that due to the
discussion in this bug thread:
https://code.google.com/p/chromium/issues/detail?id=81623#c20. Once you've
been MITM'd, anything that's cached is suspect. But what do you do at that
point? Taint track each resource in the cache? Keep separate browser
caches? What about localStorage? If JS is no longer trusted, it could have
touched anything, hence it's viral and spread to all web storage. Once
you're 0wn3d once, then even if you move to a "safe" network without the
proxy in the way that can examine your HTTPS, you can still be 0wn3d. So
what UI indicator should be shown to the user?

Of course I would prefer also to be offered a mechanism to opt in (the
> proxy) or to opt out … (if I am in by default)
> if the explicit proxys really offer extra services/advantages then maybe
> people will start to use it more and more, if not…

This discussion is hard to have because you're not providing much context.
I'm going to pigeonhole you into one of my previous use cases and you can
tell me if that's incorrect and why. I'm going to claim you fit (1) - the
existing interception proxy use case that worked fine for HTTP URIs but not
for HTTPS URIs. And this interception proxy was already operating without
any permission or knowledge from the end user. This might be an ISP proxy
for example. Now, in this case, even if an explicit proxy were provided
with a configuration to opt into the proxy being allowed to MITM the user,
I'm not seeing what incentive any user has to opt into letting themselves
get MITM'd. And I don't see why a UA would default to letting their users
get MITM'd. Can you explain how this would work?

>
> Moreover at the same time, in a perfect world, it would be really nice
> also to become aware of the existence of an SSL MITM
> especially in the case the user has decided to opt out from the usage of
> explicit proxy, but also in the case the have opt in.
>
> Both the user or the content provider may decide to act in a different way
> when they become aware that there is something in between
>
> for mobile network operators the main high level use case is to operate
> the network so to offer a great user experience to
> caching content as closer as possible to the user… (i.e. as closest as
> possible to an antenna in the case of mobile network for example)
>

Can you explain why, for these cases you describe here, an end user how
administers his/her own machine would opt into using an explicit proxy that
is allowed to MITM the SSL traffic? I'm trying to understand the incentives
here for all parties. You've described the incentives for the mobile
network operators here. But all parties need to have incentives for this to
happen, right? Unless mobile network operators have all the power (i.e.
they administer the end user devices).

>
> filtering/anti malware (as Willy is also describing) is also an important
> use case that is becoming more and more important also in the mobile world.
>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 14:16:33 +0100

> What steps does the user need to take.

1. get a web client

2. try to access http://awebsite.com

3. get http error see-gateway https://somegateway.com/
(either single entry or list of gateways)

no tls is needed for the error, the only authority is ability to intercept
or block the call
(or just get blocked with no return and try https://somegateway.com/ that
was hinted at in dns, dhcp or preconfigured in the web client)

4. ask https://somegateway.com/ for http://awebsite.com in ingoing-http2-mode

ingoing-http2-mode being one of in-clear, in-clear-with-anti-tampering,
encrypted-to-gateway, end-to-end-encryption

receive an http/2 frame with

(mandatory) gateway name

(optionnal) allowed ingoing-http2-mode for http://awebsite.com
            (if disagreement with the browser and do not want to push full
access rules)

(optionnal) login request

(optionnal) access rules list: list of rules like

from ip/ips
  to
    website/domain/ip list
  use (gateway-list in ingoing-http2-mode) (DIRECT)
  to
    website/domain/ip list
  use (gateway-list in ingoing-http2-mode) (DIRECT)
from ip/ips
 …
otherwise use (website/domain/ip list) (direct)

(optional) location of help page (terms of use, etc)

(imho regardless of the ingoing mode chosen login if required must be
secured)

5. Prompt the user:

Accept using gateway-name to access http://awebsite.com/ and other web
sites in ingoing-http2-mode ?

[check reformatted access rules] [see help page] [see certificate]

  [ ] Prompt for other web sites and security modes
  ( ) only for this session ( ) all the time
  (*) only from here        ( ) everywhere
                                         [Yes] [No]

6. Assuming the user clicked yes show the eventual login prompt and proceed

7. every time connexion uses a gateway show using gateway-name transient
message + some widget that gives access to gateway chain in use with
properties
(so user can detect its coms are intercepted when they're not supposed to be)

8. no opinion if its better to apply the access list blindly or only when
direct connection fails, it's more a hint that anything else but trying
direct on every object on restricted networks is going to be expensive

Other messages the gateway needs to insert in the stream at any time

 Refused (code + optional pretty explanation page)
 Rebalance other-gateway-list
 (re)login (login expired or previous web sites allowed without login)
 Access rules change (new list)

Regards,

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 15:36:33 +0200

I like this discovery process. It's all in HTTP. The only downside is 
that it requires plaintext HTTP to work. I'm assuming that 
http://awebsite.com should not be the real site that the user is trying 
to view, but some specific site that the browser vendor keeps available 
just for testing for proxies with HTTP. You can't use the site that the 
user used, because that might be HTTPS.

You will get pushback on #5, though.

>    (*) only from here        ( ) everywhere
My mother would call me if she got that. My daughter would quickly learn 
that clicking "Yes" after unchecking the "Prompt" box and selecting 
"everywhere" makes the prompt go away and not come back. IOW it would 
make the Internet work.

Yoav

(or my mother could call my daughter and get her advice...)

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 15:26:49 +0100

> user used, because that might be HTTPS.

Actually, you really need to have http://awebsite.com be the real site
because some sites will be available directly and others not and you can't
know it before being blocked and receiving the access list (if you decide
to trust it)

That's why I wrote the initial error requires no authority: the error by
itself proves someone is able to intercept the call, you do not have to
trust this someone, only the gateway it points you to. So processing this
error even if it's not in the tls session is not a security breach

(and the simplest this error is the more likely it is to be properly
implemented in dumb firefalls)

> You will get pushback on #5, though.

#5 is really over-engineered, because I am a geek. You can simplify it a
lot depending on the choices you want your browser to propose. The only
important parts are the three links (access rules, help page, certificate)
and yes/no, the rest is browser or extension policy

Normal human beings only need to check the "using gateway xxx" occurs on
locations they expect xxx to exist, privacy advocates need to see the
access list to protest if they don't like them, and only geeks will want
to check all the combinations.

Regards,

-- 
Nicolas Mailhot

---

From: Patrick McManus <[email-masked]>
Date: Tue, 3 Dec 2013 09:49:46 -0500

firefox uses the OS proxy config by default with the exception that we
don't honor the OS WPAD setting, cause experience has shown that it is an
easy way to get owned when you're traveling. Like most everything, it is
configurable.

better proxy detection would be handy for better error reporting, better
auth handling, etc.. I agree. Doing this browser to proxy communication
over TLS would be good, I agree with that too. (This is what Will calls
https proxies.. I've got a patchset for firefox half written for it.)

The problem with these explicit MITM proposals is that they also propose to
terminate https:// at the proxy, and that shouldn't happen. Sure lots of
people are already MITM'd by root cert annotations today - but not
everybody. I don't want to spread that particular affliction.

On Tue, Dec 3, 2013 at 6:21 AM, William Chan (陈智昌) <[email-masked]>wrote:

> OK, I think I see what you're saying. IIUC, you say that the setup UX
> sucks right now for MITM proxies, and browsers should make it better by
> providing an explicit configuration UI for this. I think that's an
> interesting point, that IT departments would prefer an explicit proxy if
> its setup were easier than the MITM proxy setup. I'm going to sleep on this
> one. The only thing that pops to mind for me is currently most browsers
> (mod Firefox only I think) generally delegate to the system preferences, so
> it'd be interesting to hear what an OS vendor (like Microsoft) has to say
> about this.
>
> Cheers.
>
>
>>
>>
>> Yoav
>>
>>
>

---

From: Albert Lunde <[email-masked]>
Date: Tue, 03 Dec 2013 10:47:50 -0600

If this sort of proxy discovery/negotiation process is such an 
improvement, it seems like there might be merit to specifying it in 
parallel for HTTP/HTTPS 1.1 and HTTP/HTTPS 2.0, even if the messages and 
state management used aren't exactly identical.

It might distinguish the proxy and/or interception issues from HTTP 
version issues.

The HTTP/HTTPS 1.1 case doesn't have to compete with with direct 
connections so much as with the other proxy or interception gimmicks 
already deployed, whether corporate antivirus or coffee shop wifi filtering.

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 19:18:21 +0100

> state management used aren't exactly identical.

I thought the aim of keeping http1 semantics was to allow http2-to-http1
bridges? If that's the case we only need good proxy support in http2, the
proxy will terminate the http2 link and translate to http1 for http1 web
sites

Trying to fix http1 for proxies at this stage seems way too late (unless
http2 goes nowhere)

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 19:39:07 +0100

> everybody. I don't want to spread that particular affliction.

That's why I proposed several modes today, so non-critical parts can be
terminated at the proxy (with malware checking) and bank traffic for
example can pass end-to-end

I fear never terminating https at the proxy won't see adoption now that
there is widespread availability of MITM solutions on the market, and web
sites try to encrypt the most trivial traffic. At some point the desire to
protect users' privacy is far outweighed by the risk of malware injection
once http is applied in blanket mode everywhere. The ship already sailed
and by trying to achieve too much https proponents generated strong
pushback

Unlike Willy I do think all is not lost (yet) and operators will accept to
not terminate ssl systematically if the protocol is not an all-or-nothing
choice. For example I'm pretty sure most corporations would accept to only
scan mime types likely to carry malware (js, executables, zip/isos/office
documents) and pass the rest in opaque messages as long as major browsers
and web sites didn't lie about this (and users deploying other web clients
that lied in their user agent would face administrative sanctions). For
non-dangerous mime types "inspection" only cares about checking if the
full url does not belong to a porn/spam/crook/gaming web site, not the
message content.

It's all a balancing act.

Regards,

BTW: great news about the Firefox patchset

-- 
Nicolas Mailhot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 10:53:26 -0800

On Tue, Dec 3, 2013 at 5:36 AM, Yoav Nir <[email-masked]> wrote:

> I like this discovery process. It's all in HTTP. The only downside is that
> it requires plaintext HTTP to work. I'm assuming that http://awebsite.comshould not be the real site that the user is trying to view, but some
> specific site that the browser vendor keeps available just for testing for
> proxies with HTTP. You can't use the site that the user used, because that
> might be HTTPS.
>
> "everywhere" makes the prompt go away and not come back. IOW it would make
> the Internet work.
>

<pushback>
I can probably expect to be tarred and feathered by my security team if I
tell them we need to put up a UI asking the end user to make a decision
about security :)
</pushback>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 11:57:37 -0800

> tell them we need to put up a UI asking the end user to make a decision

This is no joke.  There has to be a very good UX story for this.
Ironclad, I'd have to say.  I'm told secondhand that some people
believe that they have a good story.

I'd like to (again) encourage those people to tell that story here so
that we can all determine whether it is indeed good.

Otherwise, we're back to asking hard questions of those who are least
qualified to answer them.  That's not conducive to a good security
story.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 3 Dec 2013 21:00:57 +0100

> tell them we need to put up a UI asking the end user to make a decision

Then simplify the prompt to

Access to http://awebsite.com/ requires using gateway-name on this network.
gateway-name may read some of your traffic. Do you want to proceed ?
  <link to advanced info>
  <yes> <no>

The only decision the user needs to make is if he's in a location where
gateway-name is expecter and if he accepts exposing his traffic. That will
usually be a no-brainer (ok if at hotel, corp, school, nok at home unless
the proxy is user-deployed). And you only need to remind him the gateway
is in use next time it's encountered via a transient message, in case it
occurs in an unexpected place, the user wants to rescind the permission or
he's in private browsing mode. (display gateway name and encryption
status)

You don't need to force the user to check the whole access policy and
terms of use, it's only important they are available in the UI so a small
proportion of whistle-blowers can check them and keep the operator honest.

That's how all the small print contracts work in real life, actually. No
one wants to read them and few people do, but if they were not publicly
available all kinds of abuses would be possible.

-- 
Nicolas Mailhot

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 Dec 2013 20:16:10 +0000

+1 on playing nice with users and browsers, and add IT dept as well.

One of the biggest support queries we get relates to people who use our 
product to intercept connections, then wish the user to auth to the 
proxy.

What we do in this case is pretend the proxy is the server asking for 
auth (so we send a 401 back with a WWW-authenticate header).  There's no 
other way I can think of that can allow a per-connection establishment 
of credentials within HTTP.

The problem is the browser doesn't know about the proxy, so presumes the 
auth challenge (401) is coming from the server.  It also presumes 
therefore that if it goes to another site, it can't re-use the creds.

If on the other hand the client could learn about the existence of the 
proxy, and learn that it is the proxy that is asking for the auth, then 
it could adopt a different behaviour.

PAC files are not a good deployment option.  WPAD is not either.

IMO the best way is to take the connection that you have (the only one 
you can reliably know you will get) and use it to signal the requirement 
for proxy use.  This means in clear http, having a signal for 
requirement to use a proxy, and in TLS, you'd need something in there as 
well.  I know people consider this as breaking TLS.  However inserting a 
mechanism to deny with information a TLS handshake... does that really 
break it?  Couldn't it be considered an extension of ALPN or NPN?

Adrien

------ Original Message ------
From: "Nicolas Mailhot" <[email-masked]>
To: "William Chan (陈智昌)" <[email-masked]>
Cc: "Nicolas Mailhot" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 4/12/2013 12:56:06 a.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>>>  > will cause people to use explicit proxies instead of MITM proxies? 
>>>Who
>>>  is

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 Dec 2013 20:20:08 +0000

------ Original Message ------
From: "Nicolas Mailhot" <[email-masked]>
To: "Albert Lunde" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 4/12/2013 7:18:21 a.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>Trying to fix http1 for proxies at this stage seems way too late 
Actually I think there would still be an enormous benefit to be had from 
fixing this in 1.1

We can deploy such things very quickly, and customers can start to see 
benefits straight away.  unlike the expected timeframe for widespread 
benefits from 2.0, since that's not even a target we can implement to, 
let alone roll out etc.

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 Dec 2013 20:23:05 +0000

------ Original Message ------

>full url does not belong to a porn/spam/crook/gaming web site, not the

actually there are products out there that inspect HTML to attempt to 
classify content using various heuristics.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 23:20:41 +0200

On 3/12/13 8:53 PM, William Chan (陈智昌) wrote:
>     My mother would call me if she got that. My daughter would quickly
>     learn that clicking "Yes" after unchecking the "Prompt" box and
>     selecting "everywhere" makes the prompt go away and not come back.
>     IOW it would make the Internet work.
>
>
> <pushback>
> I can probably expect to be tarred and feathered by my security team 
> if I tell them we need to put up a UI asking the end user to make a 
> decision about security :)
> </pushback>
>
Especially if you ask the end user at the worst possible time - when 
you're in their way to finish something they've already begun. So I've 
decided to read my gmail, and I typed "mail.google.com", and I'm 
expecting my message list to appear in a second. And now you tell me to 
stop everything and answer some question about some proxy?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Dec 2013 23:28:25 +0200

> gateway-name may read some of your traffic. Do you want to proceed ?

Simplification doesn't help. The user is in the middle of doing 
something, and they're not going to take their mind off the task at hand 
to answer your questions.
> gateway-name is expecter and if he accepts exposing his traffic.

Not everyone has expectations regarding the presence or absence of 
proxies. Only a few would be able to make a good guess as to why the 
proxy is even there (scan for malware? Cache? scan for subversives?)

> That will
> the proxy is user-deployed).

Guess it's not a no-brainer, because I would not be OK with a decrypting 
proxy at a hotel, coffee shop, or airport.

> And you only need to remind him the gateway

"Your traffic to mail.google.com is being decrypted by 
sslproxy.example.com". Good, bad, or indifferent?

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 Dec 2013 21:47:27 +0000

most people in a corp environment would need to do this only once per 
proxy surely?

Adrien

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "William Chan (陈智昌)" <[email-masked]>
Cc: "Nicolas Mailhot" <[email-masked]>; "Roberto Peon" 
<[email-masked]>; "HTTP Working Group" <[email-masked]>
Sent: 4/12/2013 10:20:41 a.m.
Subject: Re: What will incentivize deployment of explicit proxies?

---

From: Tim Bray <[email-masked]>
Date: Tue, 3 Dec 2013 13:55:18 -0800

William is wrong: He will *definitely* be punished severely if he proposes
putting security choices in the faces of ordinary humans; no “probably
expect” about it...

On Tue, Dec 3, 2013 at 10:53 AM, William Chan (陈智昌)
<[email-masked]>wrote:

>> learn that clicking "Yes" after unchecking the "Prompt" box and selecting

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Dec 2013 14:03:50 -0800

And yet that's exactly what is done in other contexts all the time. When I
link my android chrome browser to my Google account, for instance, I can
usually expect to be asked to make several security choices...
On Dec 3, 2013 1:57 PM, "Tim Bray" <[email-masked]> wrote:

> On Tue, Dec 3, 2013 at 10:53 AM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 3 Dec 2013 17:25:20 -0500

> tell them we need to put up a UI asking the end user to make a decision
Right. There is probably no way the user can make a meaningful decision
here. Heck - I'm not sure I can make a meaningful decision and I'm
certainly more familiar with the issues than most users. We've just begun
to uncover some of the reasons why.

you make a "trust" delegation to your proxy to do exactly what.. load a
single URL? load just a particular origin? load a page.. (for how long
(scripts!)?).. can different pages use scripts cached with that trust? Can
they use my pre established cookies? What about mixed content rules? What
about a safe browsing database or a CRL list - Are those still trusted? How
about browser updates or new addons? Should you be prompted separately to
search google.com and login to chase.com? is every page a new dialog? Are
we going to categories where you opt-in a category (e.g. search, but not
finance) and then the server gets to decide what kind of data it is instead
of the user? Why is my EV indicator now gone and does that deter server
side folks who want a stable UI to not adopt EV?

And that's all rather beside the point. The information belongs to the user
not to the network even if the network is not obliged to carry it. If the
network would like to be able to more expressively define mechanisms saying
it refuses to carry e2e secured data I would be happy to make use of that..

-P

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 Dec 2013 22:33:16 +0000

in the case of the corporate proxy, you delegate trust for the duration 
of your use of the browser at that location.

So I would expect some UI indication that is basically permanently 
indicating this is happening, which is why I previously suggested the 
frame could be a way to do it.

There's also a class of proxy that we haven't been considering much 
here, that is possibly the most wide-spread:

Localhost proxies for products like endpoint AV.

Adrien

------ Original Message ------
From: "Patrick McManus" <[email-masked]>
To: "William Chan (陈智昌)" <[email-masked]>
Cc: "Yoav Nir" <[email-masked]>; "Nicolas Mailhot" 
<[email-masked]>; "Roberto Peon" <[email-masked]>; "HTTP 
Working Group" <[email-masked]>
Sent: 4/12/2013 11:25:20 a.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>
>
>
>On Tue, Dec 3, 2013 at 1:53 PM, William Chan (陈智昌) 
><[email-masked]> wrote:
>>
>><pushback>
>certainly more familiar with the issues than most users. We've just 
>begun to uncover some of the reasons why.
>
>(scripts!)?).. can different pages use scripts cached with that trust? 
>Can they use my pre established cookies? What about mixed content 
>rules? What about a safe browsing database or a CRL list - Are those 
>still trusted? How about browser updates or new addons? Should you be 
>prompted separately to search google.com and login to chase.com? is 
>every page a new dialog? Are we going to categories where you opt-in a 
>category (e.g. search, but not finance) and then the server gets to 
>decide what kind of data it is instead of the user? Why is my EV 
>indicator now gone and does that deter server side folks who want a 
>stable UI to not adopt EV?
>
>And that's all rather beside the point. The information belongs to the 
>user not to the network even if the network is not obliged to carry it. 
>If the network would like to be able to more expressively define 
>mechanisms saying it refuses to carry e2e secured data I would be happy 
>to make use of that..
>
>-P
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Dec 2013 00:37:12 +0200

The fact that everyone does it does not mean it's a good thing or that 
we should do it more.

But the fact is that I don't see how we can avoid leaving it to the 
user. When designing a protocol or a browser, we have no idea if the 
user is going to be working for example.com (making sslproxy.example.com 
acceptable), or not. We also don't have a good concept of "location", 
which would allow us to know if the browser is currently located on a 
network at the example.com offices. We also don't know whether 
IdaratAlAmnAlSiyasi.gov.sy is acceptable or not. They're hard choices, 
but only the user can make them.

It might be prudent to sacrifice expediency and block all access through 
unrecognized proxies. Adding an explicit proxy would then have to be 
done through a different UI, not a prompt that surprises a user who is 
trying to do something. If, as Adrien says, this is something that only 
happens once (when you get a new device or when the workplace installs a 
proxy) then configuring this once is likely OK. If these things start 
popping up in coffee shops, hotels, and your ISP connection, then we'll 
need something else.

Yoav

On 4/12/13 12:03 AM, James M Snell wrote:
>
> And yet that's exactly what is done in other contexts all the time. 
> When I link my android chrome browser to my Google account, for 
> instance, I can usually expect to be asked to make several security 
> choices...
>
> On Dec 3, 2013 1:57 PM, "Tim Bray" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     William is wrong: He will *definitely* be punished severely if he
>     proposes putting security choices in the faces of ordinary humans;
>     no “probably expect” about it...
>
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Tue, Dec 3, 2013 at 5:36 AM, Yoav Nir <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             I like this discovery process. It's all in HTTP. The only
>             downside is that it requires plaintext HTTP to work. I'm
>             assuming that http://awebsite.com should not be the real
>             site that the user is trying to view, but some specific
>             site that the browser vendor keeps available just for
>             testing for proxies with HTTP. You can't use the site that
>             the user used, because that might be HTTPS.
>
>             My mother would call me if she got that. My daughter would
>             quickly learn that clicking "Yes" after unchecking the
>             "Prompt" box and selecting "everywhere" makes the prompt
>             go away and not come back. IOW it would make the Internet
>             work.
>
>
>         <pushback>
>         I can probably expect to be tarred and feathered by my
>         security team if I tell them we need to put up a UI asking the
>         end user to make a decision about security :)
>         </pushback>
>
>
>             Yoav
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 15:07:05 -0800

On 3 December 2013 14:37, Yoav Nir <[email-masked]> wrote:
> unrecognized proxies. Adding an explicit proxy would then have to be done
> through a different UI, not a prompt that surprises a user who is trying to
> do something.

That's exactly what we've decided to do for screen sharing in WebRTC.
It's got a similar sort of security profile: deceptively simple, but
in practice there are subtleties users cannot be expected to evaluate.
 In that context, Chrome - the only browser thus far to even have
screen sharing support - have decided to move access to this into
their extension framework.

In order to enable screen sharing in Chrome, sites will need to use an
extension that enables screen sharing for their site.  That hasn't
been a universally popular decision, but I believe it to be a
reasonable one given the nature of the problem.  It takes the decision
off the critical path; it allows for revocation of rights when there
are bad actors; etc...

I'm not suggesting that this is the right decision here, but some
greater awareness of the sorts of things people are doing when
presented with similarly tough decisions can't hurt.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 16:22:46 -0800

OK, it sounds like people are retreating back from the
autoconfiguration+interstitial part of an explicit proxy proposal...except
maybe Nicholas? I'd love to hear more thoughts on
autoconfiguration+interstitial. It sounds like the prevailing sentiment is
it's unacceptable from a security UX perspective.

And now we're back to one-time setup operations. And in contrast to MITM
proxies, we see an opportunity to improve on the UX here, since installing
a root cert sucks. It seems like all browsers here rely on the system for
proxy configuration (Pat corrected me earlier on that), so this will tie us
to OS versions if we pursue this path. So if the OS vendors do not improve
the UX for installing MITM proxies, and instead focus energies on creating
a better explicit proxy configuration UX, then maybe that'll encourage
proxy operators to deploy more explicit proxies.

That's probably most of the proxy incentives there. Now it's interesting to
analyze the site operator incentives and the browser incentives. Site
operators will like explicit proxies, since they probably like having more
knowledge/power. Although there's the concern Stephen raised earlier about
banking site operators blocking access if an explicit "trusted" proxy is
present. This may impact the incentives of proxy operators to deploy
explicit proxies since they may not want site operators to be able to do
this. Thoughts on that?

And now there are the UAs, of which browsers are the most prominent. For
tools like curl, I don't think they'd have a problem with "trusted"
proxies, since the user presumably knows what he's doing? Maybe? For
browsers though, I expect there will be some hesitance to sacrifice e2e
security guarantees. Pat already mentioned this earlier about his dislike
of proxy termination of https:// requests. My teammates have similarly
voiced concerns here. Would we be willing to move forward with explicit
HTTPS proxies (UA<=>proxy TLS connection) without any "trusted" modes? Or
is that a key part of the proposals?

Cheers.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Dec 2013 16:34:50 -0800

On Tue, Dec 3, 2013 at 4:22 PM, William Chan (陈智昌) <[email-masked]>wrote:

> That's probably most of the proxy incentives there.
>

I'm not sure that this is the case.  One nice thing about explicit proxies
is that they do not need to be on-path, where interception proxies do.  You
could imagine someone creating a business that puts the explicit proxies
into a data center and selling that as a service.  One of the issues with
interception proxies is that you must cause the traffic to traverse the
network segments where the interception takes place.  Being able to avoid
that would be a big incentive, if the web ecosystem supported it.

Ted

> Now it's interesting to analyze the site operator incentives and the
> browser incentives. Site operators will like explicit proxies, since they
> probably like having more knowledge/power. Although there's the concern
> Stephen raised earlier about banking site operators blocking access if an
> explicit "trusted" proxy is present. This may impact the incentives of
> proxy operators to deploy explicit proxies since they may not want site
> operators to be able to do this. Thoughts on that?
>
>> done

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Dec 2013 16:42:06 -0800

> that would be a big incentive, if the web ecosystem supported it.

Indeed you are correct here.

---

From: Albert Lunde <[email-masked]>
Date: Tue, 03 Dec 2013 19:18:15 -0600

On 12/3/2013 6:22 PM, William Chan (陈智昌) wrote:
> autoconfiguration+interstitial part of an explicit proxy
> proposal...except maybe Nicholas? I'd love to hear more thoughts on
> autoconfiguration+interstitial. It sounds like the prevailing sentiment
> is it's unacceptable from a security UX perspective.
[...]
> security guarantees. Pat already mentioned this earlier about his
> dislike of proxy termination of https:// requests. My teammates have
> similarly voiced concerns here. Would we be willing to move forward with
> explicit HTTPS proxies (UA<=>proxy TLS connection) without any "trusted"
> modes? Or is that a key part of the proposals?

It seems like a HTTP client's local configuration of what proxies it 
trusts (or distrusts) is going to be a distinct problem from the wire 
protocol being talked to the proxy, and may be specific to the type of 
client or how it is being used.

What's a reasonable configuration format for a browser client may not 
make sense for an RSS aggregation, or a web service client, or wget.

A mobile client that defines "Locations" might want to associate local 
proxy trust policies with those locations.  But there still might be 
security risks with policy spoofing.

For example, my Android phone can recognize "Locations" based on WiFi 
network names. It might conclude I was at the office because of the 
existence of a network named "Northwestern" without looking at the details.

A Microsoft domain environment might want to seed trust preferences with 
Group Policy.

Having some kind of expectation of what a configuration might involve
could be helpful. A list of recognized proxies with associated actions 
(trust/distrust), and a default action, seems like the simplest case.

Saying, "I'll trust proxies with certificates signed by a list of CAs" 
"reduces" it to the certificate trust problem, which is nearly where we 
stated, though trusting proxies signed by a short list of CAs might be 
more manageable.

I can't think of a way to introduce new trusted proxies that can't be 
subverted, say, by a person wanting to get to a suspect web site.

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Dec 2013 17:31:19 -0800

On Tue, Dec 3, 2013 at 2:37 PM, Yoav Nir <[email-masked]> wrote:
> The fact that everyone does it does not mean it's a good thing or that we
> should do it more.

Agreed. My point was not to argue that it was a good thing as much as
it was to point out that the UX is not something we need to solve
here, at least not right away... Beating the "perfect is the enemy of
good" drum once again.. perhaps for the time being putting some
security decisions into the hands of users is acceptable, at least
until the UX folks figure out a better way.

- James

>
> But the fact is that I don't see how we can avoid leaving it to the user.
> When designing a protocol or a browser, we have no idea if the user is going
> to be working for example.com (making sslproxy.example.com acceptable), or
> not. We also don't have a good concept of "location", which would allow us
> to know if the browser is currently located on a network at the example.com
> offices. We also don't know whether IdaratAlAmnAlSiyasi.gov.sy is acceptable
> or not. They're hard choices, but only the user can make them.
>
> do something. If, as Adrien says, this is something that only happens once
> (when you get a new device or when the workplace installs a proxy) then
> configuring this once is likely OK. If these things start popping up in
> coffee shops, hotels, and your ISP connection, then we'll need something
> else.
>
> Yoav
>
>
>

---

From: Peter Lepeska <[email-masked]>
Date: Tue, 3 Dec 2013 20:48:58 -0500

Agreed. Also, there's no way for a MITM to distinguish between supported
and unsupported devices. It has to terminate all 443 traffic and so devices
that do not have the proxy CA installed receive a scary message about an
untrusted cert. Better would be if the explicit proxy negotiation somehow
involved clean messaging to the user in this case.

Peter

On Tue, Dec 3, 2013 at 7:42 PM, William Chan (陈智昌) <[email-masked]>wrote:

>> On Tue, Dec 3, 2013 at 4:22 PM, William Chan (陈智昌) <[email-masked]
>> > wrote:
>>
>> I'm not sure that this is the case.  One nice thing about explicit
>> proxies is that they do not need to be on-path, where interception proxies
>> do.  You could imagine someone creating a business that puts the explicit
>> proxies into a data center and selling that as a service.  One of the
>> issues with interception proxies is that you must cause the traffic to
>> traverse the network segments where the interception takes place.  Being
>> able to avoid that would be a big incentive, if the web ecosystem supported
>> it.
>>
>
>>> On Tue, Dec 3, 2013 at 3:07 PM, Martin Thomson <[email-masked]
>>> > wrote:
>>>

---

From: Peter Lepeska <[email-masked]>
Date: Tue, 3 Dec 2013 20:57:14 -0500

I like the way you've laid this out from the perspective of incentives to
adopt.

"Now, as far case (2), if the proxy operators can already deploy their MITM
here."

I wonder if MITM proxy operators have any legal concerns about viewing
content owners' traffic without their consent or even an indication that
the MITM is active. The proxy operators "own" their users' devices
presumably but not content owners' data. I think an ideal explicit proxy
would allow proxies to make their presence known to content owners.

Peter

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 04 Dec 2013 16:24:51 +1300

On 4/12/2013 2:57 p.m., Peter Lepeska wrote:
> the MITM is active.

Some of them do.

I have consulted for several installations where the MITM was decided
against on legal grounds for almost exactly those reasons.

I have also consulted for several where it was decided *for* on legal
grounds (yes it was for schools mostly, but also for some government-run
proxy system) but with restrictions on what filtering software may be
attached to the proxy.

> The proxy operators "own" their users' devices

Amos

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Dec 2013 09:28:50 +0200

On 4/12/13 3:57 AM, Peter Lepeska wrote:
> content owners' traffic without their consent or even an indication 
> that the MITM is active. The proxy operators "own" their users' 
> devices presumably but not content owners' data. I think an ideal 
> explicit proxy would allow proxies to make their presence known to 
> content owners.
>
Hi, Peter

Proxy vendor here. We can't make sweeping statements about legal 
concerns of proxy operators, because they vary from country to country 
and from state to state in federated countries.

There are also many variables that may or may not be relevant legally or 
ethically. One is the question of visibility to humans. A next 
generation firewall scans the resources going through HTTP and then 
either transfers them on or drops them. The traffic is never stored and 
never visible to any administrator. The only thing that is visible is a 
log saying: "User JohnSmith tried to GET resource 
https://warez.example.com/downloads/cracked_microsoft_office_2013.exe , 
which contained virus xxxxxxxxxx".   So that's metadata.  Is that OK?  I 
don't know. That's why I'm arguing for visibility of the proxy.

Same goes for a Caching proxy. As long as nobody sees the content, 
what's the harm. If the proxy is used for reading people's emails and 
social network posts, and forwarding them to the proper authorities if 
they seem too subversive, the legal and ethical concerns are different. 
This is the other reason why we need proxies to be explicitly 
configured. Without that, all of the above proxies look the same.

My company's product does not export HTTPS content. It's strictly a 
firewall, and there's no usable way to export the data. The problem is 
that there is no technical way to distinguish this kind of product from 
one that does export decrypted traffic.

Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 4 Dec 2013 09:46:43 +0100

> stop everything and answer some question about some proxy?

I can tell you this is way better for the user. The current systems fall
in three categories : silent interception, auth that requires restarting
the browser, auth that interrupts in a hackish way. They're all worse than
that one way of the other.

Besides, the user need not get the prompt every time. For a gateway that
does not require auth, just autoconnect the next time you encounter it
(with notification so user can stop if he does not like it). If the
gateway does require auth it's slightly more complex but browsers already
have password stores for that case. The whole point of fixing the plumbing
in the protocol is to enable automated handling when it's safe and makes
sense. The current one-of-a-kind systems do not permit this.

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 4 Dec 2013 09:55:25 +0100

> to answer your questions.

I can tell you they will and already do it (here for 150k+ people)

> proxy is even there (scan for malware? Cache? scan for subversives?)

They're not required to guess anything that's why I want the browser to
display the whole access list if the user want to consult it.

For the rest it's not better or worse than the miriad small print
interactions users perform every day (including small print on video games
for kids, including web site term of uses, etc). You can wish for a world
without small print or lawsuits but this world won't happen so let's make
the existing one as convenient as possible for existing users.

> proxy at a hotel, coffee shop, or airport.

It's a no brainer to choose yes or no. Your answer proves it's a no
brainer for you to choose no in some circumstances. I guess if you want to
access your airplane ticket to reschedule because you're late at the
airport it will be a no brainer to choose yes to the airport proxy instead
of spending hours in a physical queue (and I'm pretty sure than in the USA
any airport gateway would be monitored in depth by all kinds of black
agencies).

> sslproxy.example.com". Good, bad, or indifferent?

Indifferent is not a choice. The choice is to proceed or not.

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 4 Dec 2013 10:04:50 +0100

Le Mer 4 décembre 2013 01:34, Ted Hardie a écrit :
>> proposal...except

Explicit proxies the user chose for its own reasons (tor...) do not need
to be on-path or even block direct proxy-less connexion. (though a
security aware user will block all other paths anyway to force the
eventual malware that gets installed on his devices to pass through his
proxy even if it does not want to)

Explicit proxies where the user is under some form of constraint (employer
demand, school rules…) only require ability to block direct connexions.
Though this could be trivially enhanced without wounding anyone if there
was a simple-enough see-gateway here even dumb firewalls could implement
without scaling problems.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 4 Dec 2013 10:16:42 +0100

> stated, though trusting proxies signed by a short list of CAs might be

In the end the user needs to be notified when a particular proxy he
accepted is in use or not (with kill connexion option if he wants to
stop). Because only this user will know if his current browsing is
sensitive or not, or if the proxy is expected or not.

When I'm at home vpn connected to work I accept the terms of my workplace
proxy. When I'm at home doing personal stuff I don't want my employer to
intrude, so I want to be shown I forgot to close the vpn and I'm still
being proxified. (or to take another example if I accepted a hotel proxy
and it pops up in another physical place something fishy is going on and I
don't need to be an IT expert to realise it). I may visit another work
premise that uses a different address plan and seeing the usual work proxy
popup will be ok. Seeing the same pop up in another company indicates
someone is trying to steal trade secrets. School proxy at school is ok.
school proxy at home means an enterprising student stole the headmaster's
post-it admin password, got the gateway certificates and wants to spy on
his schoolmates.

You can't get the user out of the decision loop. You can avoid bothering
him needlessly with new prompts once the initial yes/no choice has been
done, but even afterwards gateway xxx is in use needs to be displayed
somewhere in the web client chrome

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 4 Dec 2013 10:18:35 +0100

Le Mer 4 décembre 2013 02:31, James M Snell a écrit :
>> we

Yes, the protocol needs to be clean enough web clients can build whatever
UI they feel is best, embodying whatever policies they want to apply by
default at a time (because those things have been known to evolve over
time)

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 4 Dec 2013 10:34:33 +0100

> it's unacceptable from a security UX perspective.

I think autoconfiguration and explicit are completely orthogonal problems

Explicit (in the sense the user knows a gateway is in use, can inspect the
gateway settings, and can refuse to use it) is absolutely required for
security reasons.

That does not mean the set up of this gateway can't be automated. The
decision needs to be left to humans. The plumbing, to software & protocol.

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 4 Dec 2013 15:00:32 +0000

+1 with Nicolas view below, 
I also think we should work on a smart and secure auto configuration mechanism

I do think we should still have the distinction between HTTP and HTTPS resources in HTTP/2.0 no matter if 2.0 only runs on TLS.
Indeed in my view only HTTP resources' requests will be routed through the 'explicit proxy' (if there is one, and the user has opt-in or not decided to opt-out… tbd)
while all the secure HTTPS resources' requests will be always routed directly from the browser to the destination (i.e. content provider network), bypassing the explicit proxy
exactly as it happens nowadays whenever you have accepted to use the "Google Data Compression Proxy" for Chrome.

/Salvatore

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 4 Dec 2013 11:06:50 -0500

Hi Yoav,

When I said MITM operator, I was more referring to your customers who
deploy your product. If you had two modes of operation in your product --
MITM or explicit proxy -- which would your customers choose? What is the
incentive for them to choose eproxy? I think legal considerations may
sometimes be one of them.

Thanks,

Peter

On Wed, Dec 4, 2013 at 2:28 AM, Yoav Nir <[email-masked]> wrote:

> Proxy vendor here. We can't make sweeping statements about legal concerns
> of proxy operators, because they vary from country to country and from
> state to state in federated countries.
>
> ethically. One is the question of visibility to humans. A next generation
> firewall scans the resources going through HTTP and then either transfers
> them on or drops them. The traffic is never stored and never visible to any
> administrator. The only thing that is visible is a log saying: "User
> JohnSmith tried to GET resource https://warez.example.com/
> downloads/cracked_microsoft_office_2013.exe , which contained virus
> xxxxxxxxxx".   So that's metadata.  Is that OK?  I don't know. That's why
> I'm arguing for visibility of the proxy.
>
> Same goes for a Caching proxy. As long as nobody sees the content, what's
> the harm. If the proxy is used for reading people's emails and social
> network posts, and forwarding them to the proper authorities if they seem
> too subversive, the legal and ethical concerns are different. This is the
> other reason why we need proxies to be explicitly configured. Without that,
> all of the above proxies look the same.
>
> firewall, and there's no usable way to export the data. The problem is that
> there is no technical way to distinguish this kind of product from one that
> does export decrypted traffic.
>
> Yoav
>
>
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Dec 2013 16:50:10 +0000

Hi, Peter.
Of course if legal considerations enter into it, that would affect their decisions. Currently I don't know of any different legal status for an explicit proxy vs a MitM proxy.
So here are some incentives, all of which depend on how the feature is implemented in UAs:Just being more ethical.Get the EV indication for websites that have EV certificates.For users configuring their own device (mostly phones, but some laptops) easier, better configuration. The story of why I need to install a CA certificate to make a proxy work is hard to explain. This translates directly to less helpdesk tickets.An easier time managing the proxy certificate - you can upgrade the proxy to 2048-bit RSA or ECDSA without installing a new MitM certificate on all devices.Reduced load - can avoid signing all those fake certificates.Ability to move the proxy out of the data path. A MitM needs to have both the firewall functionality (preventing direct HTTPS) and the proxy functionality on the same machine. With eproxy, the firewall can just redirect, while the proxy can be located on the side. 
That's just off the top of my head. Nobody puts HTTP proxies on the perimeter gateway. There's a good reason for that.
Yoav
Date: Wed, 4 Dec 2013 11:06:50 -0500
Subject: Re: What will incentivize deployment of explicit proxies?
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]

Hi Yoav,
When I said MITM operator, I was more referring to your customers who deploy your product. If you had two modes of operation in your product -- MITM or explicit proxy -- which would your customers choose? What is the incentive for them to choose eproxy? I think legal considerations may sometimes be one of them.

Thanks,
Peter

I wonder if MITM proxy operators have any legal concerns about viewing content owners' traffic without their consent or even an indication that the MITM is active. The proxy operators "own" their users' devices presumably but not content owners' data. I think an ideal explicit proxy would allow proxies to make their presence known to content owners.

Hi, Peter

Proxy vendor here. We can't make sweeping statements about legal concerns of proxy operators, because they vary from country to country and from state to state in federated countries.

There are also many variables that may or may not be relevant legally or ethically. One is the question of visibility to humans. A next generation firewall scans the resources going through HTTP and then either transfers them on or drops them. The traffic is never stored and never visible to any administrator. The only thing that is visible is a log saying: "User JohnSmith tried to GET resource https://warez.example.com/downloads/cracked_microsoft_office_2013.exe , which contained virus xxxxxxxxxx".   So that's metadata.  Is that OK?  I don't know. That's why I'm arguing for visibility of the proxy.

Same goes for a Caching proxy. As long as nobody sees the content, what's the harm. If the proxy is used for reading people's emails and social network posts, and forwarding them to the proper authorities if they seem too subversive, the legal and ethical concerns are different. This is the other reason why we need proxies to be explicitly configured. Without that, all of the above proxies look the same.

My company's product does not export HTTPS content. It's strictly a firewall, and there's no usable way to export the data. The problem is that there is no technical way to distinguish this kind of product from one that does export decrypted traffic.

Yoav

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 4 Dec 2013 12:04:07 -0500

7. Indication that proxy server intends to view data in the clear.
8. Ability for content server to say no. #7 and #8 amount to content server
consent.
9. Improved experience for unsupported devices.

Peter

On Wed, Dec 4, 2013 at 11:50 AM, Yoav Nir <[email-masked]> wrote:

> Hi, Peter.
>
> Of course if legal considerations enter into it, that would affect their
> decisions. Currently I don't know of any different legal status for an
> explicit proxy vs a MitM proxy.
>
> So here are some incentives, all of which depend on how the feature is
> implemented in UAs:
>
>    1. Just being more ethical.
>    2. Get the EV indication for websites that have EV certificates.
>    3. For users configuring their own device (mostly phones, but some
>    laptops) easier, better configuration. The story of why I need to install a
>    CA certificate to make a proxy work is hard to explain. This translates
>    directly to less helpdesk tickets.
>    4. An easier time managing the proxy certificate - you can upgrade the
>    proxy to 2048-bit RSA or ECDSA without installing a new MitM certificate on
>    all devices.
>    5. Reduced load - can avoid signing all those fake certificates.
>    6. Ability to move the proxy out of the data path. A MitM needs to
>    have both the firewall functionality (preventing direct HTTPS) and the
>    proxy functionality on the same machine. With eproxy, the firewall can just
>    redirect, while the proxy can be located on the side.
>
>
> That's just off the top of my head. Nobody puts HTTP proxies on the
> perimeter gateway. There's a good reason for that.
>
> Yoav
>
> ------------------------------

---

From: Werner Baumann <[email-masked]>
Date: Fri, 6 Dec 2013 21:26:55 +0100

Am Tue, 3 Dec 2013 10:53:26 -0800

> decision about security :)
Yes, that's the problem with your security team. Talking about security
for the end user, but the one party that has no saying is the end user.

Talking as an end user: It is me, and only me, who decides whom to
trust in which respect and to what extend. It is not your security team.

Sure, there are users who don't care. And there are lot of users who
can't make informed decisions, because all the necessary information is
hidden from them, many times by UI-experts who work based on the dogma
that users are stupid.

Werner

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Dec 2013 13:27:24 -0800

On 6 December 2013 12:26, Werner Baumann <[email-masked]> wrote:
> [...] the dogma that users are stupid.

Not stupid, never stupid.  It's respect.

UI surface area imposes costs upon users.  We cannot - should not -
externalize our problems by shunting them on users.

This isn't purely a security problem either; there are security
aspects to this, but they aren't the only concerns.  I expect better
of Will than to try to shift focus onto some faceless "security team",
he owns some responsibility here too.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 6 Dec 2013 14:12:55 -0800

Hey hey, there's no reason to make this personal :) I never said I
have no responsibility here. I just tried to make a funny quip that
the...more passionate factions of the larger Chromium project will be
very...passionate in their response to certain ideas. Is there a
reason you wish to make this about me all of a sudden?

Let me be clear, I in general think it's terrible to burden the user
with decisions which they are largely unable to reason about. And I
think it's wrong to expect them to have the knowledge to reason about
it. And I disagree with the argument that browser vendors must provide
all possible configuration options so users can do whatever they want.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Dec 2013 14:37:52 -0800

> reason you wish to make this about me all of a sudden?

You're a soft target, what can I say :)  The comment about
non-specific others having objections is a line that I like to push
back on because it generally isn't productive.  I didn't intend to
single you out.

You are, of course, right.  Any attempt to do this will encounter push back.

> all possible configuration options so users can do whatever they want.

Very well said.  That sets the bar pretty high, but not unreasonably
so in my opinion.  We should be treating this as a design constraint.
Anything less does everyone a disservice.

I know that most folks involved are aware of this, but I don't think
that everyone fully understands just how important this is to browser
makers in particular.  The principle is pretty widely applicable, and
everyone who interacts with people should tread carefully, but
browsers are highly exposed in this regard.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Dec 2013 00:42:56 +0200

"Don't let anybody kid you. It's all personal, every bit of business."

In this case, I disagree with Martin. This is not a problem that we can 
avoid externalizing. Deciding whether a particular proxy is acceptable 
to the user of a browser requires information that we don't have. We 
don't have it at the IETF, and we don't have it where browsers are 
developed.

A browser can learn of the existence of a TLS proxy. This information 
may come from an HTTP code, a TLS alert, DHCP, DNS, or whatever other 
discovery mechanism we can think of. Whether this proxy is acceptable 
depends on so many factors:

  * Who deployed this proxy? (can probably be deduced from name in its
    certificate, but only sort-of) Maybe your workplace is acceptable,
    but the ISP or some other workplace is not.
  * What is it doing with the cleartext traffic?  Caching? Filtering?
    Recording? Looking for terrorism/criminal activity? Assuring a
    non-hostile workplace?  There are no technical ways to know these
    things. You'll have to learn them by social means - ask the IT
    person, ask your boss, require by law all installed proxies to
    disclose what they are doing. None of this can be done by Will or
    his security team.
  * Does the product used for the proxy have a recording function that
    can be used in case of a legal mandate?  If so, what procedural
    mechanism protects the users from someone at IT using it to spy on them?
  * Does the product used for the proxy have a backdoor for
    interception?  Will and his security team don't know. The boss and
    the IT person may not know that either.

It's a complex decision affected by many objective factors and some 
subjective attributes of the user. This is not a decision we can make on 
behalf of the user. This is very different from reporting on a bad 
certificate.

Hopefully, this will be a rare decision that users don't have to face 
every day.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Dec 2013 14:50:32 -0800

On 6 December 2013 14:42, Yoav Nir <[email-masked]> wrote:
> avoid externalizing. Deciding whether a particular proxy is acceptable to
> the user of a browser requires information that we don't have. We don't have
> it at the IETF, and we don't have it where browsers are developed.

I never said that externalities weren't possible, and I don't think
that Will did either.  The key here is that we cannot afford to ask
complex, obtuse, confusing, misleading, or otherwise bad questions of
users.

It may be that we do have to ask the user something, or maybe we have
to inform them of something, but whatever that is, it has to meet a
much higher bar for clarity than I think some people are suggesting
(not everyone).

I haven't seen a UX proposal thus far that I've been satisfied with,
but then, none of them appear to be properly serious attempts, more
like ideas thrown out in the spirit of furthering the ongoing
discussion, which I think is fine, so - as may have noticed - I
haven't objected to them.

---

From: Tim Bray <[email-masked]>
Date: Fri, 6 Dec 2013 15:08:15 -0800

Whatever we ask people, a very high proportion are going to take the
default. This is independent of how much work you put into the UX.  Thus,
it’s very very important that we design things such that the “default
default” is safe, and that it’s difficult or impossible to configure a
network installation with unsafe defaults.

On Fri, Dec 6, 2013 at 2:42 PM, Yoav Nir <[email-masked]> wrote:

> the user of a browser requires information that we don't have. We don't
> have it at the IETF, and we don't have it where browsers are developed.
>
> A browser can learn of the existence of a TLS proxy. This information may
> come from an HTTP code, a TLS alert, DHCP, DNS, or whatever other discovery
> mechanism we can think of. Whether this proxy is acceptable depends on so
> many factors:
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Dec 2013 01:32:09 +0200

It's hard to make assertions about the UX without knowing how often 
you're going to come up against a proxy that you haven't seen before. We 
are willing to cooperate much more with a "first time wizard" than with 
something that pops up every few minutes.

The only TLS proxy I ever interact with is on the wired LAN at work. So 
if I get a new computer, I have to teach it only once about a proxy (or 
install the CA certificate with a MitM proxy). If that's all that is 
going to be, we can go with a UI like this

+
| WARNING
|
| You can't access your destination: https://www.facebook.com because a 
TLS proxy is installed on this network
|
| The proxy is authenticated, and is called "sslproxy.example.com". 
Working through this proxy would mean:
|  * that all your SSL traffic is decrypted by the proxy
|  * that all your personal information, passwords and credit card 
numbers are visible to the proxy
|  * that the proxy could potentially impersonate you for purposes of fraud.
|
| This browser is blocking communications since we cannot ascertain 
whether this proxy is harmful or benign.
|
| TLS proxies can only be used if they are configured. To learn more 
about trusted proxies, click here
+

I think users can live with that, and read the help, and go to the 
Tools->Options, or Safari->Preferences, or about:config and set that 
proxy. This is assuming it's a very rare event. If we get TLS proxies at 
ISPs, Coffee shops, airports, hotels, and schools as well as workplaces, 
we'll have to figure something else out.

On 7/12/13 1:08 AM, Tim Bray wrote:
> default. This is independent of how much work you put into the UX. 
>  Thus, it’s very very important that we design things such that the 
> “default default” is safe, and that it’s difficult or impossible to 
> configure a network installation with unsafe defaults.
>
>
> On Fri, Dec 6, 2013 at 2:42 PM, Yoav Nir <[email-masked] 
>     In this case, I disagree with Martin. This is not a problem that
>     we can avoid externalizing. Deciding whether a particular proxy is
>     acceptable to the user of a browser requires information that we
>     don't have. We don't have it at the IETF, and we don't have it
>     where browsers are developed.
>
>     A browser can learn of the existence of a TLS proxy. This
>     information may come from an HTTP code, a TLS alert, DHCP, DNS, or
>     whatever other discovery mechanism we can think of. Whether this
>     proxy is acceptable depends on so many factors:
>
>     It's a complex decision affected by many objective factors and
>     some subjective attributes of the user. This is not a decision we
>     can make on behalf of the user. This is very different from
>     reporting on a bad certificate.
>
>     Hopefully, this will be a rare decision that users don't have to
>     face every day.
>
>     Yoav
>
>
>
>         On Fri, Dec 6, 2013 at 1:27 PM, Martin Thomson
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             On 6 December 2013 12:26, Werner Baumann
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Dec 2013 15:35:33 -0800

On 6 December 2013 15:32, Yoav Nir <[email-masked]> wrote:
> The only TLS proxy I ever interact with is on the wired LAN at work.

If that's the case, then I actually don't have a big problem with the
UX you proposed.  I like the fact that there is no "Yah, whatever, get
out of my way" button anywhere.

I don't know how this solves the captive portal problem, but that
might be a different branch.

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 07 Dec 2013 02:13:40 +0000

+1

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "William Chan (陈智昌)" <[email-masked]>; "Martin Thomson" 
<[email-masked]>
Cc: "Werner Baumann" <[email-masked]>; "HTTP Working 
Group" <[email-masked]>
Sent: 7/12/2013 11:42:56 a.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>subjective attributes of the user. This is not a decision we can make 
>on behalf of the user. This is very different from reporting on a bad 
>certificate.
>
>><[email-masked]> wrote:
>>><[email-masked]> wrote:

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 07 Dec 2013 02:13:00 +0000

One thing.

I think it would be a bit of a push to try to force companies that want 
to deploy a MitM to obtain a CA-issued signing cert for signing the 
spoofed certs.  Many will choose a local CA-issued (e.g. the AD CA 
server) but also many will choose self-signed certs for this.

So presuming that the proxy will be authenticated may not be that 
reliable.

Also I don't think lay people really will have much of a clue what TLS 
means.

I think it's reasonable to take a precautionary default stance as 
proposed (block until allowed).  But each browser vendor will probably 
make their own decision as to what the default is.

I imagine some browser vendors may wish to allow in some environments 
that this can be centrally managed?  e.g. by Group Policy.  This then 
may take away the warning (although a browser could still put up a 
warning to let people know the decision had already been made for them 
by their sysadmin).  That's why I think some permanent visual indicator 
could be useful.  Even if it had a question mark somewhere in it so 
people could see why they were seeing that indicator.

I think though browser vendors will get serious complaints if there's no 
quick easy way for a user to say yes use the proxy.  Each user will 
become a support call.

But these are all browser UI decisions.

We are talking about the protocol here.  I don't think we should pare 
back the protocol to remove choice for users.  Browsers can remove 
choice by deciding what choice to make on behalf of the user, we don't 
have to take the choice away in the protocol.  That leaves zero wiggle 
room if it turns out we made the wrong choice.  Who knows what basis a 
browser may use to choose a default action.  E.g. depending on where the 
proxy is, what site is being visited, some external information etc the 
default may vary and in unresolvable situations the user can be asked.

Adrien

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "Tim Bray" <[email-masked]>
Cc: "William Chan (陈智昌)" <[email-masked]>; "Martin Thomson" 
<[email-masked]>; "Werner Baumann" 
<[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 7/12/2013 12:32:09 p.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>you're going to come up against a proxy that you haven't seen before. 
>We are willing to cooperate much more with a "first time wizard" than 
>with something that pops up every few minutes.
>
>proxy. This is assuming it's a very rare event. If we get TLS proxies 
>at ISPs, Coffee shops, airports, hotels, and schools as well as 
>workplaces, we'll have to figure something else out.
>
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Dec 2013 07:29:39 +0200

On 7/12/13 4:13 AM, Adrien de Croy wrote:
>
> One thing.
>
> I think it would be a bit of a push to try to force companies that 
> want to deploy a MitM to obtain a CA-issued signing cert for signing 
> the spoofed certs.  Many will choose a local CA-issued (e.g. the AD CA 

To be clear, when we're talking about explicit proxy, we mean an 
alternative to the MitM, one that does not require spoofing certs. The 
client would connect directly to the proxy, validating the proxy 
certificate, and then ask the proxy to GET or POST to the original 
server. So the proxy certificate is a regular DV or EV certificate that 
CAs are willing to issue cheaply. So, not particularly onerous.
> Also I don't think lay people really will have much of a clue what TLS 

Perhaps, but they do know what encryption is for, and they (hopefully) 
understand why you don't allow someone you don't trust to see your 
personal information, credit card number, etc.

> by their sysadmin).  That's why I think some permanent visual 
> indicator could be useful.  Even if it had a question mark somewhere 
> in it so people could see why they were seeing that indicator.
>
> I think though browser vendors will get serious complaints if there's 
> no quick easy way for a user to say yes use the proxy. Each user will 
> become a support call.
>
> browser may use to choose a default action.  E.g. depending on where 
> the proxy is, what site is being visited, some external information 
> etc the default may vary and in unresolvable situations the user can 
> be asked.

Agree. All we can do in protocol is to inform the client that a 
mandatory proxy exists (similar to today's captive portal), and provide 
a protocol for connecting to such a proxy and moving information between 
client, server and proxy.  What implementation will do with this 
information, and how they will present some or all of it to the user is 
up to the browser vendor.

Yoav

---

From: Albert Lunde <[email-masked]>
Date: Sat, 07 Dec 2013 08:25:47 -0600

Is there any useful role for having a physical file format and file 
extension that says "here is a proxy's address and TLS certificate", 
such that if one imported it into a browser it would be trusted?

I can see how this could be a security risk via spoofing, but it might 
cut out some of the protocol/user interface dance in getting a trusted 
proxy established, by providing an out-of-band way to communicate the 
trust requirements in a given setting.

Signing the file as a whole seems like a good idea, but I'd rather have 
plain text and one or more base-64 blobs than a pure binary format that 
would be easier use to hide an executable.

I am assuming typical users would double click on the file to process 
it, even though that is frequently a bad idea.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Dec 2013 17:17:51 +0200

> such that if one imported it into a browser it would be trusted?

That depends on how we authenticate the proxy. My idea is to use the 
regular HTTPS authentication for the proxy. So we only need an origin, 
as in "https://sslproxy.example.com", and the authentication can be done 
by checking that either the CN or alternate name is 
"sslproxy.example.com".  There is a cost associated with this of getting 
a certificate from a public CA. Alternatively we can do the DANE thing. 
If we want the authentication to be outside of the trusted CA or trusted 
DNS, we can create a file format that includes a public key. I think a 
simple origin is good enough.

> trust requirements in a given setting.

We can post a sign on the wall saying "everyone please set your browser 
to trust the TLS proxy https://sslproxy.example.com "

>
> Signing the file as a whole seems like a good idea, but I'd rather 
> have plain text and one or more base-64 blobs than a pure binary 
> format that would be easier use to hide an executable.
>

That's an attack vector, because the proxy is where the browser goes to 
find all resources on the web. So if double-clicking gets me to trust 
sslproxy.stasi.de (we can't use NSA as an example always, right?) we're 
not in a good place.

Yoav

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Dec 2013 13:33:20 +1100

This thread makes me wonder if, rather than focusing on introducing a new kind of proxy to address the “enterprise/school/prison” (ESP) use case, we* should instead focus on fixing how trust roots are configured and managed in browsers / OSs. 

I say that because the requirement is already being met in the market; ESPs are able to inspect and modify traffic as it goes by on the wire by configuring a new trust root. It’s just that there are some nasty side effects brought about by that solution.

We may be able to mitigate the bad effects of the current solution — e.g., by allowing the user to understand when their browser is using a trust root that was added later (AIUI some versions of Chrome already do this visually?), by giving the user more fine-grained control over what new certificates can be used for (to address the BYOD user), etc. 

If we can do that, we avoid the potential for new security choices in front of non-enterprise end users, ones that Will is justifiably nervous about (since anything that would allow a MITM warning to be clicked through is a VERY attractive attack vector).

The one thing that wouldn’t be addressed by this approach is the potential for a “semi-trusted” proxy that can see inside encryption and yet promises e2e integrity. So, to me it seems like we should be focusing on the use cases that lead us there (rather than on that particular solution, yet).

The one that’s been clearly identified is shared caching; is there another?

Cheers,

* for some value of “we". Not every problem needs to be hit with an HTTP-shaped hammer.

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

---

From: Roberto Peon <[email-masked]>
Date: Sun, 8 Dec 2013 20:17:26 -0800

On Sun, Dec 8, 2013 at 6:33 PM, Mark Nottingham <[email-masked]> wrote:

> This thread makes me wonder if, rather than focusing on introducing a new
> kind of proxy to address the “enterprise/school/prison” (ESP) use case, we*
> should instead focus on fixing how trust roots are configured and managed
> in browsers / OSs.
>
> I say that because the requirement is already being met in the market;
> ESPs are able to inspect and modify traffic as it goes by on the wire by
> configuring a new trust root. It’s just that there are some nasty side
> effects brought about by that solution.
>
> We may be able to mitigate the bad effects of the current solution — e.g.,
> by allowing the user to understand when their browser is using a trust root
> that was added later (AIUI some versions of Chrome already do this
> visually?), by giving the user more fine-grained control over what new
> certificates can be used for (to address the BYOD user), etc.
>
> If we can do that, we avoid the potential for new security choices in
> front of non-enterprise end users, ones that Will is justifiably nervous
> about (since anything that would allow a MITM warning to be clicked through
> is a VERY attractive attack vector).
>
> The one thing that wouldn’t be addressed by this approach is the potential
> for a “semi-trusted” proxy that can see inside encryption and yet promises
> e2e integrity. So, to me it seems like we should be focusing on the use
> cases that lead us there (rather than on that particular solution, yet).
>

malware/virus scanning

-=R

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 09 Dec 2013 04:26:32 +0000

and DLP (data leakage protection)

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 9/12/2013 5:17:26 p.m.
Subject: Re: What will incentivize deployment of explicit proxies?
>>This thread makes me wonder if, rather than focusing on introducing a 
>>new kind of proxy to address the “enterprise/school/prison” (ESP) use 
>>case, we* should instead focus on fixing how trust roots are 
>>configured and managed in browsers / OSs.
>>
>>ESPs are able to inspect and modify traffic as it goes by on the wire 
>>by configuring a new trust root. It’s just that there are some nasty 
>>side effects brought about by that solution.
>>
>>We may be able to mitigate the bad effects of the current solution — 
>>e.g., by allowing the user to understand when their browser is using a 
>>trust root that was added later (AIUI some versions of Chrome already 
>>do this visually?), by giving the user more fine-grained control over 
>>what new certificates can be used for (to address the BYOD user), etc.
>>
>>front of non-enterprise end users, ones that Will is justifiably 
>>nervous about (since anything that would allow a MITM warning to be 
>>clicked through is a VERY attractive attack vector).
>>
>>The one thing that wouldn’t be addressed by this approach is the 
>>potential for a “semi-trusted” proxy that can see inside encryption 
>>and yet promises e2e integrity. So, to me it seems like we should be 
>>focusing on the use cases that lead us there (rather than on that 
>>particular solution, yet).
>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 08:40:16 +0000

Messing with root stores sounds like a TLS MITM rather than addressing proxies in HTTP since not all such stores are protocol specific. That would be a significant issue.

S

Adrien de Croy <[email-masked]> wrote:
>>> > trust in which respect and to what extend. It is not your security
>
>>>team.
>>> >
>>> > can't make informed decisions, because all the necessary
>information 
>>>is

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 9 Dec 2013 10:55:43 -0500

+1.

Also, as I mentioned in another thread, cert pinning and DANE promise ways
to defeat MITMs in the future. Our protocol should provide support for
legitimate proxies even assuming MITM no longer works.

Peter

On Mon, Dec 9, 2013 at 3:40 AM, Stephen Farrell
<[email-masked]>wrote:

>
> Messing with root stores sounds like a TLS MITM rather than addressing
> proxies in HTTP since not all such stores are protocol specific. That would
> be a significant issue.
>
> S
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Dec 2013 10:59:13 +1100

> Messing with root stores sounds like a TLS MITM rather than addressing proxies in HTTP since not all such stores are protocol specific. That would be a significant issue.

People are already messing with root stores. What I'm talking about below is placing constraints on how they can do that, and making the messing more visible to end users.

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 00:26:13 +0000

On 12/09/2013 11:59 PM, Mark Nottingham wrote:
>> Messing with root stores sounds like a TLS MITM rather than
>> addressing proxies in HTTP since not all such stores are protocol
>> specific. That would be a significant issue.
> 
> People are already messing with root stores. 

Really? Using some IETF standard protocol? We actually have
one of those (RFC 5934) that afaik has had zero deployment
even though if I recall correctly, the folks behind that
did try to interest browser makers. I think they were told
that the browsers preferred to manage roots as part of their
s/w update. Has that changed?

> What I'm talking about
> below is placing constraints on how they can do that, and making the
> messing more visible to end users.

And you're going to do that analysis of how that'd impact
on all other consumers of TLS?

I'll also be interested in how end users will be protected
from root-insertion attacks from pretty much anywhere if
this becomes anywhere near common.

S.

>>> ------ Original Message ------ From: "Roberto Peon"
>>> <[email-masked]> To: "Mark Nottingham" <[email-masked]> Cc:
>>> "HTTP Working Group" <[email-masked]> Sent: 9/12/2013
>>> 5:17:26 p.m. Subject: Re: What will incentivize deployment of
>>> explicit proxies?
>>>> 
>>>> 
>>>> 
>>>>> I say that because the requirement is already being met in
>>>>> the
>>> market;
>>>>> by configuring a new trust root. It’s just that there are
>>>>> some nasty side effects brought about by that solution.
>>>>> 
>>>>> We may be able to mitigate the bad effects of the current
>>>>> solution — e.g., by allowing the user to understand when
>>>>> their browser is using
>>> a
>>>>> what new certificates can be used for (to address the BYOD
>>>>> user),
>>> etc.
>>>>> 
>>>>> front of non-enterprise end users, ones that Will is
>>>>> justifiably nervous about (since anything that would allow a
>>>>> MITM warning to be clicked through is a VERY attractive
>>>>> attack vector).
>>>>> 
>>>>> The one thing that wouldn’t be addressed by this approach is
>>>>> the potential for a “semi-trusted” proxy that can see inside
>>>>> encryption and yet promises e2e integrity. So, to me it seems
>>>>> like we should be focusing on the use cases that lead us
>>>>> there (rather than on that particular solution, yet).
>>>>> 
>>>>>> Am Tue, 3 Dec 2013 10:53:26 -0800 schrieb William Chan (陈智
>>>>>> 昌) <[email-masked]>:
>>>>>> 
>>>>>>> 
>>>>>>> <pushback> I can probably expect to be tarred and
>>>>>>> feathered by my security
>>>>> team
>>>>>>> if I tell them we need to put up a UI asking the end user
>>>>>>> to make
>>> a
>>>>>>> decision about security :) </pushback>
>>>>>>> 
>>>>>> Yes, that's the problem with your security team. Talking
>>>>>> about
>>>>> security
>>>>>> for the end user, but the one party that has no saying is
>>>>>> the end
>>>>> user.
>>>>>> 
>>>>>> Talking as an end user: It is me, and only me, who decides
>>>>>> whom to trust in which respect and to what extend. It is
>>>>>> not your security
>>> 
>>>>> team.
>>>>>> 
>>>>>> Sure, there are users who don't care. And there are lot of
>>>>>> users
>>> who
>>>>>> hidden from them, many times by UI-experts who work based
>>>>>> on the
>>>>> dogma
>>>>>> that users are stupid.
>>>>>> 
>>>>>> Werner
>>>>>> 
>>>>> 
>>>>> -- Mark Nottingham   http://www.mnot.net/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
>> 
> 
> -- Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Dec 2013 11:37:35 +1100

On 3 Dec 2013, at 7:09 pm, William Chan (陈智昌) <[email-masked]> wrote:

>> CDNs, accelerators/caches, traffic-optimizers/traffic-shapers have usecases that wouldn't require the browser to give up any confidentiality (that the site didn't direct them to do, at least).
> 
> I'm going to ignore the CDN case, since I don't think they're explicit proxies from a UA's perspective (unless I'm misunderstanding). How do you serve cached content without knowing the URL of the resource? Are you differentiating between object confidentiality and metadata (URL/headers) confidentiality here? I think these questions apply to the other use cases you refer to, but am not completely sure.

Right. To be clear, CDNs *might* be interested in mechanisms that allowed them to guarantee integrity to their clients while still caching (for example), but that's separate from the need to introduce a new flavour of proxy to the ecosystem.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Dec 2013 11:44:21 +1100

On 10 Dec 2013, at 11:26 am, Stephen Farrell <[email-masked]> wrote:

> Really? Using some IETF standard protocol?

In the sense that when you start a new job, you're told to go to a certain URL (RFC3986) and download (RFC2616) a new CA cert and install it into your root store, yes...

Of course, other folks are using proprietary protocols to automate that, but I'm not talking about standardising that. I'm talking about what the browsers do with certs once they're in the store.

> We actually have

Dunno. Browser guys?

> on all other consumers of TLS?

Sure. I'm thinking in terms of changes in browser behaviour (along the lines that some have already explored), not changing TLS, or even certs, necessarily.

> this becomes anywhere near common.

Well, at the least, they'd be as protected as they are now...

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 00:50:44 +0000

On 12/10/2013 12:44 AM, Mark Nottingham wrote:
> Sure. I'm thinking in terms of changes in browser behaviour (along
> the lines that some have already explored), not changing TLS, or even
> certs, necessarily.

But there is a problem here - as I understand it many root
stores have no controls over the protocols with which the
roots can be used so if you insert a new root then you will
also have affects on non-HTTP protocols that use TLS.

What I've not seen is anyone who's proposing such changes
(that do affect TLS) volunteering to do that analysis.
I'd say its not an easy piece of work but absolutely
necessary and it might well turn up a conclusion that
this is a bad idea globally.

S.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 9 Dec 2013 17:45:48 -0800

> s/w update. Has that changed?

Mozilla controls its own SSL root certificates. Other browsers use the
OS configured SSL root certificates. See
http://techlib.barracuda.com/BWFSSLDefaultCert for an example of
documentation provided on how to configure this.

> on all other consumers of TLS?

Just so we're clear, the common methods already in use impact all
consumers of TLS, not just browsers. They're getting added to the
system certificate store, so they affect all applications. But the
primary reason that it gets installed in the system certificate store
is because these proxies want to MITM browser connections.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 02:02:11 +0000

> is because these proxies want to MITM browser connections.

Right. And if vendors, operators or users do that that's their
responsibility. But if we do/endorse that, then we (the IETF)
have to bear some responsibility for other uses of TLS or we're
not doing our job. At least to the level of knowing what might
be broken, but even that's a huge job. So I really think the
HTTP proxy issue is best addressed via HTTP mechanisms to be
honest.

S.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 9 Dec 2013 21:06:56 -0500

> > s/w update. Has that changed?
I am extremely skeptical of the notion that the problem with root
certificate management is that it needs to be easier to automate the
addition of new root certs on a per install basis.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Dec 2013 13:12:51 +1100

> also have affects on non-HTTP protocols that use TLS.

Yes, that's already happening today. Such controls would indeed be nice.

<https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf> is a nice writeup, and lists a few products that do this at the end. There are others; e.g., <http://wiki.squid-cache.org/Features/SslBump>.

The problem is that installing a new CA is *extremely* common; try searching for "install CA certificate" and you'll see many, many results like <http://community.web.cern.ch/faq/certificate-installation-android>  <-- note that it's even happening where the Web started!

Those CAs then have unlimited power to MITM communication (whether that's their intent or not), and cannot easily be detected when doing so.

> this is a bad idea globally.

AIUI we're already there -- i.e., people think it's a bad idea, but it's happening. 

To be crystal clear -- I'm not talking about making it easier to install CAs in browsers. I'm wondering if we can *constrain* the current practice in a meaningful way, so as to limit the damage of this already-widespread practice.

We may not be able to (either because it's too hard, or because the IETF isn't the right place to do it), but it's worth talking about. One interesting discussion that's related:
  https://code.google.com/p/chromium/issues/detail?id=81623  (CLOSED WONTFIX)

What I don't want to do is spend months-to-years developing a new kind of explicit proxy in HTTP in the *hope* that it'll somehow magically supplant these devices, without some sort of evidence that it has a chance of doing so.

Cheers,

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 9 Dec 2013 18:26:12 -0800

> What I don't want to do is spend months-to-years developing a new kind of explicit proxy in HTTP in the *hope* that it'll somehow magically supplant these devices, without some sort of evidence tha…

+1, hence the email subject: "What will incentivize deployment of
explicit proxies?"

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 02:37:38 +0000

On 12/10/2013 02:12 AM, Mark Nottingham wrote:
>>> Sure. I'm thinking in terms of changes in browser behaviour
>>> (along the lines that some have already explored), not changing
>>> TLS, or even certs, necessarily.
>> 
>> But there is a problem here - as I understand it many root stores
>> have no controls over the protocols with which the roots can be
>> used so if you insert a new root then you will also have affects on
>> non-HTTP protocols that use TLS.
> 
> <https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf> is a
> nice writeup, and lists a few products that do this at the end. There
> are others; e.g., <http://wiki.squid-cache.org/Features/SslBump>.
> 
> The problem is that installing a new CA is *extremely* common; 

Do we have any numbers on that? Extremely common wouldn't match
my impression but I've nothing much on which to base that.

> try
> searching for "install CA certificate" and you'll see many, many
> results like
> <http://community.web.cern.ch/faq/certificate-installation-android>
> <-- note that it's even happening where the Web started!

Well that's pretty different isn't it - the cern one seems to be a
new CA for an SSO system and not for a MITM system. It could do
both I guess, but it looks like eduroam and local SSO. If its not
a MITM then that is what installing a new root is supposed to be
for. That is, there are no fake certificates involved.

> Those CAs then have unlimited power to MITM communication (whether
> that's their intent or not), and cannot easily be detected when doing
> so.

Yes. Mpodulo things like NameConstraints and other application layer
constraints, none of which are widely done. But a lot of those more
complex PKI things could be done if desired. I also don't see any
interest in going down that road though.

>> What I've not seen is anyone who's proposing such changes (that do
>> affect TLS) volunteering to do that analysis. I'd say its not an
>> easy piece of work but absolutely necessary and it might well turn
>> up a conclusion that this is a bad idea globally.
> 
> To be crystal clear -- I'm not talking about making it easier to
> install CAs in browsers. I'm wondering if we can *constrain* the
> current practice in a meaningful way, so as to limit the damage of
> this already-widespread practice.
> 
> We may not be able to (either because it's too hard, or because the
> IETF isn't the right place to do it), but it's worth talking about.
> One interesting discussion that's related: 

Yeah. Its not my code but I'd have to say that its an ongoing
surprise for me that even when browsers know for sure that they're
not talking to https://example.com that they don't tell the user.
(E.g. if example==google, some of 'em do know and for sure, and
there are some such names for all browsers I think.)

> What I don't want to do is spend months-to-years developing a new
> kind of explicit proxy in HTTP in the *hope* that it'll somehow
> magically supplant these devices, without some sort of evidence that
> it has a chance of doing so.

Fully agree. If people set up with irreconcilable requirements
and aren't willing to change then the outcome will be the same
kind of scenario we have now. There's not much value in thrashing
about for ages before discovering that. (And before you ask, I'm
already clearly willing to discuss anathema decrypting proxies of
the HTTP variety:-)

>From my purely personal pov -  I figure that one of CT or DANE
or mucking about with JS will eventually ferret out the TLS MITM
attack boxes anyway so the do-nothing scenario isn't necessarily
that terrible in the medium term. I'd have thought the MITM folk
would be more keen to move into the daylight though, but if
they're not, they're not.

S.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 9 Dec 2013 18:47:30 -0800

> there are some such names for all browsers I think.)

I think the answers are all in the bug listed above. If it's still
unclear, please say what's unclear. In your example, when we know
you're not talking to Google, we show an error. We disable this error
in certain situations
(https://www.imperialviolet.org/2011/05/04/pinning.html):

"""
What about MITM proxies, Fiddler etc?

There are a number of cases where HTTPS connections are intercepted by
using local, ephemeral certificates. These certificates are signed by
a root certificate that has to be manually installed on the client.
Corporate MITM proxies may do this, several anti-virus/parental
control products do this and debugging tools like Fiddler can also do
this. Since we cannot break in these situations, user installed root
CAs are given the authority to override pins. We don't believe that
there will be any incompatibility issues.
"""

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 10 Dec 2013 18:43:55 +1300

> HTTP proxy issue is best addressed via HTTP mechanisms to be

And there is the rub. You see there are no HTTP mechanisms until the TLS
has been MITM'd away.

Amos

---

From: Albert Lunde <[email-masked]>
Date: Tue, 10 Dec 2013 00:14:04 -0600

I would tend to argue that, in the web browser case, the list of 
configured trusted proxies and/or configured trusted CAs for proxies 
should go in a separate "bucket" from trusts for CAs used web servers, 
and should distinguish GET vs CONNECT tunnels.

It's not so much that typical end users care about trusting a FOO-server 
vs a BAR-server (though maybe they should), but it should be possible to 
manage the proxies in use by some means, and that software  may care 
about these distinctions.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 9 Dec 2013 23:52:41 -0800

I don't fully understand your email. From what I can tell, the main point
is that there are some subtle differences amongst trusted CAs for proxies
vs origin servers, and software should distinguish these. It may be true
that software can distinguish the differences here, but it may be very
difficult for end users to grok the differences.

On Mon, Dec 9, 2013 at 10:14 PM, Albert Lunde <[email-masked]> wrote:

> configured trusted proxies and/or configured trusted CAs for proxies should
> go in a separate "bucket" from trusts for CAs used web servers, and should
> distinguish GET vs CONNECT tunnels.
>
> manage the proxies in use by some means, and that software  may care about
> these distinctions.
>
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Dec 2013 18:22:09 +0200

> Those CAs then have unlimited power to MITM communication (whether that's their intent or not), and cannot easily be detected when doing so.

Even worse, browsers have to work "everywhere". So when faced with such 
MitM CAs, they disable mitigation features such as public key pinning. 
Nor can they afford to change this behavior unless organizations move 
away from using these CAs for MitM. A corporate CA used for corporate 
servers would not need the browser to disable pinning.

But because we don't want to burden the user, we use the heuristic 
installed CA == corporate CA == legitimate MitM proxy. That means miss 
those CAs that got installed through social engineering or a technical 
flaw, but are not legitimate, even though pinning was explicitly 
designed to catch them.
> To be crystal clear -- I'm not talking about making it easier to install CAs in browsers. I'm wondering if we can *constrain* the current practice in a meaningful way, so as to limit the damage of…

I don't see how we can constrain it much. We can offer a better 
alternative - a TLS proxy without a CA - and if (when?) using them 
becomes sufficiently wide-spread, a different value of "we" might set a 
date at which browsers will no longer default to disabling pinning when 
faced with corporate CAs signing pinned servers.

The problem is that the incentives here are all skewed:

  * For the servers, pinning might get them in trouble, and agreeing to
    a connection from an explicit proxy means assuming some risk
  * For proxy vendors supporting both MitM and explicit proxy,
    configurable by the network administrator is easy - small cost to
    us. We can even support both for BC.
  * For the network administrator MitM works, so why risk turning on
    eproxy, which might break something.
  * Browser vendors can implement eproxy, but that might be one of those
    things that people fail to configure properly. Also, the plan above
    calls for them to butt heads with the network administrators, who
    might say, "this browser doesn't work - use that browser (which
    still disables pins by default)". I don't think it's their job to
    force people into good security practices.
  * Users (especially those that use their own devices or Firefox on the
    corporate device) still have to follow some procedure to define the
    proxy. It can (but does not have to) be easier than adding a CA

So getting rid of MitM proxies and replacing them with explicit proxies 
requires (a) administrators that are willing to do what's right for 
security at the expense of some support calls in the short term, and (b) 
browser vendors that are willing to risk some disconnects with sites 
that deploy PKP, which is likely to be the same sites that now deploy 
STS - Google, Facebook, Yahoo, Paypal - so, important sites. If you were 
working on Chrome, would you be willing to have the IT department at 
some places of work sending everyone an email that "Following the Chrome 
update from yesterday, Chrome can no longer be used with Google, 
Facebook, Yahoo, Paypal and some others. Please use one of the supported 
browsers, like ..." ?

> What I don't want to do is spend months-to-years developing a new kind of explicit proxy in HTTP in the *hope* that it'll somehow magically supplant these devices, without some sort of evidence tha…
I work for a vendor that makes such devices. We'd be happy to change the 
way they work. It's a win for us in many senses. I just don't know if 
it's as much of a win for the other players.

Yoav

---

From: Peter Lepeska <[email-masked]>
Date: Tue, 10 Dec 2013 11:25:06 -0500

"Since we cannot break in these situations, user installed root
CAs are given the authority to override pins."

Wouldn't browser manufacturers prefer to come up with a way to allow
proxies to operate that does not defeat the purpose of deploying pinned
certs? Wouldn't proxy vendors (often security companies) prefer not to slow
the pace of security improvements in web browsers? Accepting MITMs, and
taking the teeth out of security functionality in order to allow them to
continue to work, creates a stalemate situation where security
and usability cannot advance.

Isn't it the purpose of protocol designers to break this type of stalemate?

Peter

---

From: Peter Lepeska <[email-masked]>
Date: Tue, 10 Dec 2013 12:59:09 -0500

Yoav,

Good summary of conflicting incentives. I think the key is that eproxy
needs to represent a security improvement. Going from MITM to eproxy should
be seen as going from the insecure 1.x MITM way to do encrypted proxying to
the 2.x more secure way to do it.

Eproxy includes support for:

   - Pinned certs
   - No transitive trust
   - In general, no certificate forgery
   - Any node refusal (or other related scheme that improves server
   visibility and/or negotiates consent)
   - Additional security features??

Improved security interests everyone (servers, proxies, network admins,
browsers, users) as long as the glitches of upgrading are short term and
manageable.

Lastly, it's worth pointing out that this discussion on incentives has
largely focused on the enterprise use case. The service provider (Darlene
and Eliot in Mark's user stories --
https://github.com/http2/http2-spec/wiki/Proxy-User-Stories) will be more
impacted by the increase in encrypted traffic due to HTTP2 requiring TLS
and therefore much more interested in an eproxy standard that makes
optimization possible. I work on such an optimizing proxy for satellite
networks and TLS sites, even with HTTP2, are dramatically slower (often as
much as 4x slower) due to the fact that prefetching/caching/acceleration is
blocked. Without eproxy support, service providers will increasingly look
for ways to implement MITM-based solutions.

Peter

On Tue, Dec 10, 2013 at 11:22 AM, Yoav Nir <[email-masked]> wrote:

>> <https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf> is a nice
>> writeup, and lists a few products that do this at the end. There are
>> others; e.g., <http://wiki.squid-cache.org/Features/SslBump>.
>>
>> The problem is that installing a new CA is *extremely* common; try
>> searching for "install CA certificate" and you'll see many, many results
>> like <http://community.web.cern.ch/faq/certificate-installation-android>
>> Those CAs then have unlimited power to MITM communication (whether that's
>> their intent or not), and cannot easily be detected when doing so.
>>
>
> MitM CAs, they disable mitigation features such as public key pinning. Nor
> can they afford to change this behavior unless organizations move away from
> using these CAs for MitM. A corporate CA used for corporate servers would
> not need the browser to disable pinning.
>
> flaw, but are not legitimate, even though pinning was explicitly designed
> to catch them.
>
>> To be crystal clear -- I'm not talking about making it easier to install
>> CAs in browsers. I'm wondering if we can *constrain* the current practice
>> in a meaningful way, so as to limit the damage of this already-widespread
>> practice.
>>
>
> alternative - a TLS proxy without a CA - and if (when?) using them becomes
> sufficiently wide-spread, a different value of "we" might set a date at
> which browsers will no longer default to disabling pinning when faced with
> corporate CAs signing pinned servers.
>
> browser vendors that are willing to risk some disconnects with sites that
> deploy PKP, which is likely to be the same sites that now deploy STS -
> Google, Facebook, Yahoo, Paypal - so, important sites. If you were working
> on Chrome, would you be willing to have the IT department at some places of
> work sending everyone an email that "Following the Chrome update from
> yesterday, Chrome can no longer be used with Google, Facebook, Yahoo,
> Paypal and some others. Please use one of the supported browsers, like ..."
> ?
>
>  We may not be able to (either because it's too hard, or because the IETF
>> isn't the right place to do it), but it's worth talking about. One
>> interesting discussion that's related:
>> What I don't want to do is spend months-to-years developing a new kind of
>> explicit proxy in HTTP in the *hope* that it'll somehow magically supplant
>> these devices, without some sort of evidence that it has a chance of doing
>> so.
>>
> way they work. It's a win for us in many senses. I just don't know if it's
> as much of a win for the other players.
>
> Yoav
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Dec 2013 10:29:06 +1300

> the 2.x more secure way to do it.

There is one extremely simple measure which I and many in the proxy user 
community have been campaigning for some time now.

This is one of the use-cases for MITM which is being deployed *only* 
because ccertain configuration options are missing from browsers:
  * MITM all port 80 traffic from clients
  * 3xx redirect all http:// URLs to https://
  * MITM port 443 traffic from clients
  * un-map https:// URL back to http:// for WAN connection.

Sounds daft reason encrypting LAN connections while WAN ones are 
un-encrypted, but this meets corporates policies in places and there is 
potential that the encryption can also be extended by the proxy over 
untrusted networks to a remote POP before the decryption is needed.
  Please lets kill this use-case before it becomes more popular.

It seems to be a trivial and reasonable request for browsers to attempt 
to use TLS when talking to a proxy. No padlocks or user feedback 
mechanisms necessary - its not offering user-relevant security but 
*network* security. Simply extend the proxy config dialog/options to 
{hostname, port, TLS Y/N tickbox, button to upload cert for the proxy 
verification} is all the UI required (if any).

Yet the amount of pushback on implementing that simple security 
enhancement is enormous. All the talk of complexity implementing UI 
feedback sounds like FUD obscuring the detail that this is a small 
incremental step that could be taken yesterday to improve security.
  So what if the proxy TLS connection is decrypted at the proxy? there is 
no guarantee of e2e security here and UI should absolutely not be 
telling the user green-padlock style stuff about this.
  Uploading a specific cert for validating the proxy *and only 
connections to that proxy* allows the browser to indicate when MITM is 
happening between them.

If it works the TLS is invisible, if MITM is detected *that* can be 
announced, if it fails for other reasons alternatives should be taken 
without bothering the user.

Amos

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 10 Dec 2013 21:31:24 +0000

------ Original Message ------
From: "Peter Lepeska" <[email-masked]>
>... due to HTTP2 requiring TLS ...

I thought this was nowhere near reaching consensus.

Adrien

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 11 Dec 2013 13:50:14 +0100

> these devices, without some sort of evidence that it has a chance of doing

The trust level of the endpoint site is not the same as the trust level of
the gateway. It may surprise you but in some case the trust level of the
gateway is way higher than a random web site on the other side of the
world, so not being able to distinguish in the web client between the
signals of the web site and of the gateway is a big security problem.

-- 
Nicolas Mailhot

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Dec 2013 17:22:45 -0800

> signals of the web site and of the gateway is a big security problem.
So, I think this is the point at which someone traditionally says "the term
'trust' is overloaded here", and it seems to fall to me this time.  An end
user or IT staff member may have greater confidence that a specific type of
proxy is not delivering malware than it has in a random web site, since the
proxy may be developed to remove malware.  For that value of "trust", your
statement makes sense.

The end user/IT staff member cannot have great confidence that the proxy is
delivering the content intended by the random web site.  It can at most
match the same confidence.

So let's be a little careful with terms like "trust level", please.

thanks,

Ted

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 Dec 2013 08:22:46 +0000

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
>
>What I don't want to do is spend months-to-years developing a new kind 
>of explicit proxy in HTTP in the *hope* that it'll somehow magically 
>supplant these devices, without some sort of evidence that it has a 
>chance of doing so.
>
I'm getting the feeling we're doing just this when it comes to HTTP/2.

About 80% of the posts on the list here seem to be based on the foregone 
conclusion that HTTP/2 will be over TLS only, and that therefore ALPN 
will be available.

But last time I looked we were a long way from consensus on HTTP/2 being 
over TLS only.  Or did I miss something?

So what's the plan?

Seems dangerous to do all this work based on something that is still 
highly contentious without first reaching some conclusions first about 
mandatory TLS.

And also for the record.

Most of my customers would have a big problem with the proposal that 
connections to the ("trusted") proxy should be over TLS.

For many of them the proxy is already working the hardware quite hard 
(either old hardware or high-end).  To reduce capacity by 75% or more 
just by making everything TLS would mean they would all need to go get 
new or extra hardware for their proxy.  I foresee a lot of resistance to 
this.

I don't see why the client needs to auth the proxy inside a private 
network.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Dec 2013 10:52:32 +0200

> connections to the ("trusted") proxy should be over TLS.
It's a must for a decrypting proxy that will do "GET https://";  less so for a proxy that does "CONNECT". 
> new or extra hardware for their proxy.  I foresee a lot of resistance to 
Capacity reduction depends on what the proxy is doing. Malware scanning is so onerous, that the TLS part will be lost in the noise, because handshakes will be rare. Caching or simple URL filetering is lighter, so the capacity may be reduced by as much as you say.
MitM proxies already do that much work, except that they also sign fake certificates. Their load might even decrease.
> I don't see why the client needs to auth the proxy inside a private 

Because people bring all kinds of stuff to the private network. That's a direct result of making computers smaller than this:http://www.tcf.ua.edu/Classes/Jbutler/T389/RailroadComputer1967.jpg
If someone (or some bot) fools your computer to use it as a proxy, it gets access to all your HTTP content, and all your HTTPS meta-data, even without being a decrypting proxy. That is why authentication is needed.
Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 12 Dec 2013 10:34:06 +0100

Le Jeu 12 décembre 2013 02:22, Ted Hardie a écrit :
>> of

The proxy auth may be shared with other internal systems. On any big
organisation it will be (see SSO)

Browsers not making the distinction between proxy and web site messages
mean any random web site can spoof the proxy auth and steal credentials.

Such credential stealing was used to infiltrate French presidency last
year IIRC.

So yes, let's be a little careful with terms like "trust level" and stop
assuming any random blog trumps everything else.

-- 
Nicolas Mailhot

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 Dec 2013 10:00:54 +0000

------ Original Message ------
>so for a proxy that does "CONNECT".
but when a client makes a connection to the proxy for a GET http:// 
would that also be over a TLS connection?

This is a large proportion of surfing currently.  To move this to TLS 
(even if only TLS to proxy) will be a considerable increase in load.

I agree difference between TLS to proxy + GET https:// vs MitM is not 
much (cert is cached after generation anyway).  But currently https 
traffic is only a fraction of total traffic (albeit increasing thanks to 
FB and Google).

>Capacity reduction depends on what the proxy is doing. Malware scanning 
>is so onerous, that the TLS part will be lost in the noise, because 
>handshakes will be rare. Caching or simple URL filetering is lighter, 
>so the capacity may be reduced by as much as you say.
Actually you'd be surprised about load from malware scanning as well.  
With normal content-type based whitelisting policy, only a fraction of 
content is actually scanned.

Basic testing when we put in an https reverse proxy showed an encrypted 
connection took considerably more CPU than a plaintext one.  Probably 
10x as much.  So my 75% was optimistic.

>
>MitM proxies already do that much work, except that they also sign fake 
>certificates. Their load might even decrease.
Agree for current https, but not for current http.

>Because people bring all kinds of stuff to the private network. That's 
>a direct result of making computers smaller than this:
>http://www.tcf.ua.edu/Classes/Jbutler/T389/RailroadComputer1967.jpg
>
>If someone (or some bot) fools your computer to use it as a proxy, it 
>gets access to all your HTTP content, and all your HTTPS meta-data, 
>even without being a decrypting proxy. That is why authentication is 
>needed.
We have that problem now then for http, why is noone doing anything 
about it?

I think such problems deserve a solution outside http.

Adrien

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Dec 2013 13:45:51 +0200

On 12/12/13 12:00 PM, Adrien de Croy wrote:
> From: "Yoav Nir" <[email-masked] <mailto:[email-masked]>>
>>
>> > And also for the record.
>> >

I think (and this is not an opinion about existing things - it's about 
future extensiosn) the client connects to the proxy with or without TLS. 
and then:

  * Without TLS:
      o GET http://  works
      o CONNECT  works if HTTPS inspection is disabled or voluntary,
        denied if HTTPS inspection is mandatory
      o GET https://  is denied
  * With TLS:
      o GET http://  works, although policy may cause it to be denied to
        save resources. This only gives you privacy from your
        co-workers, not the Internet, which is kind of weird.
      o CONNECT  works if HTTPS inspection is disabled or voluntary,
        denied if HTTPS inspection is mandatory
      o GET https://  works

So you might end up with two connections, one for stuff that needs 
inspection and the other for stuff that doesn't.

> traffic is only a fraction of total traffic (albeit increasing thanks 
> to FB and Google).

I think FB and Google will lead the way. Before Google moved webmail to 
HTTPS, the others made you do your mail in the clear. Now they're all 
https. When Google move youtube to https (which some Google people said 
they were planning), could the other content providers be far behind?
>> Capacity reduction depends on what the proxy is doing. Malware 
>> scanning is so onerous, that the TLS part will be lost in the noise, 
>> because handshakes will be rare. Caching or simple URL filetering is 
>> lighter, so the capacity may be reduced by as much as you say.
> Basic testing when we put in an https reverse proxy showed an 
> encrypted connection took considerably more CPU than a plaintext one.  
> Probably 10x as much.  So my 75% was optimistic.

My opinion may be skewed by the setup in my company. Since we develop 
it, all manner of scanning are enabled on our gateway (far more than a 
customer would do), and the CPU resources spent on scanning for malware 
and identifying bots dwarf those spent on encryption and decryption.

>> MitM proxies already do that much work, except that they also sign 
>> fake certificates. Their load might even decrease.
>> Because people bring all kinds of stuff to the private network. 
>> That's a direct result of making computers smaller than this:
Regardless of how you configure it, you'll need to authenticate the 
proxy, otherwise you're vulnerable to all kinds of attacks. It's one of 
those threats that you can decide are not worth the effort to fix, 
because it's rare and the cost of authentication is onerous, or 
meta-data about HTTPS is not all that interesting, but the problem is 
still there.

Yoav

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Dec 2013 15:35:21 +0000

On Dec 9, 2013, at 5:17 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Dec 8, 2013 at 6:33 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
This thread makes me wonder if, rather than focusing on introducing a new kind of proxy to address the “enterprise/school/prison” (ESP) use case, we* should instead focus on fixing how trust roots are configured and managed in browsers / OSs.

malware/virus scanning

+1

but then would be also other more related to network management aspect such us
modifying the flow control to improve performance is special network environments (i.e. cellular networks)

/Salvatore

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 12 Dec 2013 17:01:51 +0100

> cases that lead us there (rather than on that particular solution, yet).

IIRC web site and browser people have reaffirmed many times here they
didn't want intermediaries to tamper with content. Which is actually fine
as most intermediaries do not want to tamper in any way, just look at what
goes through and block what they don't like. That's where e2e integrity
comes into play (and as end-user I'd like to have it too). Besides that's
a major part of reassuring users nothing fishy is going on behind their
back

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 12 Dec 2013 16:14:32 +0000

In message <[email-masked]>, "Nicol
as Mailhot" writes:

>That's where e2e integrity comes into play (and as end-user I'd
>like to have it too). Besides that's a major part of reassuring users
>nothing fishy is going on behind their back

And as usual, once you start pulling on a single loose thread, you
find out that it's tied to all the turtles:

What good is e2e integrity, if you don't know who the other 'e' is ?

All you can know without e2e authentication is that you have some
cryptographic property (privacy/integrity/whatever...) all the way
to the node where the (first!) MITM attack is implemented.

Unless you use a Pre Shared Key, there are only three levels of security:

1. Plaintext.

2. Obfuscated to keep trival tcpdump/snort snoopers out of the loop.

3. Authenticated.

If you want more than #2, you need to fix #3, and that I belive is
waaay beyond this WG.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Dec 2013 16:25:08 +0000

> a major part of reassuring users nothing fishy is going on behind their

Nicolas,

actually my point is 
because with 2.0 most likely there will be only one connection (TLS/TCP) between the browser and the server,
in some network environment, like cellular network, it would be quite important for an
operator to play with the HTTP2.0 Flow control mechanism in order to provide to 
the user a great user experience and at same time avoiding the possibility to congest
the limited radio bandwidth capacity

that has nothing to do with tamper the content neither with sniffing content
it has to do with monitoring in support of network operator

/Salvatore

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 12 Dec 2013 17:24:44 +0100

> What good is e2e integrity, if you don't know who the other 'e' is ?

sure, but it's no better or worse than what exists in tls today, and tls
was good enough for most of the people that didn't want intermediaries to
tamper with content

-- 
Nicolas Mailhot

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Dec 2013 12:15:29 +1100

Adrien,

On 12 Dec 2013, at 7:22 pm, Adrien de Croy <[email-masked]> wrote:
> 
> About 80% of the posts on the list here seem to be based on the foregone conclusion that HTTP/2 will be over TLS only, and that therefore ALPN will be available.
> 
> But last time I looked we were a long way from consensus on HTTP/2 being over TLS only.  Or did I miss something?

This is being tracked at --
  https://github.com/http2/http2-spec/issues/314

A while back, I asked for proposals to address that issue. So far, the only proposal we've had is effectively the status quo -- i.e., not to make anything mandatory.

In particular, no one has yet proposed that TLS be mandatory for HTTP/2.  Some people have stated that their products will only support HTTP/2 when it happens over TLS, but they are not suggesting (so far) that this be written into the specification.

> So what's the plan?

My inclination at this point is to continue to document the different ways to negotiate HTTP/2 (i.e., for both http:// and https:// URLs), and see how the protocol is implemented. If we get rough consensus and have running code, we might include opportunistic encryption for http:// URIs as well (the alt-svc and http2-encryption drafts are just proposals, not yet WG documents). 

Depending on how that goes, we might talk about starting a separate Informational document to track how browsers use HTTP/2 (as opposed to various other use cases for the protocol), in an effort to encourage convergence. Such a document would ideally contain a profile of HTTP/2 that spells how how browser implementations use the protocol; less ideally, it would contain more than one. 

We also might work on other mechanisms (e.g., explicit proxy) in separate documents. 

We'll be talking about all of this as we go along, and especially at the upcoming interim meeting. Implementation (as well as deployment) experience, along with discussion, may give us more insight that makes making decisions easier than it is now.

For now, though, getting consensus on mandatory-to-use TLS seems unlikely, based on the discussion so far (never mind that it hasn't even been proposed formally). 

The wild card in all of this is draft-farrell-perpass-attack. If that document gains IETF consensus, we'll need to demonstrate that we've at least considered pervasive monitoring as a threat, and can explain why we have taken the approach we have.

Regards,