Subject: [TLS] TLS Proxy Server Extension

From: David McGrew <[email-masked]>
Date: Tue, 26 Jul 2011 08:01:31 -0700

Hi,

I would like to request feedback on a new draft that Philip Gladstone  
and I put together, which aims to solve some of the security problems  
that happen when there is a (HTTP) proxy present and TLS is in use.    
The approach is to require the proxy to provide the client with  
additional information that the client can use to make a well-informed  
decision about the security of the session.  This draft was put  
together too late to request a slot at the WG meeting this week, but  
if you have thoughts on either the goals or the mechanism, we can  
discuss either in person or on the list.

David

http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 26 Jul 2011 17:23:12 +0200

Hi,

I just skimmed the start of the document

I assume, from context, that your use case is for proxies that perform an  
authorized MITM "attack" on the TLS connection by issuing specific "fake"  
certificates for the site you are connecting to, decrypting/re-encrypting  
the encrypted data, and not a proxy that uses the normal HTTP CONNECT  
request and just passes packets back and forth and the TLS connection is  
end-to-end. Right?

If so, that should perhaps be made clearer in the introduction and  
abstract, possibly by using a different term for the proxy? My association  
with "proxy" is generally the ordinary CONNECT packet forwarding proxy,  
not the MITM proxy.

IMO, when you authorize a proxy to MITM your connections, you also  
implicitly accept the security policies of the proxy, and whatever  
encryption and certificate it trusts.

As an alternative way forward, might it not be an equally good way forward  
to require the proxy to either negotiate the same encryption methods with  
the client as it negotiated with the server, or alternatively, only offer  
the mutually acceptable set of cipher suites for the client and proxy  
(perhaps with an addition for better suites, allowing an encryption  
upgrade)?

On Tue, 26 Jul 2011 17:01:31 +0200, David McGrew <[email-masked]> wrote:

> decision about the security of the session.  This draft was put together  
> too late to request a slot at the WG meeting this week, but if you have  
> thoughts on either the goals or the mechanism, we can discuss either in  
> person or on the list.
>
> David
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: David McGrew <[email-masked]>
Date: Tue, 26 Jul 2011 10:38:39 -0700

Hi Yngve,

On Jul 26, 2011, at 8:23 AM, Yngve N. Pettersen wrote:

> I assume, from context, that your use case is for proxies that  
> perform an authorized MITM "attack" on the TLS connection by issuing  
> specific "fake" certificates for the site you are connecting to,  
> decrypting/re-encrypting the encrypted data, and not a proxy that  
> uses the normal HTTP CONNECT request and just passes packets back  
> and forth and the TLS connection is end-to-end. Right?
>

right.

> abstract, possibly by using a different term for the proxy? My  
> association with "proxy" is generally the ordinary CONNECT packet  
> forwarding proxy, not the MITM proxy.

Yes, I think so.

> encryption and certificate it trusts.

Right, this is what happens at present.

> As an alternative way forward, might it not be an equally good way  
> forward to require the proxy to either negotiate the same encryption  
> methods with the client as it negotiated with the server, or  
> alternatively, only offer the mutually acceptable set of cipher  
> suites for the client and proxy (perhaps with an addition for better  
> suites, allowing an encryption upgrade)?

Agreed that it is a good idea for the proxy to offer a subset of the  
ciphersuites offered by the client.  But this only covers the crypto  
policy - it doesn't address the problem of how the client can decide  
whether or not it trusts the server on the other side of the proxy,  
for the particular application in use.  Section 2 of the draft  
outlines this in some more detail.

As a side note, I think that for almost all purposes, the ciphersuites  
offered by the proxy should be a subset of those offered by the  
client.  The one scenario where we might decide that it is a good idea  
to allow the proxy to offer other ciphersuites is the case in which  
the client and server do not have a mutually acceptable ciphersuite;  
in this case the proxy is acting like a translator.   I am not  
thrilled about this scenario, because it implies that there is lack of  
interoperability which I think should be avoided if/when possible, but  
I do not think that it would make sense to exclude the scenario.

thanks,

David

>> I would like to request feedback on a new draft that Philip  
>> Gladstone and I put together, which aims to solve some of the  
>> security problems that happen when there is a (HTTP) proxy present  
>> and TLS is in use.   The approach is to require the proxy to  
>> provide the client with additional information that the client can  
>> use to make a well-informed decision about the security of the  
>> session.  This draft was put together too late to request a slot at  
>> the WG meeting this week, but if you have thoughts on either the  
>> goals or the mechanism, we can discuss either in person or on the  
>> list.
>>
>> David
>>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jul 2011 00:17:09 +0300

> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00

Hi Dave.

I like this draft. TLS proxies are becoming a fact of life. They still have significant drawbacks in that the "fake" certificates that they generate are not identical to the original certificates. For example, the fake certificates cannot be EV certificates, and therefore the users lose the "green-bar" indication.

I don't know if you're following the LockFoo discussion on WebSec, but all of those locks would cause a hard-fail for clients connecting to sites that have specified them. As security people we might think "good!", but that would actually be a bar to implementations of LockFoo more than it would be a bar to deployment of TLS proxies. Giving the client access to the original certificates would allow the browser to overcome this limitation.

A similar argument also applies to DANE. If the DNS entry identifies the key, the certificate or the CA, then the "fake" certificate would cause an error. Access to the original certificate chain allows the client to eliminate the error message, although I am not sure how the browser UI would indicate an EV certificate proxied through a non-EV proxy.

I am wondering why you would need the ConnectionSecurityParameters structure. Wouldn't the 2-byte ciphersuite be a more compact way to represent this information?

Also I would add text about EV certificates (and maybe also the LockFoo cases of DANE and WebSec) to the motivation section.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jul 2011 00:20:40 +0300

Also, I'd lose section 3.2.  It doesn't add much :-)

On Jul 26, 2011, at 5:17 PM, Yoav Nir wrote:

> Scanned by Check Point Total Security Gateway.
> 
> <smime.p7s><ATT00001..txt>

---

From: Adam Langley <[email-masked]>
Date: Tue, 26 Jul 2011 17:25:59 -0400

> I don't know if you're following the LockFoo discussion on WebSec, but all of those locks would cause a hard-fail for clients connecting to sites that have specified them. As security people we mig…

At least in Chrome, user installed root CAs can override certificate
pins. Thus MITM proxies aren't broken and nor will they be by any of
the various pinning proposals in websec.

Cheers

AGL

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Jul 2011 00:41:28 +0300

> the various pinning proposals in websec.

Really?  I thought Chrome used the operating system TA store. How can it tell the difference between a trust anchor that was installed by Microsoft and one that was installed by the user?

But I know that the EV indication goes away behind a proxy, and there's no way to make your CA certificate "EV" to the browser. Dave's proposal allows the green label to come back.

Yoav

---

From: Adam Langley <[email-masked]>
Date: Tue, 26 Jul 2011 17:51:56 -0400

> Really?  I thought Chrome used the operating system TA store. How can it tell the difference between a trust anchor that was installed by Microsoft and one that was installed by the user?

Not in any very clean way I'm afraid:

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_known_roots_win.h?revision=80765&view=markup

> But I know that the EV indication goes away behind a proxy, and there's no way to make your CA certificate "EV" to the browser. Dave's proposal allows the green label to come back.

I've poked BlueCoat at least about this problem in the past and they
didn't appear to be too exercised by it. It's really the MITM folks
who need to figure out if this address their needs or not. I simply
don't know the requirements in this space well enough to know if the
draft meets them. From my point of view, we keep MITM in the back of
our minds but otherwise mostly ignore them except to ban certain
troublesome vendors from time to time.

Cheers

AGL

---

From: David McGrew <[email-masked]>
Date: Tue, 26 Jul 2011 18:50:57 -0700

On Jul 26, 2011, at 3:00 PM, Philip Gladstone wrote:

>
>
> On 7/26/2011 5:17 PM, Yoav Nir wrote:
>>
>> I am wondering why you would need the ConnectionSecurityParameters  
>> structure. Wouldn't the 2-byte ciphersuite be a more compact way to  
>> represent this information?
>>
> Yes it would. Thank you for that comment!

Agreed that much of the info is redundant with the ciphersuite, but  
there are some info that might be worth reporting on, such as the key  
sizes and the truncated HMAC extension.

David

>
> Philip
>
> -- 
> Philip Gladstone
> Distinguished Engineer
> Product Development
> [email-masked]
> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
> Google: +1 978 800 1010
> Ham radio: N1DQ
>
>

---

From: David McGrew <[email-masked]>
Date: Tue, 26 Jul 2011 18:54:11 -0700

Hi Yoav,

thanks for the good suggestions.

David

On Jul 26, 2011, at 2:17 PM, Yoav Nir wrote:

> I like this draft. TLS proxies are becoming a fact of life. They  
> still have significant drawbacks in that the "fake" certificates  
> that they generate are not identical to the original certificates.  
> For example, the fake certificates cannot be EV certificates, and  
> therefore the users lose the "green-bar" indication.
>
> I don't know if you're following the LockFoo discussion on WebSec,  
> but all of those locks would cause a hard-fail for clients  
> connecting to sites that have specified them. As security people we  
> might think "good!", but that would actually be a bar to  
> implementations of LockFoo more than it would be a bar to deployment  
> of TLS proxies. Giving the client access to the original  
> certificates would allow the browser to overcome this limitation.
>
> A similar argument also applies to DANE. If the DNS entry identifies  
> the key, the certificate or the CA, then the "fake" certificate  
> would cause an error. Access to the original certificate chain  
> allows the client to eliminate the error message, although I am not  
> sure how the browser UI would indicate an EV certificate proxied  
> through a non-EV proxy.
>
> Also I would add text about EV certificates (and maybe also the  
> LockFoo cases of DANE and WebSec) to the motivation section.
>
> Yoav
>

---

From: David McGrew <[email-masked]>
Date: Tue, 26 Jul 2011 19:04:24 -0700

Hi Adam and Yoav,

On Jul 26, 2011, at 2:51 PM, Adam Langley wrote:

>> Really?  I thought Chrome used the operating system TA store. How  
>> can it tell the difference between a trust anchor that was  
>> installed by Microsoft and one that was installed by the user?
>
>> But I know that the EV indication goes away behind a proxy, and  
>> there's no way to make your CA certificate "EV" to the browser.  
>> Dave's proposal allows the green label to come back.
>

I like the succinct way that you put it.

> troublesome vendors from time to time.

I believe that the approach in the draft meets the broad requirements  
of many MITM devices and services: it doesn't require much new session  
state, or new policy that would need to be coordinated or managed, and  
there is not too much additional computation.  That plus it adds back  
security, which is important in general and is especially important  
for proxy devices that are providing security services.   But I can't  
claim to have broad knowledge of all such devices, so it will be  
useful to hear from others in this space.

David

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Jul 2011 22:42:30 -0400

> that happen when there is a (HTTP) proxy present and TLS is in use.

It doesn't seem that this work is in any way specific to HTTP.

Suggestions:

- If you're going to require support from the client, you might as well
do something to support client authentication on the server-side
connection, e.g., tunnel the PKCS#11 protocol back to the client.

- You could bundle the whole sequence of handshake messages from the
server-side connection in the ProxyInfo and let the client deal with it
rather than muck about with the ConnectionSecurityParameters here.  This
would include any further ProxyInfos without making a special case.

- It would be better design to put the whole certificate acceptance test
(trust anchor validation + server name check) on the client.  Schemes
such as DANE replace the certificate acceptance test as a whole.

- One approach would be to do a real escrowed TLS where the client
negotiates directly with the server but releases the confidentiality key
and optionally also the integrity key to the proxy.  This subsumes all
of the above concerns but doesn't allow the proxy to manipulate the
handshake in any finer way than blocking the connection if it doesn't
like the outcome.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 26 Jul 2011 23:07:17 -0400

> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_known_roots_win.h?revision=80765&view=markup

Yeah, that approach ensures that the pins you ship by default do not
break MITM proxies (since public CAs are bound not to support MITM
proxies, or at least we have no sympathy for them if they do), but it
also (arguably) negates their promised benefits in environments with
custom CAs, a superset of those with MITM proxies.  That choice of
trade-off is understandable but pretty disappointing.  Power users will
want to designate MITM-proxy CAs explicitly.  I guess I could file an
enhancement request...

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jul 2011 20:17:17 +0200 (MEST)

> It doesn't seem that this work is in any way specific to HTTP.

Only for Web-Browser scenario can I personally see a very limited
value that does not amount to 100% wiretapping.

Are you aware of rfc2804 "IETF Policy on Wiretapping"?

  http://tools.ietf.org/html/rfc2804

Standardizing MITM attacks on TLS-protected communication
("lawful intercept?") seems like an extremely bad idea to me.

Checking whether some data conforms to a certain company policy will
almost always be illegal in European countries, where we have
sensible data protection laws.

> handshake in any finer way than blocking the connection if it doesn't

For the purpose of "centralized malware screening", for the incoming
Web traffic of Web Browsers that are well known to interpret such
data in arbitrarily stupid ways (such as active content, img src, (i)frame,
javascript, css), sharing the encryption traffic keys with the Proxy
would be perfectly sufficient, and that also enables the clients
to clearly limit who is able to read the traffic.  No super-CA-equivalent
keys would need to be on the malware-scanning Proxy.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 29 Jul 2011 00:33:19 -0400

On Thu, 2011-07-28 at 12:48 -0700, David A. McGrew wrote:
> It would be great to promote client authentication, though I'm not  
> exactly sure what you are proposing.  Do you mean to pass PKCS#11  
> through a TLS extension?

No, I imagine PKCS#11 would use several round trips, so a new
ContentType would be needed.  It's probably possible to define a more
efficient protocol than a serialization of PKCS#11, but also more work.
Whatever the protocol would be, it has to nest to handle multiple
proxies.

> I also have the sense that it is best to have the client do all the  
> work in most cases.   But do you think it would be OK to eliminate the  
> possibility that the proxy does some of the work?

Not sure.  Do you have a use case for the proxy doing some or all of the
work?  My point was that splitting the server name check from the trust
anchor validation is specific to PKIX certificate acceptance and serves
no purpose that I can foresee, while doing the whole test on the client
often makes sense because the client is prepared to do the whole test in
the absence of a proxy.

> I think that propagating secret or private keys from one device to  
> another is not a good idea, for crypto reasons which are outlined in  
> Section 6 of the draft.

I missed the potential attack when the stream is edited under a single
integrity key.  And indeed, I am having trouble coming up with any
scheme that is fundamentally simpler than two separate TLS connections
and does not introduce security problems.  You may still wish to provide
as much client-to-server negotiation transparency as possible.

Another comment:

>    The ProxyInfo
>    proposal [...]
>    allows the client to refuse to deal with untrusted proxies.

This has to be understood carefully.  An "untrusted proxy" is just a
MITM attacker.  In general, we already have a mechanism for refusing to
deal with them: it's called server authentication.  The above benefit
exists /compared to the alternative/ of a proxy trust anchor.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 29 Jul 2011 00:51:30 -0400

> ("lawful intercept?") seems like an extremely bad idea to me.

This is not wiretapping as defined in that policy.  Not that I would
ever be willing to use a TLS proxy for personal activities, but I see no
reason to block the standardization.  In fact, I am intrigued by the
idea.

> sensible data protection laws.

If you are thinking of corporate networks (the typical current use of
the proxies in question), I don't see how restricting what checks a
company can do on its own property is sensible, but that is off topic...

> would be perfectly sufficient

Correct.

> and that also enables the clients
> to clearly limit who is able to read the traffic.

Huh?  The proxy's ability to pass decrypted data to someone else is no
different than if it were bridging two TLS connections.

> No super-CA-equivalent

You speak as if that were in a whole different class of badness, but the
actual effect is simply to give up integrity as well as confidentiality
to the proxy.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jul 2011 08:21:38 +0200 (MEST)

> different than if it were bridging two TLS connections.

No, that is entirely different.

Revealing the traffic **encryption** keys to the proxy requires cooperation
of the client, so a sensible client implementation can ask for consent
and the user may deny consent, whereas a proxy with a super-CA-cert
can subvert any connection for that client, no matter where that
client goes--and MitM all connections any time, including those that do
not traverse that proxy.

> actual effect is simply to give up integrity as well as confidentiality

You would not reveal the MAC keys, of course. only the encryption keys.

There is no need to allow the proxy to modify the traffic.  If the
proxy doesn't like some of the data, it should not pass it along and
terminate the connection.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 29 Jul 2011 10:22:27 -0500

> The ProxyInfo extension only provides information about proxies to
> the client; it does not provide any information to the server about
> either the client or other proxies on the path.  This is acceptable
> when there are no client certificates in use, which is (regrettably)
>  common in practice.  It would be possible to generalize the ideas in
>  this note to also provide information to the server about the client
>  and other proxies on the path.  Nonetheless, that goal is out of
> scope for this note.

It's good that the draft is explicit about what is not being provided to
to the server.

But, please, won't somebody think of the poor servers?

As someone who works on the security of an authentication service
delivered through TLS, I feel the need to oppose the standardization of
functionality with the potential to undermine the security of our service.

It was once said that the driving purpose of the design of SSL was to
make users *feel* secure enough to be comfortable entering their credit
card number on the web and I've seen little or no evidence to refute
that claim. In this model, all the paranoia is expected to reside with
the user.

One of the unfortunate artifacts of the resulting design is that the
server has no way to prove the nonexistence of a MitM, he can only hope
that the client will do a good job of this. We all know how well this
works when put to the test by an active attacker. Client certificates
are currently the only tool available for server admins to participate
in preventing this important class of attacks. The authors of this draft
seem to feel the relative infrequency of client certificate usage is
"regrettable", yet they propose standardizing a scheme which will break
them entirely!

Consider, for example, the scenario which was described to me by someone
in the retail sector. She was responsible for auditing security policies
for a retail credit card website. They interpreted the relevant laws and
industry regulations to mean that they were obligated to intercept
employee web browser usage to monitor for and block various forms of
undesired content. However, employees may also have personal credit
cards with the same issuer, the statements of which they might sometimes
access from their desk at work. But the organization considered itself
forbidden from snooping on that traffic.

I don't know if or how they got it sorted out, my point being only that
there are several parties involved here and it's not clear at all the
circumstances under which one party may have an absolute right to
impersonate, decrypt, or MitM the traffic even between its own clients
and servers.

If you operate a financial or government site, you may be under various
legal obligations to ensure that certain information is transmitted only
to the intended recipient. Today this is commonly done (weakly) with
non-client certificate HTTPS websites. If or when MitM interception
becomes standardized and widespread it will obligate the use of client
certificates to satisfy this requirement while at the same time breaking
their functionality entirely.

Any standardization of MitM or interception functionality must take into
account the requirements of the server operators as an equal party and
stakeholder in the security of the connection.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Fri, 29 Jul 2011 19:52:28 +0300

> functionality with the potential to undermine the security of our service.

This draft does not invent TLS proxies or even standardize them. It invents a way for the client to recover some of the information that is lost because of the existing use of TLS proxies.

> "regrettable", yet they propose standardizing a scheme which will break

I can see how this draft could be extended to support client certificates, but that would require changes to the server as well, and a change to the state machine that elevates this draft in the new taxonomy from "trivial" to "significant", so we probably don't want that at all.
But client certificates are already broken now behind a TLS proxy. This draft does not make this worse. It does mean that other things that got broken, like HSTS and EV can be unbroken.

> impersonate, decrypt, or MitM the traffic even between its own clients

Operating a MitM requires issuing fake certificates from a CA that is not trusted by any browser out of the box. The user will get the warning messages from the browser unless they choose to trust this CA, or are required to do so by company policy. In both cases the existence of the MitM is known to the user. I agree that there is an ethical issue with having the CA certificate pre-installed on the "company laptop" without telling the user.

> their functionality entirely.

That's the beauty of this draft. If MitM boxes support it, it will expose (to the browser) the existence of a MitM even without user certificates. Maybe WebSec should standardize a header that says "no-tls-proxies". A client that detects a proxy and receives this header breaks the connection and shows a red warning screen.

Fortunately today many people have an alternative to "company network". If the company network has a MitM and you don't want it to see your credit card number or scan the attachments you get to your gmail account, just surf from your phone. Just as you would call from your phone if the company may listen in on phone conversations.

> stakeholder in the security of the connection.

Stealthy MitM are possible today with company computers without any standardization effort by the IETF. We can make it possible for clients and MitM to play nice - inform the browser, etc.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Fri, 29 Jul 2011 13:33:30 -0500

On 07/29/2011 11:52 AM, Yoav Nir wrote:
>
> This draft does not invent TLS proxies or even standardize them.

The IETF defines no such thing as a "TLS proxy". I don't even see how 
such a thing can be defined without violating some basic guarantees of 
the protocol, but I'm open to being educated on that.

> It invents a way for the client to recover some of the information that
> is lost because of the existing use of TLS proxies.

I'm really sympathetic to the necessity of the lesser evil in practice.

But "TLS proxies" currently work poorly today because they are 
underspecified and they violate certain protocol assumptions. Sometimes 
they end up weakening security and breaking higher-layer stuff.

> I can see how this draft could be extended to support client
> certificates, but that would require changes to the server as well,
> and a change to the state machine that elevates this draft in the new
> taxonomy from "trivial" to "significant",

That would be a good thing in my view because the underlying changes 
actually are significant.

> so we probably don't want
> that at all. But client certificates are already broken now behind a
> TLS proxy.

What is this "TLS proxy" of which you speak? I see no SHOULDs or MUSTs 
or which apply to it, much less any cryptographic guarantees about it.

More importantly, what is its security model?

All I see usually amounts to "convince the client to install our trusted 
root and then the MitM can get away with almost anything". Perhaps this 
draft is admirable in that it defines a mechanism with which the MitM 
MAY choose to communicate certain info to the client, but I feel it is 
handwaving over the deeper questions and tacking features on top of an 
architecture which isn't really defined at all.

> This draft does not make this worse.

But it does, it endorses the brokenness as a protocol standard.

> It does mean that
> other things that got broken, like HSTS and EV can be unbroken.

TLS is being changed at a fundamental level, it's not a little tweak 
that just needs a little tweak to change it.

> Operating a MitM requires issuing fake certificates from a CA that is
> not trusted by any browser out of the box.

Has anyone ever asked the rightful domain holders how they might feel 
about someone minting certificates with their name on them?

> The user will get the
> warning messages from the browser unless they choose to trust this
> CA, or are required to do so by company policy. In both cases the
> existence of the MitM is known to the user.

Right, it's TLS operating properly as designed to prevent MitM attacks. 
If only TLS had been designed such that the server could resist them as 
well!

> I agree that there is an
> ethical issue with having the CA certificate pre-installed on the
> "company laptop" without telling the user.

Honestly, I don't see that as the big issue in general. Such laptops 
commonly have a wide variety of spyware installed already and employees 
should have no expectation of privacy on it, IMHO.

But note that the web site being accessed is not a party to that 
employment contract!  Lying to the web browser about the authenticity of 
the server's identity could be viewed as lying to the server about the 
absence of a MitM. Oh what a tangled web we weave!

> That's the beauty of this draft. If MitM boxes support it, it will
> expose (to the browser) the existence of a MitM even without user
> certificates.

Couldn't that be done today without a protocol change by looking at the 
issuer?

> Maybe WebSec should standardize a header that says
> "no-tls-proxies". A client that detects a proxy and receives this
> header breaks the connection and shows a red warning screen.

Why wouldn't the MitM simply strip the header while he was at it?

> Fortunately today many people have an alternative to "company
> network". If the company network has a MitM and you don't want it to
> see your credit card number or scan the attachments you get to your
> gmail account, just surf from your phone. Just as you would call from
> your phone if the company may listen in on phone conversations.

I agree that the best course of action for the user is to use a network 
which does not have a MitM policy (or possibly establish a secure tunnel 
to one).

> Stealthy MitM are possible today with company computers without any
> standardization effort by the IETF. We can make it possible for
> clients and MitM to play nice - inform the browser, etc.

I don't want them to play nice. They're broken now because they violate 
a fundamental principle of the security model: clients trust CAs to 
accurately represent the identity of the target domain (don't laugh :-).

Making them 'play nice' appears to reduce my effective security as a 
server operator.

- Marsh

---

From: David McGrew <[email-masked]>
Date: Fri, 29 Jul 2011 12:32:46 -0700

Hi Martin,

On Jul 27, 2011, at 11:17 AM, Martin Rex wrote:

>>> Gladstone

Standardizing MITM attacks would be awful, but that's not at all what  
the draft is proposing.

> sensible data protection laws.

Firewalls are illegal in Europe?  That can't be right.

IANAL, but it appears that the approach of the draft (which notifies  
the client about the presence of a proxy, as well as provides info on  
the server) could help to meet the EU Data Protection Directive, in  
that it informs the data subject when his/her personal data are being  
processed by a proxy, a condition that must be met in some cases.

> keys would need to be on the malware-scanning Proxy.

In what way is a protocol that propagates secret keys to a proxy any  
better with regard to privacy?   Note that if such a protocol is used  
by a server, then the client is not informed.

David

---

From: David McGrew <[email-masked]>
Date: Fri, 29 Jul 2011 12:33:31 -0700

Hi Martin,

> client goes--and MitM all connections any time, including those that  

It sounds like you misunderstand the proposal.  The approach we are  
going for is one in which the client is fully informed about both the  
proxy and the server, and the client is free to choose to trust them  
or not.

> terminate the connection.

No, this undermines the cryptographic security.  Please see Section 6  
of the draft.

A malware-screening proxy needs to be able to modify the traffic  
flowing through it.  It would be pointless for it to detect malware,  
and then pass it on to the client!

David

---

From: David McGrew <[email-masked]>
Date: Fri, 29 Jul 2011 13:00:28 -0700

Hi Marsh,

> "regrettable", yet they propose standardizing a scheme which will  

Important clarification: we have not proposed any standards action, we  
have requested comments on a draft.  I felt that the approach outlined  
in the draft deserved to be discussed even though it does not address  
the issue of client authentication to the server.  I would strongly  
prefer a solution that works with client certificates, if one can be  
worked out.   (I think the ideal security goal here would be something  
like three-party mutual authentication and authentication checking.   
If we are willing to be invasive to TLS, we could do something like  
that.  If C/S/P each issued nonces and signed all of the nonces, that  
would get us most of the way there.   That sounds like an interesting  
design exercise, but I am skeptical that we could get broad  
deployment.  How close we can get to that goal is something worth  
exploring.)

In the absence of a client certificate, the proxy extension does  
improve security, because it restores server authentication and  
authorization, and that operation is essential when the client is  
using password-based authentication  to the server.

David

---

From: David McGrew <[email-masked]>
Date: Fri, 29 Jul 2011 13:42:23 -0700

Hi Marsh,

On Jul 29, 2011, at 11:33 AM, Marsh Ray wrote:

> The IETF defines no such thing as a "TLS proxy". I don't even see  
> how such a thing can be defined without violating some basic  
> guarantees of the protocol, but I'm open to being educated on that.
>
> underspecified and they violate certain protocol assumptions.  
> Sometimes they end up weakening security and breaking higher-layer  
> stuff.
>
> What is this "TLS proxy" of which you speak? I see no SHOULDs or  
> MUSTs or which apply to it, much less any cryptographic guarantees  
> about it.
>

Some appropriate security goals are outlined in Section 6.  They are  
client-oriented; as you pointed out, ideally the server would gain  
some assurances about the client as well.

>
> All I see usually amounts to "convince the client to install our  
> trusted root and then the MitM can get away with almost anything".  
> Perhaps this draft is admirable in that it defines a mechanism with  
> which the MitM MAY choose to communicate certain info to the client,  
> but I feel it is handwaving over the deeper questions and tacking  
> features on top of an architecture which isn't really defined at all.

I would be interested to hear your thoughts on what sort of  
architecture would be good.

It might be appropriate to have the certificate held by the proxy have  
an attribute that states that it is a proxy.  An attribute could be  
used to limit the scope of the proxy as well, based on e.g. DNS.  That  
sort of mechanism would ensure that a proxy would be known to the  
client; it couldn't hide its presence just by not sending the TLS  
Proxy Extension.

David

---

From: Martin Rex <[email-masked]>
Date: Fri, 29 Jul 2011 22:44:49 +0200 (MEST)

Matt McCutchen wrote:
> This is not wiretapping as defined in that policy.

I *STRONGLY* disagree.  That is very much about wiretapping and
even goes far beyond that, because it not only reveals the content
of the communication, it also allows the "TLS proxy" to arbitrarily
manipulate the communication in a fashion that might be entirely
concealed to the communication peers at the end.

I am strongly opposed to have any document describing such proxies
published as an RFC!

-Martin

---

From: David McGrew <[email-masked]>
Date: Fri, 29 Jul 2011 15:24:09 -0700

>> This is not wiretapping as defined in that policy.

Right, it's clearly not wiretapping as per RFC 2804: "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 ..."   The intent of  
the work we are discussing is to ensure that the client knows about  
the third party.

> I am strongly opposed to have any document describing such proxies

And yet you would favor a protocol that propagates decryption keys  
around the network?

We don't have a choice about whether or not TLS proxying will be done  
on the Internet; it is being done.  What we can choose is whether or  
not the IETF improves how it is being done.

David

---

From: Martin Rex <[email-masked]>
Date: Sat, 30 Jul 2011 01:26:57 +0200 (MEST)

David McGrew wrote:
> Martin Rex wrote:
> No, this undermines the cryptographic security.
> Please see Section 6 of the draft.

I'm having some difficulties understanding Section 6, but some of what
is described is clearly bogus and some clearly wrong.

Cryptographic security of the TLS protocol is clearly unaffected
from sharing the traffic encryption keys with the proxy.
What happens is that the proxy may remove confidentiality of the
data and look at the data before passing along the original, encrypted
data the the rightful communication peer.

It is a design property of the TLS protocol that having access
to the traffic encryption keys does not allow _you_ to subvert other
characteristics of the protocol beyond the confidentiality.

> and then pass it on to the client!

Huh?  The peer does not get anything that the proxy does not forward.
And if there is something goofy. the proxy simply terminates the
connection (both connection. that to the real server and that to the
real client). 

Proxies MUST NOT change a single bit of the data stream,
any capability to modify the communication without the receiver aborting
the connection because of a data integrity violation would mean
that you have _completely_ subvert the security of the whole system,
and there would exist no technical limits to arbitrary and fully covert
modifications.

> > Revealing the traffic **encryption** keys to the proxy requires  
> > cooperation of the client, so a sensible client implementation
> > can ask for consent and the user may deny consent, whereas a proxy
> > with a super-CA-cert can subvert any connection for that client,
> > no matter where that client goes--and MitM all connections any time,
> > including those that do not traverse that proxy.
> 

"The client (should) know(s) about it" is not a legally valid
escape from the obligations for data privacy and data integrity
guaranteed by the our constitution and the data protection laws,
at least not here in Germany.

For the purpose of malware screening, the proxy having only the traffic
encryption keys is perfectly sufficient.  And because it is perfectly
sufficient, the MAC keys fall under constitutional protection and
requesting them would be unlawful.

A little more than three years ago our constitutional court
described the concept of a
 "fundamental right to the guarantee of the
  confidentiality and integrity of information technology systems"

based on the abstract gurantees of fundamental rights by our
constitution specifically applied to modern information technology.

e.g.
http://www.bundesverfassungsgericht.de/pressemitteilungen/bvg08-022en.html

(the original german-language decision is elaborate, crystal clear and
 perfectly fits with 4-5 earlier decisions about telecommunication
 and informational self-determination that I knew before this decision.
 The german press release seems just slighty inaccurate in some details
 (secretarial sloppiness), but I'm having significant difficulties
 understanding the official english-language press release...)

Given the clear and consistent history of decisions by our constitutional
court on the "fundamental right for informational self-determination" with
respect to telecommunication and protection of data transported by
or stored on information technology systems, there are a number of
current practices in german companies that are very probably
un-constitutional by that measure, and it is only a matter of time
when the attitude of lower courts and lawyer, that even today frequently
fail to properly account for the requirements published by our
constitutional court, get challenged and overturned, with the result
that a number of popular current practices encroaching on integrity and
privacy of telecommunication, will have to be discontinued
in Germany.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 30 Jul 2011 04:30:57 +0200 (MEST)

> >> This is not wiretapping as defined in that policy.

On the contrary, it is EXACTLY wiretapping _as_meant_by_rfc2804_.

> the work we are discussing is to ensure that the client knows about  

As Marsh Ray previously pointed out...

...the server might be sending a response, and due to the server
not knowing about the MitM on the communication link to the client
this falls within the description and intent of RFC2804.

In Germany such a TLS proxy will always and unconditionally fall under
the constitutional protection of telecommunications (Art 10 Abs. 1 GG),
unless **ALL** communication parties have consciously agreed.

(it would fall under the less stringent constitutional protection
 of informational self-determination of the sender of information
 when communication contents were leaked only at a rightful
 TLS endpoint as conceived by the information sender,
 which is _still_ a very serious legal problem where I live).

> And yet you would favor a protocol that propagates decryption keys  

That approach would ensure communication integrity and keep client
certificates functional.  Favour? No, but it is by a huge margin the
lesser evil and the lesser security problem when compared to a
TLS-terminating proxy with a super-CA-equivent keypair that can
fake every server cert and surreptitiously modify all
comunications, which completely precludes control and accountability
through technical/protocol safeguards.

> not the IETF improves how it is being done.

The IETF does not have a choice whether law enforcement does
wiretap, yet it refuses to work on and standarize technology
that provides or facilitates such activities.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 29 Jul 2011 22:35:16 -0500

> And yet you would favor a protocol that propagates decryption keys

I'm with Martin on this one.

If the goal is to allow well-regulated eavesdropping of a TLS protocol 
stream it would be better done via a mechanism which transfers the 
minimum necessary secret key material to the authorized party with the 
consent of both legitimate endpoints. Although I've often wanted such a 
thing for debugging, I don't like it. But it would be preferable to 
having middleboxes falsely impersonating the identity of servers.

Just because you can convince a client to accept your trusted root cert 
it doesn't give you the moral authority to impersonate the identity of a 
third party or deceive them about the connection's security properties. 
Otherwise, by that logic, there are hundreds of governments and 
corporations around the world which would be justified in doing so.

> We don't have a choice about whether or not TLS proxying will be done on
> the Internet; it is being done.

Over the internet? Really? The only case I've heard of was Syria using a 
Blue Coat on their people. I'd assume China has built the capability as 
well.

> What we can choose is whether or not the
> IETF improves how it is being done.

But this is not really "TLS proxying" at all since the TLS is actually 
being stripped off entirely and re-established with a largely 
independent context.

 From a purely technical perspective it sounds as if people want to 
convert TLS from a "two party plus PKI" protocol into a "three party 
plus" protocol, without actually defining the implications of all the 
new trust relationships it brings up.

- Marsh

---

From: David McGrew <[email-masked]>
Date: Sat, 30 Jul 2011 06:20:12 -0700

It seems that you do not understand the intent of the draft or the  
authors.

The use case here is web filtering as it is used by organizations and  
consumers, in which a consumer or an organization chooses to use a  
service or a product that acts as an HTTP proxy, and configures their  
clients to do so.  It is desirable in such cases to use TLS whenever  
possible, and it is certainly desirable that the client be able to  
authenticate the proxy.  The intent of the authors is to enable TLS to  
be used when an proxy is present, and to make clients informed about  
both the proxy and the server, and to provide cryptographically strong  
authentication of both.  The client should be able to decide if it  
accepts the proxy for a particular session, and the scope of the proxy  
should be limited, and the proxy should not lie to the client.   The  
client should also have the full information about the server on the  
other end of the connection.

We oppose the development of a technology that would help a country  
spy on its citizens, and we certainly oppose the development of  
standards in that area.  The IETF can't control how the technologies  
that it develops are used, or who uses them, of course, which makes it  
imperative to not develop any mechanisms that could be used in that way.

David

On Jul 29, 2011, at 8:35 PM, Marsh Ray wrote:

> If the goal is to allow well-regulated eavesdropping of a TLS  
> protocol stream it would be better done via a mechanism which  
> transfers the minimum necessary secret key material to the  
> authorized party with the consent of both legitimate endpoints.  
> Although I've often wanted such a thing for debugging, I don't like  
> it. But it would be preferable to having middleboxes falsely  
> impersonating the identity of servers.
>
> Just because you can convince a client to accept your trusted root  
> cert it doesn't give you the moral authority to impersonate the  
> identity of a third party or deceive them about the connection's  
> security properties. Otherwise, by that logic, there are hundreds of  
> governments and corporations around the world which would be  
> justified in doing so.
>
> Over the internet? Really? The only case I've heard of was Syria  
> using a Blue Coat on their people. I'd assume China has built the  
> capability as well.
>
> But this is not really "TLS proxying" at all since the TLS is  
> actually being stripped off entirely and re-established with a  
> largely independent context.
>
> plus" protocol, without actually defining the implications of all  
> the new trust relationships it brings up.
>
> - Marsh

---

From: David McGrew <[email-masked]>
Date: Sat, 30 Jul 2011 06:22:22 -0700

> is described is clearly bogus and some clearly wrong.

I would be obliged if you could provide specifics.

> from sharing the traffic encryption keys with the proxy.

It would be an exceedingly brittle solution to build a system that  
would be cryptographically insecure if proxies added or changed a  
single byte, then insist and hope that proxies never modify the data  
stream.

> characteristics of the protocol beyond the confidentiality.

That property does not hold for any use of authenticated encryption,  
including that of RFC 5288 or the two drafts using CCM.

> connection (both connection. that to the real server and that to the

What I have been told is that there are proxies that don't work that  
way, and it is not realistic to expect them to work that way.   Rather  
than debate that point on the list, let's seek out some objective data.

> requesting them would be unlawful.

Not using end-to-end message authentication is unconstitutional?   But  
decryption in the middle is OK?

If I rushed to conclusions on this topic, I might think that we are  
violating the constitution because we haven't signed our emails with  
SMIME or PGP.  That can't be right, so apparently a more detailed  
analysis is needed.

David

---

From: Marsh Ray <[email-masked]>
Date: Mon, 01 Aug 2011 01:28:32 -0500

On 07/30/2011 08:20 AM, David McGrew wrote:
> It seems that you do not understand the intent of the draft or the authors.

The intent is nearly irrelevent. The text of the spec and the bits on 
the wire are what matters.

> authenticate the proxy.

HTTP has explicit support for proxies and you can connect to them 
securely via TLS already. Wouldn't this all be done more appropriately 
at the HTTP layer?

> The intent of the authors is to enable TLS to be
> used when an proxy is present,

But the intent of TLS is to prevent man-in-the-middle attacks, i.e., to 
prevent you from proxying it.

Just because you can exploit it almost reliably with a custom root CA on 
today's clients doesn't mean that it's not deeply contrary to the 
security architecture of TLS.

Design a secure way for the legitimate endpoints to agree to share some 
session key material with you in a way that doesn't impersonate anyone. 
I might even support such an extension (but good luck convincing the 
servers of the world).

> and to make clients informed about both
> the proxy and the server, and to provide cryptographically strong
> authentication of both.

This concept of polyamorous TLS is more radical than its proponents want 
to accept.

Current TLS:
Client strongly authenticates server via trusted CA
Server may authenticate client, but usually server relies on client to 
stop S-C MitM
Any proxy can only slow or drop connections

"TLS proxy" via root cert on client:
Client can't authenticate server any stronger than weakest proxy allows
Client may not even be aware of proxies
Any proxy may degrade security of connections arbitrarily
Any proxy may get pwned and expose its root CA private key
Any proxy may prevent the use of protocol features and extensions
Any proxy can both read and modify plaintext
Server can't authenticate client at all, client certs are busted forever
Server can't authenticate proxy at all
Server probably can't detect proxy downgrade
Proxy relies on client to stop P-C MitM
Server relies on proxy to stop S-P MitM

> The client should be able to decide if it

But by installing the custom root CA in the browser you've weakened the 
guarantees (which derive from "MUST"s and "MUST NOT"s) to merely 
"should"s and "should not"s. I.e., you've removed the strong crypto 
guarantees from the perspective of the legitimate client and (by 
extension) the server, who are the only parties given any security 
guarantees at all in the current TLS RFCs.

> We oppose the development of a technology that would help a country spy
> on its citizens,and we certainly oppose the development of standards in
> that area.

Meh. It already exists for anyone controlling a trusted root or sub-CA, 
why would they choose to turn on this functionality?

> The IETF can't control how the technologies that it develops
> are used, or who uses them, of course, which makes it imperative to not
> develop any mechanisms that could be used in that way.

Put it another way: don't develop mechanisms that break basic security 
guarantees. Even better would be to improve on them.

- Marsh