Subject: Re: Comments on Explicit/Trusted Proxy

From: Peter Lepeska <[email-masked]>
Date: Wed, 1 May 2013 21:55:24 -0400

I like the mcgrew proposal best as well. I like the way that it removes the "transitive trust" problem without having a tunnel within a tunnel and the passing of encryption keys over the air, which is the approach used in Roberto's draft as I understand it.

SPDY is increasing the adoption of SSL, which is rendering traditional caches less and less useful. At minimum it would be great to have agreement on what the protocol to support a trusted proxy would look like.

Even better would be if Chrome or another browser led the way and implemented it.

Peter

On Apr 27, 2013, at 4:09 PM, Yoav Nir <[email-masked]> wrote:

> Here's one (I'm a co-author)
> 
> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server
> 
> One reason this was rejected is that MitM proxies are used for corporate firewalls and national firewalls, so the use case seems to be "Alice wants to post to Twitter trashing president Assad. Mallory who works for the secret police would like to catch her, so he installs a proxy."  The feedback said that if whoever wants the inspection (call them Mallory for now) can configure trust on Alice's client, they might as well install spyware instead. Another idea that was floated was to have the client send the keys to the trusted proxy. That way, the client could send just the encryption key (but not the hash key) so the proxy would be able to decrypt, but not forge. I didn't like that, but I did try to write a draft describing it:
> 
> http://tools.ietf.org/html/draft-nir-tls-keyshare
> 
> I still think this solution is unwieldy.
> 
> Anyway, the TLS WG can re-consider things. NPN was suggested several times. If there is a use case that is not "Mallory wants to see what Alice is telling Bob", a request from this WG would go a long way, regardless of which mechanism is preferred for enabling a trusted proxy.
> 
> Yoav
> 
> On Apr 26, 2013, at 3:45 PM, Peter Lepeska <[email-masked]> wrote:
> 
>> Hi Stephen. 
>> 
>> I was responding to Roberto's draft, which was submitted to this list. But my suggestion crosses over into TLS changes so I'll read up on the 5 previous discussions and post to the TLS group if appropriate.
>> 
>> Thanks,
>> 
>> Peter
>> 
>> 
>> On Apr 26, 2013, at 6:43 AM, Stephen Farrell <[email-masked]> wrote:
>> 
>>> 
>>> Hi Peter,
>>> 
>>> If you want to modify TLS, then that's work that would
>>> need to be done in the TLS working group and not here.
>>> Note that this'd be about the 5th time someone has asked
>>> if we want to standardise how to do a MITM attack on TLS,
>>> which is a protocol designed specifically to deter MITM
>>> attacks, and the answer has always been an emphatic no.
>>> I cannot see that changing. As a current security AD I
>>> know I'd have a huge problem with standardising that
>>> attack as I believe would my co-AD who's responsible
>>> for the TLS WG.
>>> 
>>> If you want to propose changes to the semantics of HTTP,
>>> and supporting MITM proxies would be one such IMO, then
>>> I guess take that up with Mark. Or not, since I don't
>>> believe this WG is chartered to develop new semantics
>>> for HTTP at present.
>>> 
>>> Regard,
>>> Stephen.
>>> 
>>> On 04/25/2013 09:38 PM, Peter Lepeska wrote:
>>>> Some comments on Roberto's doc:
>>>> 
>>>> In the case where the user-agent has been configured with Chris as a
>>>> trusted-proxy, either Anne's connect-stream MUST use either a null-
>>>> cipher, or Anne MUST provide the decryption key material to Chris
>>>> immediately after tunnel establishment, and before any data traverses
>>>> the tunnel.
>>>> 
>>>> This seems like a showstopper to me. Even if we can get past the problems associated with a trusted proxy in general, I can't see getting acceptance of any approach that involves sending a session key from one machine to another. But why not just use two full SSL sessions like the typical MITM proxy (http://crypto.stanford.edu/ssl-mitm/ or http://mitmproxy.org) approach? But instead of forging certificates like they do, just give the trusted proxy its own certificate and then display both the trusted proxy certificate and the content server certificate in the browser when the user wants info about the two point-to-point SSL sessions.
>>>> 
>>>> "For the purpose of this document, it is assumed that the user locates
>>>> a piece of paper upon a wall and reads it, typing these proxy
>>>> settings into a configuration field for their user-agent.  This is
>>>> obviously not the only possible configuration mechanism, but it may,
>>>> sadly, be the most secure.  It is assumed that alternate distribution
>>>> techniques may be discussed.
>>>> "
>>>> 
>>>> While explicit proxy configuration may be the most secure, it is very difficult to manage for mobile devices especially, as others have mentioned on this list. Transparent interception is the more widely adopted approach -- not because of security but because of stability and manageability. 
>>>> 
>>>> What about "transparent" proxies that advertise themselves? Is it possible to use NPN (https://technotes.googlecode.com/git/nextprotoneg.html) to advertise the presence of an intercepting proxy for 443 traffic? Then the user can be notified that a proxy wants to be trusted for X reasons and the user would then make the opt in or opt out decision. Then, similar to SPDY, the presence of the trusted proxy in the end-to-end path could be signaled to the end user via icons in the browser.
>>>> 
>>>> MITM is used today with no user knowledge. At least in this approach, a user has the ability to opt in or out and to also be aware of the presence of the intermediate proxy.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Peter
>>>> 
>>>> 
>>>> On Apr 24, 2013, at 12:49 PM, William Chan (陈智昌) <[email-masked]> wrote:
>>>> 
>>>>> Yep, but no, it hasn't gone anywhere.
>>>>> 
>>>>> 
>>>>> On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska <[email-masked]> wrote:
>>>>> Hi William,
>>>>> 
>>>>> Is this draft by Roberto Peon the one you were referring to?
>>>>> 
>>>>> http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00
>>>>> 
>>>>> Has this gone anywhere?
>>>>> 
>>>>> I'm looking to design and build a "trusted proxy" that aligns with the browser development roadmap/vision in order to provide web acceleration functionality and so would like to get involved in this process if still active.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Peter
>>>>> 
>>>>> 
>>>>> On Mon, Apr 30, 2012 at 5:57 PM, William Chan (陈智昌) <[email-masked]> wrote:
>>>>> On the contrary, I think it's great to have multiple proposals. If you have your own vision for how this should work, please send it out! :) My statement was simply an FYI, not a "back off, we've got this!"
>>>>> 
>>>>> On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska <[email-masked]> wrote:
>>>>> Perfect then I'll sit tight.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Peter
>>>>> 
>>>>> 
>>>>> On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) <[email-masked]> wrote:
>>>>> FYI, we (google spdy team) have been discussing a "trusted proxy" internally and I think Roberto's got a draft in the works.
>>>>> 
>>>>> 
>>>>> On Mon, Apr 30, 2012 at 2:22 PM, Peter Lepeska <[email-masked]> wrote:
>>>>> Hi Mark,
>>>>> 
>>>>> Earlier this group discussed the idea of a "trusted proxy". Does that fall under the HTTP/2.0 category?
>>>>> 
>>>>> I may have some cycles for this.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Peter
>>>>> 
>>>>> 
>>>>> On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham <[email-masked]> wrote:
>>>>> Just a reminder that we're still accepting proposals for:
>>>>> 
>>>>> 1. HTTP/2.0
>>>>> 2. New HTTP authentication schemes
>>>>> 
>>>>> As per our charter <http://datatracker.ietf.org/wg/httpbis/charter/>.
>>>>> 
>>>>> So far, we've received the following proposals applicable to HTTP/2.0:
>>>>> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
>>>>> 
>>>>> But none yet for authentication schemes:
>>>>> <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals>
>>>>> 
>>>>> As communicated in Paris, the deadline for proposals is 15 June, 2012. It's fine if your proposal isn't complete, but we do need to have a  good sense of it by then, for discussion.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> --
>>>>> Mark Nottingham   http://www.mnot.net/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 
>> 
>> Email secured by Check Point
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 May 2013 10:09:26 +0100

> I like the mcgrew proposal best as well. I like the way that it removes the "transitive trust" problem without having a tunnel within a tunnel and the passing of encryption keys over the air, which…

Again, that's for the TLS wg. As Yoav notes, you can be the
N-th set of people who want to standardise a MITM. Expect
resistance;-)

> SPDY is increasing the adoption of SSL, which is rendering traditional caches less and less useful. At minimum it would be great to have agreement on what the protocol to support a trusted proxy wo…

Personally, I don't believe I've seen a coherent description
of what this kind of MITM is supposed to be, except for those
that call it a MITM. My guess (no more than that) is that you'd
probably need some new semantics for HTTP to actually support
the kind of thing people say they want.

> Even better would be if Chrome or another browser led the way and implemented it.

I disagree fwiw. I think its bad enough that there are MITM
proxy products being deployed and am happy that browsers
seem mostly to prefer to actually want to talk to the real
server that has the relevant private key. I really do prefer
that when I want to do banking that no corporate MITM gets access
to my bank account. (Mind you, I also have the protection of
an almost always near-zero bank account;-) If I needed to collude
with someone via one of these boxes, I and anyone else am
also quite capable of bypassing any outbound content analysis
that such proxies might attempt, and I have to have sufficient
security on the box with the browser to handle inbound malware
in any case (e.g. that arrives via mail) so the security argument
for these MITMs is to a large degree (though not quite 100%)
bogus IMO. Just because some people get sold a pup doesn't
mean we should turn TLS into a dog:-)

S.

---

From: Fabian Keil <[email-masked]>
Date: Thu, 2 May 2013 12:19:13 +0200

> Anyway, the TLS WG can re-consider things. NPN was suggested several times. If there is a use case that is not "Mallory wants to see what Alice is telling Bob", a request from this WG would go a lo…

Another use case is Alice operating both the client(s) and
the trusted proxy.

In this use case the trusted proxy should be able to MITM some,
but not all, requests and the client(s) should be able to verify
and signal this to Alice.

Mallory should not be able to silently MITM anything and
Alice obviously doesn't want to install spyware instead of
configuring a trust relationship, even though she could.

Having a standard for this would be useful for proxies like Privoxy.

Fabian

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 2 May 2013 10:34:40 -0400

Stephen,

I agree with you about bank sites but HTTPS is increasingly used for sites that transfer much less sensitive information. Over very high latency networks like satellite (full disclosure: my job is to optimize Viasat's Exede network) the adoption of HTTPS is hurting page load performance. The primary reason for this is that our HTTP prefetching that is built into the network cannot be applied to encrypted traffic.

For example, www.usps.com recently switched from plain HTTP to HTTPS. It's page load time went from ~5 seconds to ~30 seconds over satellite. If the protocol was changed to support the advertisement of an accelerating proxy to the content server, for instance with a flag in the ClientHello, my guess is that many content owners like www.usps.com would agree to allow the proxy to decrypt/re-encrypt for the purposes of speeding up access to that site for their users. On the other hand, a bank would likely refuse, which again the protocol could support via a flag in the ServerHello that is processed by the proxy telling it that the information is too sensitive for optimization.

In general, SPDY adds the HTTPS requirement and Prefetching to HTTP. But the HTTPS requirement limits the prefetching benefit b/c proxies that can learn which objects a given site will need are increasingly unable to see the traffic.

> N-th set of people who want to standardise a MITM. Expect

Yes. I see that TLS wg is not receptive to this. My hope is to prototype this functionality and then submit a draft update of the mcgrew approach with tweaks and working code. I'll submit it to the TLS wg unless there is interest here.

Thanks,

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 May 2013 15:47:51 +0100

> For example, www.usps.com recently switched from plain HTTP to HTTPS. It's page load time went from ~5 seconds to ~30 seconds over satellite. If the protocol was changed to support the advertisemen…

I don't know how you can do that and prevent someone from MTIM'ing
the bank. That's the problem with all this so-called "trusted" proxy
stuff.

S.

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 2 May 2013 10:53:33 -0400

It's no different than today. If you have a root CA installed on the end users machine, you can MITM the bank. Under this scheme, there will be some proxies that will elect to not MITM traffic from content providers that explicitly opt-out.

In general, adding support for an SSL proxy should not decrease the level of security from MITM attacks that we have today. It just allows well-behaving ones to A) not have to forge certificates, B) remove the problem of transitive trust, and C) make content servers aware and give them the ability to opt-out.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 May 2013 15:57:55 +0100

> It's no different than today. If you have a root CA installed on the end users machine, you can MITM the bank. Under this scheme, there will be some proxies that will elect to not MITM traffic from…

Right. All web servers have to trust all the proxies in the universe.
Seems like a show-stopper to me.

> In general, adding support for an SSL proxy should not decrease the level of security from MITM attacks that we have today. It just allows well-behaving ones to A) not have to forge certificates, B…

Standardising that would IMO seriously decrease the level of
security we have.

S.

---

From: Albert Lunde <[email-masked]>
Date: Thu, 02 May 2013 10:17:17 -0500

On 5/2/2013 9:57 AM, Stephen Farrell wrote:
>> In general, adding support for an SSL proxy should not decrease the
>> level of security from MITM attacks that we have today. It just allows
>> well-behaving ones to A) not have to forge certificates, B) remove the
>> problem of transitive trust, and C) make content servers aware and give
> them the ability to opt-out.
>

I'd say it's better to trust a known proxy than to be in the typical 
captive portal situation where the portal in effect forges certificates 
to make you think everything is wonderful.

This is being done widely enough to suggest there is a use case.

What one would like is something that restricts what the proxy can do 
and identifies the proxy in a reliable way.

The other approach that sometimes works is some kind of VPN, but that 
may be out of scope...

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 May 2013 16:26:17 +0100

> and identifies the proxy in a reliable way.

Feel free to propose something. All I've seen in this so far
are proposals to allow proxies to do whatever they want.

That's why I suspect any good solution here is really a
semantic change for HTTP.

S.

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 2 May 2013 11:32:00 -0400

Agreed. 

Today:
MITM proxy must get its CA installed in the certificate db on the end user device.
MITM forges certs -- effectively impersonating content servers.
MITM performs trust validation for end user -- transitive trust opens up the possibility that users will not be made aware that they are visiting https sites that they do not trust.
Content servers are unaware of SSL proxy.

Tomorrow:
We could instead have a new section of the certificate database for trusted proxy certs. These certs would need to be issued by trusted CAs. An SSL proxy would need to install this into the end user device so level of security is the same as today.
No forged certs -- the original content server certificate is sent to the browser as described by the mcgrew draft.
Client can decide if it trusts the content server certificate or not -- no transitive trust.
Content servers can be made aware of SSL proxy so that when cnn.com adopts SPDY it can allow optimization by SSL proxies and it will not become 4x slower over satellite.

Peter

On May 2, 2013, at 11:17 AM, Albert Lunde <[email-masked]> wrote:

> I'd say it's better to trust a known proxy than to be in the typical captive portal situation where the portal in effect forges certificates to make you think everything is wonderful.
> 
> What one would like is something that restricts what the proxy can do and identifies the proxy in a reliable way.
> 
> The other approach that sometimes works is some kind of VPN, but that may be out of scope...
> 
> --

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 2 May 2013 11:32:44 -0400

Ok thanks. I will update the mcgrew doc and send along for comments.

Peter

---

From: Benjamin Carlyle <[email-masked]>
Date: Fri, 3 May 2013 07:28:39 +1000

My biggest issue with the transition to SSL has been the reduced security
it affords to M2M uses of http. I used to be able to throw a firewall in
between two railway systems that filters messages by method and URI regex
to limit the damage one compromised system can do to the next system down
the line. These are already private networks so although the extra layer of
protection is welcome, it is not strictly necessary.
I'm still pondering the precise solution on this one. At present it seems
to be to offload the SSL to the firewall also and to install each system's
certificates on their firewalls instead of on their servers, and then do
another SSL hop to the servers using a different certificate. This seems
more or less reasonable so probably doesn't necessitate a protocol change,
but at least for the moment adds cost to the solution that wasn't
previously there. Many firewalls are capable of http filtering but not of
SSL offload.
I guess the central use case here is "I don't want to read your messages. I
don't want to store them. I don't want a human to see them, but I want to
check to ensure they comply with policy" - a difficult one.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 2 May 2013 17:13:21 -0700

responses inline.

On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <[email-masked]> wrote:

> This seems like a showstopper to me. Even if we can get past the problems
> associated with a trusted proxy in general, I can't see getting acceptance
> of any approach that involves sending a session key from one machine to
> another. But why not just use two full SSL sessions like the typical MITM
> proxy (http://crypto.stanford.edu/ssl-mitm/or http://mitmproxy.org)
> approach? But instead of forging certificates like they do, just give the
> trusted proxy its own certificate and then display both the trusted proxy
> certificate and the content server certificate in the browser when the user
> wants info about the two point-to-point SSL sessions.
>
>
Using two connections may require two separate connections at the eventual
endpoint, and it contributes to bufferbloat.
Also, the proxy may wish to influence the private channel (e.g. don't talk
to site X). With connection sharing, this is difficult/impossible otherwise
(that other connection may not only go to example.com).

> While explicit proxy configuration may be the most secure, it is very
> difficult to manage for mobile devices especially, as others have mentioned
> on this list. Transparent interception is the more widely adopted approach
> -- not because of security but because of stability and manageability.
>
>
There is no secure automatic proxy configuration unless a completely
separate trust chain is somehow created and is reliable (or at least moreso
than what we have with TLS today).
Transparent proxying causes problems in upgrading the protocol as nobody
knows where the problem lies. If this wasn't such a painful point, we'd
have been using SPDY over port 80...
I'm fundamentally opposed to transparent proxying because it makes protocol
evolution next to impossible when you can't figure out who is messing up...

> What about "transparent" proxies that advertise themselves? Is it possible
> to use NPN (https://technotes.googlecode.com/git/nextprotoneg.html) to
> advertise the presence of an intercepting proxy for 443 traffic? Then the
> user can be notified that a proxy wants to be trusted for X reasons and the
> user would then make the opt in or opt out decision. Then, similar to SPDY,
> the presence of the trusted proxy in the end-to-end path could be signaled
> to the end user via icons in the browser.
>

>
> MITM is used today with no user knowledge. At least in this approach, a
> user has the ability to opt in or out and to also be aware of the presence
> of the intermediate proxy.
>

That is the idea.
Additionally, and this is important, the server gets to decide if the MITM
is acceptable, and, in the proposed scheme the MITM doesn't get to modify
bytes. It merely gets to advise the recipient of how to deal with them,
delay them, or disconnect.

-=R

On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <[email-masked]> wrote:

> This seems like a showstopper to me. Even if we can get past the problems
> associated with a trusted proxy in general, I can't see getting acceptance
> of any approach that involves sending a session key from one machine to
> another. But why not just use two full SSL sessions like the typical MITM
> proxy (http://crypto.stanford.edu/ssl-mitm/ or http://mitmproxy.org)
> approach? But instead of forging certificates like they do, just give the
> trusted proxy its own certificate and then display both the trusted proxy
> certificate and the content server certificate in the browser when the user
> wants info about the two point-to-point SSL sessions.
>
> While explicit proxy configuration may be the most secure, it is very
> difficult to manage for mobile devices especially, as others have mentioned
> on this list. Transparent interception is the more widely adopted approach
> -- not because of security but because of stability and manageability.
>
> What about "transparent" proxies that advertise themselves? Is it possible
> to use NPN (https://technotes.googlecode.com/git/nextprotoneg.html) to
> advertise the presence of an intercepting proxy for 443 traffic? Then the
> user can be notified that a proxy wants to be trusted for X reasons and the
> user would then make the opt in or opt out decision. Then, similar to SPDY,
> the presence of the trusted proxy in the end-to-end path could be signaled
> to the end user via icons in the browser.
>
> MITM is used today with no user knowledge. At least in this approach, a
> user has the ability to opt in or out and to also be aware of the presence
> of the intermediate proxy.
>
> Thoughts?
>
> Peter
>
>
> On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska <[email-masked]>wrote:
>
>> Hi William,
>>
>> I'm looking to design and build a "trusted proxy" that aligns with the
>> browser development roadmap/vision in order to provide web acceleration
>> functionality and so would like to get involved in this process if still
>> active.
>>
>> Thanks,
>>
>> Peter
>>
>>
>>> On the contrary, I think it's great to have multiple proposals. If you
>>> have your own vision for how this should work, please send it out! :) My
>>> statement was simply an FYI, not a "back off, we've got this!"
>>>
>>> On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska <[email-masked]>wrote:
>>>
>>>>> FYI, we (google spdy team) have been discussing a "trusted proxy"
>>>>> internally and I think Roberto's got a draft in the works.
>>>>>
>>>>>
>>>>> On Mon, Apr 30, 2012 at 2:22 PM, Peter Lepeska <[email-masked]>wrote:
>>>>>
>>>>>> Hi Mark,
>>>>>>
>>>>>> On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham <[email-masked]>wrote:
>>>>>>
>>>>>>> As per our charter <http://datatracker.ietf.org/wg/httpbis/charter/
>>>>>>> >.
>>>>>>>
>>>>>>> As communicated in Paris, the deadline for proposals is 15 June,
>>>>>>> 2012. It's fine if your proposal isn't complete, but we do need to have a
>>>>>>>  good sense of it by then, for discussion.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> --

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 03 May 2013 00:48:07 +0000

proxies need to be able to modify the bytes or at least inject messages 
back to the client.

e.g.

* request denied by policy (e.g. you can't POST to that site due to DLP 
rules)
* serving from cache
* ad stripping
* malware blocking
* etc etc etc

let alone stripping hop-by-hop headers etc

So I don't think anyone will bother with a scheme that doesn't allow for 
that.  If the only option of the intermediary is to delay or drop the 
connection, the client is going to be in the dark as to why.  Already 
the user experience in this area is poor.

As for intercepting proxies.  Whilst I agree they are a PITN, they are 
strongly favoured by customers for several obvious reasons.

Until we can get a wide-spread mechanism deployed to securely FORCE 
clients to use a proxy, we're going to see interception.

As for MITM.  Whilst we continue to think of it as an attack, we will 
continue to see resistance.  It's clear some people see it only 
negatively, where others see this as an opportunity to improve things 
compared to current MITMs.

Personally I would rather know what is going on, than be in the dark and 
be forced to swallow whatever I receive simply because I was forced (by 
company policy) to install a root cert for the spoofed certs.  Sites 
using EV certs will show me what is going on if I know a site uses EV 
certs, since the EV breaks on spoofed certs.  Or I need to check the 
cert path on any site to see if I can find the forced cert at the root.  
But that's me, not everyday punters.

As for the server trusting the proxy.  Why is that any different to the 
server trusting the client.  Use a client cert.  Can always fall back to 
a tunnel if the server indicates it needs a client cert.  Currently 
there's no way around this issue in today's MITM systems except for 
installing the client cert on the proxy.

Adrien

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Peter Lepeska" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 3/05/2013 12:13:21 p.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>>This seems like a showstopper to me. Even if we can get past the 
>>problems associated with a trusted proxy in general, I can't see 
>>getting acceptance of any approach that involves sending a session key 
>>from one machine to another. But why not just use two full SSL 
>>sessions like the typical MITM proxy 
>>(http://crypto.stanford.edu/ssl-mitm/or http://mitmproxy.org/) 
>>approach? But instead of forging certificates like they do, just give 
>>the trusted proxy its own certificate and then display both the 
>>trusted proxy certificate and the content server certificate in the 
>>browser when the user wants info about the two point-to-point SSL 
>>sessions.
>>
>
>Using two connections may require two separate connections at the 
>eventual endpoint, and it contributes to bufferbloat.
>Also, the proxy may wish to influence the private channel (e.g. don't 
>talk to site X). With connection sharing, this is difficult/impossible 
>otherwise (that other connection may not only go to example.com).
>
>>a piece of paper upon a wall and reads it, typing these proxy settings 
>>into a configuration field for their user-agent. This is obviously not 
>>the only possible configuration mechanism, but it may, sadly, be the 
>>most secure. It is assumed that alternate distribution techniques may 
>>be discussed.
>>"
>>
>>difficult to manage for mobile devices especially, as others have 
>>mentioned on this list. Transparent interception is the more widely 
>>adopted approach -- not because of security but because of stability 
>>and manageability.
>>
>
>separate trust chain is somehow created and is reliable (or at least 
>moreso than what we have with TLS today).
>Transparent proxying causes problems in upgrading the protocol as 
>nobody knows where the problem lies. If this wasn't such a painful 
>point, we'd have been using SPDY over port 80...
>I'm fundamentally opposed to transparent proxying because it makes 
>protocol evolution next to impossible when you can't figure out who is 
>messing up...
>
>
>>What about "transparent" proxies that advertise themselves? Is it 
>>possible to use NPN 
>>(https://technotes.googlecode.com/git/nextprotoneg.html) to advertise 
>>the presence of an intercepting proxy for 443 traffic? Then the user 
>>can be notified that a proxy wants to be trusted for X reasons and the 
>>user would then make the opt in or opt out decision. Then, similar to 
>>SPDY, the presence of the trusted proxy in the end-to-end path could 
>>be signaled to the end user via icons in the browser.
>
>
>
>>
>>MITM is used today with no user knowledge. At least in this approach, 
>>a user has the ability to opt in or out and to also be aware of the 
>>presence of the intermediate proxy.
>
>That is the idea.
>Additionally, and this is important, the server gets to decide if the 
>MITM is acceptable, and, in the proposed scheme the MITM doesn't get to 
>modify bytes. It merely gets to advise the recipient of how to deal 
>with them, delay them, or disconnect.
>
>-=R
>
>
>>This seems like a showstopper to me. Even if we can get past the 
>>problems associated with a trusted proxy in general, I can't see 
>>getting acceptance of any approach that involves sending a session key 
>>from one machine to another. But why not just use two full SSL 
>>sessions like the typical MITM proxy 
>>(http://crypto.stanford.edu/ssl-mitm/ or http://mitmproxy.org) 
>>approach? But instead of forging certificates like they do, just give 
>>the trusted proxy its own certificate and then display both the 
>>trusted proxy certificate and the content server certificate in the 
>>browser when the user wants info about the two point-to-point SSL 
>>sessions.
>>
>>a piece of paper upon a wall and reads it, typing these proxy settings 
>>into a configuration field for their user-agent. This is obviously not 
>>the only possible configuration mechanism, but it may, sadly, be the 
>>most secure. It is assumed that alternate distribution techniques may 
>>be discussed.
>>"
>>
>>difficult to manage for mobile devices especially, as others have 
>>mentioned on this list. Transparent interception is the more widely 
>>adopted approach -- not because of security but because of stability 
>>and manageability.
>>
>>What about "transparent" proxies that advertise themselves? Is it 
>>possible to use NPN 
>>(https://technotes.googlecode.com/git/nextprotoneg.html) to advertise 
>>the presence of an intercepting proxy for 443 traffic? Then the user 
>>can be notified that a proxy wants to be trusted for X reasons and the 
>>user would then make the opt in or opt out decision. Then, similar to 
>>SPDY, the presence of the trusted proxy in the end-to-end path could 
>>be signaled to the end user via icons in the browser.
>>
>>MITM is used today with no user knowledge. At least in this approach, 
>>a user has the ability to opt in or out and to also be aware of the 
>>presence of the intermediate proxy.
>>
>>Thoughts?
>>
>>Peter
>>
>>
>>>>I'm looking to design and build a "trusted proxy" that aligns with 
>>>>the browser development roadmap/vision in order to provide web 
>>>>acceleration functionality and so would like to get involved in this 
>>>>process if still active.
>>>>
>>>>Thanks,
>>>>
>>>>Peter
>>>>
>>>>
>>>>>On the contrary, I think it's great to have multiple proposals. If 
>>>>>you have your own vision for how this should work, please send it 
>>>>>out! :) My statement was simply an FYI, not a "back off, we've got 
>>>>>this!"
>>>>>
>>>>>>>>>As per our charter 
>>>>>>>>><http://datatracker.ietf.org/wg/httpbis/charter/>.
>>>>>>>>>
>>>>>>>>>As communicated in Paris, the deadline for proposals is 15 
>>>>>>>>>June, 2012. It's fine if your proposal isn't complete, but we 
>>>>>>>>>do need to have a  good sense of it by then, for discussion.
>>>>>>>>>
>>>>>>>>>Regards,
>>>>>>>>>
>>>>>>>>>--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 2 May 2013 17:53:31 -0700

The scheme allows for injection of bytes, but not within any of the secure
tunnels. Instead, the proxy's bytes are clearly demarqued as different.

The idea here is that the client or server should always know when the
proxy has changed bytes, and it shouldn't, though it may inject
bytes/requests/whatever in either direction.

Sure, a client cert is one way of authenticating to the server. I didn't go
into that much detail, but rather pointed out that the scheme proposed in
that doc, that servers may decide they don't want to service queries from
(some) proxies, and direct the client to either try directly, or allow the
request to fail.

-=R

On Thu, May 2, 2013 at 5:48 PM, Adrien W. de Croy <[email-masked]> wrote:

> connection, the client is going to be in the dark as to why.  Already the
> user experience in this area is poor.
>
> continue to see resistance.  It's clear some people see it only negatively,
> where others see this as an opportunity to improve things compared to
> current MITMs.
>
> company policy) to install a root cert for the spoofed certs.  Sites using
> EV certs will show me what is going on if I know a site uses EV certs,
> since the EV breaks on spoofed certs.  Or I need to check the cert path on
> any site to see if I can find the forced cert at the root.  But that's me,
> not everyday punters.
>
> server trusting the client.  Use a client cert.  Can always fall back to a
> tunnel if the server indicates it needs a client cert.  Currently there's
> no way around this issue in today's MITM systems except for installing the
> client cert on the proxy.
>
> Adrien
>
>
>> proxy (http://crypto.stanford.edu/ssl-mitm/or http://mitmproxy.org/)
>> possible to use NPN (
>> https://technotes.googlecode.com/git/nextprotoneg.html) to advertise the
>> presence of an intercepting proxy for 443 traffic? Then the user can be
>> notified that a proxy wants to be trusted for X reasons and the user would
>> then make the opt in or opt out decision. Then, similar to SPDY, the
>> presence of the trusted proxy in the end-to-end path could be signaled to
>> the end user via icons in the browser.
>>
>
>
>
>
>>
> On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <[email-masked]>wrote:
>
>> possible to use NPN (
>> https://technotes.googlecode.com/git/nextprotoneg.html) to advertise the
>> presence of an intercepting proxy for 443 traffic? Then the user can be
>> notified that a proxy wants to be trusted for X reasons and the user would
>> then make the opt in or opt out decision. Then, similar to SPDY, the
>> presence of the trusted proxy in the end-to-end path could be signaled to
>> the end user via icons in the browser.
>>
>>>>>>>>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals
>>>>>>>> >
>>>>>>>>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 May 2013 09:16:33 +0100

The contrast between this arm-waving nonsense and the precision
with which this wg are tackling HTTP/2.0 performance is frankly
astounding.

Every web site in the world (and all the non-HTTP uses of TLS)
are supposed to be able to authenticate every proxy in the world
and know when its ok for a particular set of proxies to MITM an
TLS session? That's just BS.

Note, I'm not specifically directing this at Roberto - I mean
the entire discussion rests on BS notions like the above.

S.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 03 May 2013 11:16:28 +0000

As far as a server is concerned, why would a client be any more 
trustable than a proxy?

Adrien

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "HTTP Working Group" <[email-masked]>
Sent: 3/05/2013 8:16:33 p.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>>>negatively,
>>>using
>>>   On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska 
>>><[email-masked]>
>>>   wrote:
>>>
>>>>problems
>>>eventual
>>>>mentioned
>>>nobody
>>>>problems
>>>>mentioned
>>>>   On Apr 24, 2013, at 12:49 PM, William Chan (陈智昌) 
>>>><[email-masked]>
>>>>  wrote:
>>>>
>>>>>the
>>>>>>>>>  Earlier this group discussed the idea of a "trusted proxy". 
>>>>>>>>>Does
>>>>>>>>>  that fall under the HTTP/2.0 category?
>>>>>>>>>
>>>>>>>>>><http://datatracker.ietf.org/wg/httpbis/charter/
>>>>>>>>>>>  .
>>>>>>>>>>
>>>>>>>>>>June,

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 09:16:32 -0700

and by hand-wavy I mean intentionally vague.
-=R

On Fri, May 3, 2013 at 9:15 AM, Roberto Peon <[email-masked]> wrote:

> responses inline
>
>
> On Fri, May 3, 2013 at 1:16 AM, Stephen Farrell <[email-masked]
> > wrote:
>
>>
> One puts effort towards defining something precisely when it is believed
> that it is useful to do so. At the moment we're arguing about concepts and
> seeing if there is/was interest.
>
> Precision for precision's sake seems like it would be a waste of time
> better spent adding clarifications, collecting data, etc. for HTTP/2 given
> that this would ultimately be decided by a different working group.
>
>
> Why would this be hard? You potentially have a whitelist of proxies that
> you do trust, and you tell everyone else to go away. Or you simply tell
> everyone to go away for whatever URLs you believe are too sensitive to
> allow through a proxy (I'd say that should be my login credentials and
> similar data). In the end the policy may have little to do with
> authenticating proxies and more about the URLs being served. It IS possible
> for a site to decide to authenticate proxies, however, and thus
> discriminate if it so chooses (i.e. if the benefit in doing so is high
> enough), which is why someone brought it up. Since I didn't really think
> authenticating proxies was important, it isn't in the I-D.
>
>
> The basic idea here was that if I'm a bank or similar, I'm happy to have a
> proxy which allows people in places with high RTTs to use a content caching
> proxy for non-sensitive data-- better user experience, more happy users.
>
> I'd not be happy, however, allowing this entity to change the bits on the
> wire of things flowing to the client, even if I was happy allowing them to
> be cached, as this could possibly cause a security breach of their data.
> I'd not be happy allowing that proxy to see my client's sensitive financial
> data (or I may not be allowed by law to let them see it).
>
> As a content provider I may be perfectly fine with having the javascript
> for my page cached, but I really don't want it modified, else instead of
> simply allowing DENY/REJECT/DELAY policies, I've instead allowed an easy
> vector for the proxy to take control of every session which passes through
> it.
>
> The intent was to provide a middle ground whereby both the client and the
> server get to decide what powers to grant the proxy.
>
>>
> I have a propensity to speak less than I should, which occasionally causes
> confusion. Hopefully the above has clarified the intent, but if not, please
> continue to ask questions.
>
> There is one part where I was hand-wavy in the I-D, calling out for
> discussion to be had, which was around the mechanism by which we configure
> the proxies. I still believe that to be the biggest and thorniest issue
> (and one which isn't merely technical). If that can't be solved, then any
> scheme doing MITM for point-to-point private stuff will fail, and all the
> rest of the stuff here and in the draft are for naught.
>
> -=R
>
>
>>
>> S.
>>
>> talk
>> a
>> MITM
>> >> On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska <[email-masked]
>> >wrote:
>> >>
>> a
>> >>>  On Apr 24, 2013, at 12:49 PM, William Chan (陈智昌) <
>> [email-masked]>
>> >>> wrote:
>> >>>
>> >>> On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska <[email-masked]
>> >wrote:
>> >>>
>> >>>> Hi William,
>> >>>>
>> you
>> >>>>>>>> On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham <[email-masked]
>> >wrote:
>> >>>>>>>>
>> >>>>>>>>> As per our charter <
>> http://datatracker.ietf.org/wg/httpbis/charter/
>> >>>>>>>>>> .
>> >>>>>>>>>
>> >>>>>>>>>  <
>> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
>> >>>>>>>>>
>> >>>>>>>>>  <
>> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals
>> >>>>>>>>>>
>> >>>>>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 09:23:10 -0700

A proxy can represent the interests of a 3rd party which has nothing to do
with the client or server. The motivations of this 3rd party may not be
known, and are often enough antithetical to the wishes of the client or
server.

The motivation of the client is more likely known-- they simply want the
content the server is providing, without allowing it to be modified in ways
which make for a poor experience (not just that page load, but overall,
including things like not having their bank account mysteriously go to
zero).

-=R

On Fri, May 3, 2013 at 4:16 AM, Adrien W. de Croy <[email-masked]> wrote:

>
> As far as a server is concerned, why would a client be any more trustable
> than a proxy?
>
>
>
> Adrien
>
>>>>>  proxy (http://crypto.stanford.edu/**ssl-mitm/or<http://crypto.stanford.edu/ssl-mitm/or>
>>>>> http://mitmproxy.org/)
>>>>>  https://technotes.googlecode.**com/git/nextprotoneg.html<https://technotes.googlecode.com/git/nextprotoneg.html>)
>>>>> to advertise the
>>>>>  proxy (http://crypto.stanford.edu/**ssl-mitm/<http://crypto.stanford.edu/ssl-mitm/>or
>>>>> http://mitmproxy.org)
>>>>>  https://technotes.googlecode.**com/git/nextprotoneg.html<https://technotes.googlecode.com/git/nextprotoneg.html>)
>>>>> to advertise the
>>>>>>  http://tools.ietf.org/html/**draft-rpeon-httpbis-exproxy-00<http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00>
>>>>>>
>>>>>>  Has this gone anywhere?
>>>>>>
>>>>>>>>>>>  As per our charter <http://datatracker.ietf.org/**
>>>>>>>>>>> wg/httpbis/charter/<http://datatracker.ietf.org/wg/httpbis/charter/>
>>>>>>>>>>>
>>>>>>>>>>>>  .
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   <http://trac.tools.ietf.org/**wg/httpbis/trac/wiki/**
>>>>>>>>>>> Http2Proposals<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>   <http://trac.tools.ietf.org/**wg/httpbis/trac/wiki/**
>>>>>>>>>>> HttpAuthProposals<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 09:15:51 -0700

responses inline

-=R

> >>>>> On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska <[email-masked]
> >wrote:
> >>>>>
> >>>>>>>>>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals
> >
> >>>>>>>>>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 03 May 2013 20:27:06 +0000

my next question, is how can the server tell the difference between a 
proxy and a client?

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Stephen Farrell" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 4/05/2013 4:23:10 a.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>
>A proxy can represent the interests of a 3rd party which has nothing to 
>do with the client or server. The motivations of this 3rd party may not 
>be known, and are often enough antithetical to the wishes of the client 
>or server.
>
>The motivation of the client is more likely known-- they simply want 
>the content the server is providing, without allowing it to be modified 
>in ways which make for a poor experience (not just that page load, but 
>overall, including things like not having their bank account 
>mysteriously go to zero).
>
>-=R
>
>
>>>>>>  proxy 
>>>>>>(http://crypto.stanford.edu/ssl-mitm/orhttp://mitmproxy.org/)
>>>>><[email-masked]>wrote:
>>>>>
>>>>>>>>>>>>  So far, we've received the following proposals applicable 
>>>>>>>>>>>>to
>>>>>>>>>>>>  HTTP/2.0:
>>>>>>>>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 14:07:44 -0700

The client has no need to do TLS in TLS and wouldn't do it by default.
The proxy has no choice but to do TLS in TLS (since that is what the client
sends it), and, since it doesn't have the integrity keys, it can't change
the data, etc. without detection by the client or server.

So, if the server receives a stream which indicates that it is doing TLS,
it knows this should be treated as having come through a proxy.

-=R

On Fri, May 3, 2013 at 1:27 PM, Adrien W. de Croy <[email-masked]> wrote:

> Cc: "Stephen Farrell" <[email-masked]>; "HTTP Working Group" <
> [email-masked]>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 03 May 2013 22:52:34 +0000

sorry I should have been more clear, my questions weren't in the context 
of your proposal, but in the context of what the current situation is, 
and mostly in response to Stephen's comments.

Concerns were raised about creating a requirement for servers to 
authenticate proxies.

My questions were about how does a server know it's a proxy, so how can 
a client be trusted more, and therefore how is a proxy less trustworthy.

HTTP auth only covers one small part of the picture, and doesn't lock a 
proxy out of the conversation, only out of the authentication.  The 
proxy can still modify anything else about the requests.

Regards

Adrien

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Stephen Farrell" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 4/05/2013 9:07:44 a.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>The proxy has no choice but to do TLS in TLS (since that is what the 
>client sends it), and, since it doesn't have the integrity keys, it 
>can't change the data, etc. without detection by the client or server.
>
>So, if the server receives a stream which indicates that it is doing 
>TLS, it knows this should be treated as having come through a proxy.
>
>-=R
>
>
>>Cc: "Stephen Farrell" <[email-masked]>; "HTTP Working 
>>Group" <[email-masked]>
>>>A proxy can represent the interests of a 3rd party which has nothing 
>>>to do with the client or server. The motivations of this 3rd party 
>>>may not be known, and are often enough antithetical to the wishes of 
>>>the client or server.
>>>
>>>the content the server is providing, without allowing it to be 
>>>modified in ways which make for a poor experience (not just that page 
>>>load, but overall, including things like not having their bank 
>>>account mysteriously go to zero).
>>>
>>>-=R
>>>
>>>
>>>>>>>>>>>>>  Earlier this group discussed the idea of a "trusted 
>>>>>>>>>>>>>proxy". Does

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 May 2013 11:29:43 +0100

> Concerns were raised about creating a requirement for servers to

Not quite. If one did accept the mainly-bogus arguments for
MITMing TLS (and I clearly don't:-), and you want any level
of security at all, you need a secure N-party protocol instead
of TLS or to change HTTP significantly and use multiple but
linked TLS sessions. I don't know of any real solution for
these mainly-bogus requirements that does not involve web
servers being able to authenticate every possible proxy in
either case. Being able to do that is just not practical IMO.

The problem with claims that you don't need the ability
for any web server to authenticate any proxy is that that
would allow any middle-box to join any TLS session which
would mean that TLS confidentiality would be a thing of the
past. That'd be a hugely bad outcome.

Requiring that web-sites can and will go through all the
URLs they serve and decide which are ok to MITM and which
are not also seems bogus to me. That'd either result in
failure to establish many many TLS sessions because we'd
have invented a bogus-standard that more or less forced
proxies and web servers to choose non-interoperable options
or else would mean that many many TLS sessions were MITMable
through web-server admin inaction. Again both are hugely
bad outcomes.

Oh, and I've left out the fact that there are many non-web
uses for TLS any of which could be screwed if we standardised
a way to MITM TLS designed to satisfy mainly-bogus HTTP proxy
driven requirements. I don't see any of the proponents of these
mainly-bogus requirements doing the security analysis of the
impact their mainly-bogus solutions would have on those other
protocols. Hey - there's likely another hugely bad outcome
or 10.

The answer about what to do here is obvious to anyone who
cares about security and BCP61 says the IETF does. What to
do here is: don't break TLS.

>From any rational web server perspective, no forward proxy is
"trustworthy" (terrible term to use btw, it means nothing as
used above).

If a web server cares, it can add an account for the user
(not UA) and the UA is (sort of) under the control of that
user according to our host-based security models. Proxies
are just unknowns.

Stephen.

PS: Yes, the above uses pejorative language. Apologies for
that, but yes, it is deliberate;-)

>>>> modified in ways which make for a poor experience (not just that
>>>> page load, but overall, including things like not having their bank
>>>>>>>>>>>>>>>  So far, we've received the following proposals
>>>>>>>>>>>>>>> applicable to
>>>>>>>>>>>>>>>  HTTP/2.0:
>>>>>>>>>>>>>>>

---

From: Roberto Peon <[email-masked]>
Date: Sat, 4 May 2013 08:30:10 -0700

Ugh. The last part of the email means that you are being deliberately
insulting. This is, in the long-run, rarely effective.

responses inline.

> either case. Being able to do that is just not practical IMO.

You can state this without being pejorative, in which case I might agree.

There are two suppositions in the draft:
1) MITM may be unavoidable in the long-term, in which case the lesser of
evils is to have a MITM which is detectable and which is prevented from
modifying or falsifying information.

2) It may be interesting to have a connection to a proxy which is
point-to-point private, and which allows the proxy to perform caching
duties as it might with HTTP, but with guarantees that the content it
serves is unmodified.

I'm assuming you conflate the motivation for #1 with the rest of everything
and have an adverse ideological reaction.
I don't particularly like it either, but that (that
coporations/organizations/gov't entities, etc. will be forcing
unconstrained MITM by various means) was the supposition. If it is in
general false, *good*. If it is true, then choose some lesser of evils, and
discuss it. A discussion about whether such a mechanism would hasten the
creation of such a world is also interesting and valid. Being a pragmatist,
I see that ideology is useful until it isn't. I also know that there are
companies and organizations which *DO* do SSL MITM by installing and
configuring root certs, etc. and there is currently no protection guarantee
to users traversing such.

> past. That'd be a hugely bad outcome.

You are either misinterpreting or falsifying here.

The mechanism specified in the draft requires at least three TLS sessions
which interplay, and possibly 4.

1) client<-> proxy   for point-to-point privacy
2) proxy <-> server for point-to-point privacy
3) client (tunneled through the proxy) <-> server for end-to-end privacy
and authentication
4) client (tunneled through the proxy, null-cipher or similar used,
integrity key NOT exposed) <-> server for end-to-end integrity while
allowing the proxy to examine/delay/drop and provide policy to the client
or server outside of the tunnel

In other words, the only way to don't also have a full TLS session (which
simply happens to be tunneled) with full authentication and encryption is
when you explicitly give this up by configuring it manually (like what one
does today).

In other words it is always the client's choice to do #4, and doing so does
require an explicit configuration by said client.
It is also stated that this trust relationship is likely problematic in the
public case, which is why I didn't provide for any mechanism for
automatically configuring such, and I called out that that part is
potentially problematic and needs further consideration.

None of the trust things are problematic in the caching case-- automatic
configuration would be fine there, but I didn't go into it because I didn't
want that part conflated with the much more worrisome aspects. It is fine
because if something is cached (at an intermediary) it is public
information, and all we care about in that case is that the integrity of
the item is intact.
The draft's scheme for caching does provide a potential privacy benefit
there as well, however-- since one may now speak with a caching proxy over
a channel which is point-to-point private, it is more difficult to see what
(public) resources the client is requesting.

> through web-server admin inaction. Again both are hugely
Do you write or maintain servers that serve commercial traffic?
It doesn't sound that way.

In any case, as a larger problem, you're arguing from both ends and somehow
not meeting in the middle.

You're seem to be asserting that MITM proxies are bad and won't happen
(i.e. you dispute the premise behind #1), but then you're also asserting
that when they do happen, that servers should completely ignore it and
happily serve content through servers which are unauthenticated to the
user, unknown to the user, and unknown to the server.

So, which is it?
Do you believe that MITM is not happening and never will?
Or do you believe that MITM will happen, and if so that clients and servers
should be blind to it, and should accept mutated data without comment or
reaction?

> protocols. Hey - there's likely another hugely bad outcome

The draft was submitted to the HTTP working group to help with HTTP's
particular requirement set, and as a response to the fact that, while
encrypting point-to-point communications allows for protocol evolution, it
makes caching difficult, and also as a real-world result of dealing with
schools and other entities which have legal or perceived moral reasons for
enforcing policies on communications.

In other words, problems faced because I do have to serve clients.

The scheme specified in the draft requires no change to TLS's mechanisms,
though the considered and informed input of security experts on the content
of the draft is hopefully useful.

> "trustworthy" (terrible term to use btw, it means nothing as

That is precisely the point!

Some resources are too sensitive to allow through any non client-controlled
proxy. Only the server has any reasonable potential of knowing which these
are, and it *should not* trust the proxy in such cases.

> user according to our host-based security models. Proxies

How would this work w.r.t proxies?

 -=R

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 May 2013 19:34:57 +0100

> insulting. This is, in the long-run, rarely effective.

No, I'm not insulting anyone nor trying to. I am describing
the purported requirements here as mainly-bogus which is
pejorative but entirely different and is IMO justified. I
think emphasis on the bogosity of the purported requirements
is deserved.

I won't respond blow by blow because I think we're talking
at cross purposes as I wasn't commenting specifically about
your draft but about the entire set of proposals for MITMing
TLS. But to address your points:

- My approach is not ideological at all, but based solely
on good engineering and security practices.

- Possible government mandated MITM attacks on IETF protocols
were a major factor in why we ended up with RFC2804. I suggest
that's required reading for people proposing work on this
topic.

- We are not talking about privacy at all here but about
confidentiality. Confusing those, in this context, is a
bad idea.

- Yes, I do believe that MITM is happening in enterprises,
that we should not standardise it because of the bad
outcomes I mentioned in my mail and that we should try
use whatever mechanisms we can to make it detectable
(e.g. pinning or certificate transparency). The reason
for all that is not ideological but because it is an
attack on the protocol.

I also think we can leave the discussion at this point,
given that there is no WG chartered for this. At least
I'm happy to leave it there.

S.

---

From: Roberto Peon <[email-masked]>
Date: Sat, 4 May 2013 14:00:37 -0700

Agreed, agreed, ditto :)
-=R
On May 4, 2013 11:35 AM, "Stephen Farrell" <[email-masked]>

---

From: Werner Baumann <[email-masked]>
Date: Sun, 5 May 2013 10:39:33 +0200

Am Sat, 04 May 2013 19:34:57 +0100
schrieb Stephen Farrell <[email-masked]>:

> ...

Definition of Wiretapping from RFC2804:

   Wiretapping is what occurs when information passed across the
   Internet from one party to one or more other parties is delivered to
   a third party:

   1. Without the sending party knowing about the third party

   2. Without any of the recipient parties knowing about the delivery to
      the third party

   3. When the normal expectation of the sender is that the transmitted
      information will only be seen by the recipient parties or parties
      obliged to keep the information in confidence

   4. When the third party acts deliberately to target the transmission
      of the first party, either because he is of interest, or because
      the second party's reception is of interest.

An explicit trusted proxy does not meet this definition of wiretapping
because of condition 1. Whether information is delivered to a third
party at all depends on the administration of that proxy. End users will
have to decide whether to trust it or not (which is much more easy done
than to decide whether to trust some CA or not).

All participants in this discussion that argued in favor of explicit
trusted proxies did it to stop a situation where this is done without
the end user knowing of the interception. The whole point of these
proposals is to make the user aware of the proxy and to allow the user
to either agree or deny.

Start of not trying to insult section:
Repeating the mantra "Don't open TLS to MITM attacks" is bogus in face
of the well known fact that TLS is susceptible to MITM attacks
(mostly due to not trustworthy CAs) and that this weakness is already
widely exploited.

Werner

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 05 May 2013 10:07:15 +0100

Briefly, this thread's going on too long...

Corporate MITM'ing may well not amount to wiretap ala
2804. Standardising MTIM'ing does however make 2804
relevant IMO because the standard MITM attack would
be used in that way. The original clipper proposals
had the LEAF field that the client was supposed to (have
to) send, so the fact that something has to happen on
the client doesn't by itself mean the client is aware
of what's going on.

And yes MITM does happen and one could debate where
blame for that ought lie if one wanted (I don't.) The
point is that standardising that makes the Internet
worse, for all approaches I've seen proposed. We're
not in the business of denying reality but nor are we
in the business of rubberstamping all misbehaviours.

S.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 May 2013 12:04:26 +0000

Hi, Werner

Feels weird for me to be arguing for the other side, but…

> than to decide whether to trust some CA or not).

Corporate proxies are installed by the same IT departments that install the corporate laptops. So why bother the user with pesky warning screens and with installing CA certificates / trusted proxy certificates?  The corporate laptops come pre-installed with the MitM CA. This will not change if some trusted proxy technology is adopted - the user will still "trust" the proxy without their knowledge. 

Ethical IT departments inform their users that this is going on. Certainly in some countries informing the users about this is mandatory. I believe that a trusted proxy scheme is better than the status quo, because browsers *could* display some warning/icon/color in the address bar whenever a proxy is present. However, there is nothing to guarantee that all browser vendors will display such an indication, nor that users would notice if they did.

> proposals is to make the user aware of the proxy and to allow the user

If you bring your own device, the proxy is visible right now. If you use your employer's device, they are in full control of whether you are or aren't aware.

Yoav

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 06 May 2013 10:37:59 +0000

Hi

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "Werner Baumann" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Sent: 6/05/2013 12:04:26 a.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>Corporate proxies are installed by the same IT departments that install 
>the corporate laptops. So why bother the user with pesky warning 
>screens and with installing CA certificates / trusted proxy 
>certificates?
Current MiTM schemes require a certificate to be trusted by the client 
in order to avoid incessant cert warnings.

Deployment of this cert is more or less of a headache depending on the 
network environment and client OS.  For instance in a Windows AD, they 
can be pushed out to domain members by Group Policy.

However, enforcement of interception for computers/devices not directly 
under the administative control of the organisation/IT department (e.g. 
phones, or visitors' devices) remains a problem.

In the end, whether the reasons for wanting to intercept an inspect 
https traffic are bogus or not according to us is moot.  Customers will 
go where they are served.  Any proxy (forward) vendor who does not 
currently support https inspection, or doesn't have a plan for it, has 
IMO numbered days.

If all the proxy vendors banded together and refused to provide https 
inspection it wouldn't be a problem. But that's not the case, and to not 
offer it is increasingly (yes the problem is growing) IMO a serious 
competitive disadvantage.  Customers simply don't care.  They want to:

* enforce DLP policy
* scan for malware / malsites at the perimeter
* cache
* content filter

When it was only banks using SSL it wasn't a problem - customers didn't 
really care about not being able to scan bank traffic.  Facebook made it 
a problem for everyone.  The more big sites move to SSL the worse it 
gets.

I hear arguments that standardising MiTM will open the door for illicit 
and clandestine eavesdropping or worse.  However, how do the external 
parties get you to install the trusted root cert?  Or does this claim 
rely on users ignoring cert warnings?  How is this any worse than the 
current situation?

Being able to advertise your presence (as an https-inspecting proxy) is 
surely better than the current scenario.  What would be better still is 
a way for an organisation to enforce use of a proxy, esp for visiting 
devices.  To be able to intercept, and divert to something that can

a) spell out the company policy for use of its internet resources
b) provide a painless way for the browser or other agent to be 
configured to use the proxy (if desired by the user) in accordance with 
the policy.

Currently it's not even possible to display a page instead of the 
requested (https) destination in the case where the client is not 
configured to use a proxy, and doesn't have the proxy spoofing cert 
installed.  Not at least without a browser cert warning.  You get 2 
choices:

1. browser cert warning when you
- intercept the connection
- look at requested server, or connect to destination and obtain actual 
cert
- spoof the cert
- TLS handshake with the client using that cert -> cert warning
- send the page

2. Disconnect the client if it goes somewhere it's not authorized to.  
This leads to in general lousy user experience and support calls.

So, we don't want to do anything about this?  The problem isn't going 
away, and more MiTM implementations are being deployed.  It's the user 
that suffers in the end if we don't act to improve things for them.

Cheers

Adrien

>The corporate laptops come pre-installed with the MitM CA. This will 
>not change if some trusted proxy technology is adopted - the user will 
>still "trust" the proxy without their knowledge.
>
>Ethical IT departments inform their users that this is going on. 
>Certainly in some countries informing the users about this is 
>mandatory. I believe that a trusted proxy scheme is better than the 
>status quo, because browsers *could* display some warning/icon/color in 
>the address bar whenever a proxy is present. However, there is nothing 
>to guarantee that all browser vendors will display such an indication, 
>nor that users would notice if they did.
>
>If you bring your own device, the proxy is visible right now. If you 
>use your employer's device, they are in full control of whether you are 
>or aren't aware.
>
>Yoav
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 May 2013 11:00:45 +0000

Hi

On May 6, 2013, at 1:37 PM, "Adrien W. de Croy" <[email-masked]>
 wrote:

>> Corporate proxies are installed by the same IT departments that install the corporate laptops. So why bother the user with pesky warning screens and with installing CA certificates / trusted proxy certificates?
> Current MiTM schemes require a certificate to be trusted by the client in order to avoid incessant cert warnings.
> 
> Deployment of this cert is more or less of a headache depending on the network environment and client OS.  For instance in a Windows AD, they can be pushed out to domain members by Group Policy.
> 
> However, enforcement of interception for computers/devices not directly under the administative control of the organisation/IT department (e.g. phones, or visitors' devices) remains a problem.
> 
> In the end, whether the reasons for wanting to intercept an inspect https traffic are bogus or not according to us is moot.  Customers will go where they are served.  Any proxy (forward) vendor who does not currently support https inspection, or doesn't have a plan for it, has IMO numbered days.
> 
> If all the proxy vendors banded together and refused to provide https inspection it wouldn't be a problem. But that's not the case, and to not offer it is increasingly (yes the problem is growing) IMO a serious competitive disadvantage.  Customers simply don't care.  They want to:
> 
> * enforce DLP policy
> When it was only banks using SSL it wasn't a problem - customers didn't really care about not being able to scan bank traffic.  Facebook made it a problem for everyone.  The more big sites move to SSL the worse it gets.
> 
> I hear arguments that standardising MiTM will open the door for illicit and clandestine eavesdropping or worse.  However, how do the external parties get you to install the trusted root cert?  Or does this claim rely on users ignoring cert warnings?  How is this any worse than the current situation?
> 
> Being able to advertise your presence (as an https-inspecting proxy) is surely better than the current scenario.  What would be better still is a way for an organisation to enforce use of a proxy, esp for visiting devices.  To be able to intercept, and divert to something that can
> 
> b) provide a painless way for the browser or other agent to be configured to use the proxy (if desired by the user) in accordance with the policy.
> 
> Currently it's not even possible to display a page instead of the requested (https) destination in the case where the client is not configured to use a proxy, and doesn't have the proxy spoofing cert installed.  Not at least without a browser cert warning.  You get 2 choices:
> 
> - look at requested server, or connect to destination and obtain actual cert
> - spoof the cert
> 2. Disconnect the client if it goes somewhere it's not authorized to.  This leads to in general lousy user experience and support calls.
> 
> So, we don't want to do anything about this?  The problem isn't going away, and more MiTM implementations are being deployed.  It's the user that suffers in the end if we don't act to improve things for them.
> 
> Cheers
> 
> Adrien

You're preaching to the choir here. I work for a vendor of such proxies, and I'm a co-author of Dave McGrew's draft. I'm just saying that we should not exaggerate the benefit to the user of having an explicitly trusted proxy vs an explicitly trusted CA certificate.

Yoav

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 06 May 2013 23:29:29 +0000

Hi Yoav

not everyone here is a member of our choir :)

Regards

Adrien

------ Original Message ------
From: "Yoav Nir" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Werner Baumann" <[email-masked]>; 
"<[email-masked]>" <[email-masked]>
Sent: 6/05/2013 11:00:45 p.m.
Subject: Re: Comments on Explicit/Trusted Proxy
>>>  Corporate proxies are installed by the same IT departments that 
>>>install the corporate laptops. So why bother the user with pesky 
>>>warning screens and with installing CA certificates / trusted proxy 
>>>certificates?
>>  Current MiTM schemes require a certificate to be trusted by the 
>>client in order to avoid incessant cert warnings.
>>
>>  Deployment of this cert is more or less of a headache depending on 
>>the network environment and client OS. For instance in a Windows AD, 
>>they can be pushed out to domain members by Group Policy.
>>
>>  However, enforcement of interception for computers/devices not 
>>directly under the administative control of the organisation/IT 
>>department (e.g. phones, or visitors' devices) remains a problem.
>>
>>inspection it wouldn't be a problem. But that's not the case, and to 
>>not offer it is increasingly (yes the problem is growing) IMO a 
>>serious competitive disadvantage. Customers simply don't care. They 
>>want to:
>>
>>  * enforce DLP policy
>>  When it was only banks using SSL it wasn't a problem - customers 
>>didn't really care about not being able to scan bank traffic. Facebook 
>>made it a problem for everyone. The more big sites move to SSL the 
>>worse it gets.
>>
>>  I hear arguments that standardising MiTM will open the door for 
>>illicit and clandestine eavesdropping or worse. However, how do the 
>>external parties get you to install the trusted root cert? Or does 
>>this claim rely on users ignoring cert warnings? How is this any worse 
>>than the current situation?
>>
>>  Being able to advertise your presence (as an https-inspecting proxy) 
>>is surely better than the current scenario. What would be better still 
>>is a way for an organisation to enforce use of a proxy, esp for 
>>visiting devices. To be able to intercept, and divert to something 
>>that can
>>
>>configured to use the proxy (if desired by the user) in accordance 
>>with the policy.
>>
>You're preaching to the choir here. I work for a vendor of such 
>proxies, and I'm a co-author of Dave McGrew's draft. I'm just saying 
>that we should not exaggerate the benefit to the user of having an 
>explicitly trusted proxy vs an explicitly trusted CA certificate.
>
>Yoav
>