Subject: [Unbearable] Some further thoughts about TLS proxies and tokbind

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Mar 2015 12:35:53 -0500

Hi

To continue the conversation from today’s session, I’m not talking about server-side proxies such as load balancers, but about client-side TLS MitM.

The issue here is that in the presence of such a proxy, there is one TLS session between the client and proxy, and another between the proxy and the server. Different servers mean different tls_unique values, and with different values, the signature validation fails.

One suggested solution in today’s meeting was for the proxy to manage the sessions on behalf of the UA. Makes sense to trust the proxy with session management, since you’re anyway trusting it with the cleartext. So your client may or may not have a token bound with the proxy, but the proxy does have a token bound with the server. This means that “we” trust the proxy to impersonate UAs to servers and push some of its own requests authenticated with the users’s key.

In practice today, the browsers know when they are being proxied. This is usually done with some heuristic. Google’s is to identify all CAs that do NOT come bundled with the OS but were added by the user, and consider all such CAs to be intercepting proxies. So if the server certificate is signed by such a CA, the connection is considered to be proxied. We could solve the issue by having the browser indicate no support for token binding when faced with a proxied connection. In such a case the server may revert to a legacy session management mechanism, probably cookies.

I don’t think that this is a desirable outcome. Ideally there wouldn’t be TLS proxies at all, but given that they are, it would be good if we could have end-to-end session management even in the absence of end-to-end confidentiality. So if we could use some kind of mechanism to do this in the presence of a proxy. It can be done in several ways. Someone (I think Martin) mentioned a challenge-response idea. Such an idea should be fleshed out to make sure we neither slow down every request nor create a new bearer token.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Mar 2015 16:45:30 -0500

> I don’t think that this is a desirable outcome. Ideally there wouldn’t be TLS proxies at all, but given that they are, it would be good if we could have end-to-end session management even in the ab…

I think that for the most part, the only reason that we have a
proposal to use TLS unique is that it is a) present at the right time,
and b) hard to move (i.e., replay).  A challenge from the server would
accomplish the same end, but only at the cost of a round trip.

I agree that the situation with MitM is potentially bad.  If the MitM
supports this mechanism, the client will go through the
re-authorization process and thereby bless a private key controlled by
the MitM.  I think that runs counter to the goals of the mechanism.

But I don't know how to solve that problem, either by preventing the
impersonation, or by detecting the MitM at the server and suppressing
the binding code.  At this point, I'm inclined to leave as-is.  That
implies some sort of backup protection mechanism if the MitM strips
the binding and maybe even a hard failure if the MitM breaks it.  A
backup mechanism will be required for clients that don't support token
binding.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 24 Mar 2015 22:05:32 +0000

If the client allows MITM (e.g. by installing a MITM root cert), the MITM can modify any application data, suppress the client's offer of Token Binding, or cause the server to bind tokens to a MITM-controlled key. 

Yoav: do you have a suggestion as to how we can achieve end-to-end session management that works in the presence of a TLS proxy?

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, March 24, 2015 4:46 PM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [Unbearable] Some further thoughts about TLS proxies and tokbind

> I don’t think that this is a desirable outcome. Ideally there wouldn’t be TLS proxies at all, but given that they are, it would be good if we could have end-to-end session management even in the ab…

I think that for the most part, the only reason that we have a proposal to use TLS unique is that it is a) present at the right time, and b) hard to move (i.e., replay).  A challenge from the server would accomplish the same end, but only at the cost of a round trip.

I agree that the situation with MitM is potentially bad.  If the MitM supports this mechanism, the client will go through the re-authorization process and thereby bless a private key controlled by the MitM.  I think that runs counter to the goals of the mechanism.

But I don't know how to solve that problem, either by preventing the impersonation, or by detecting the MitM at the server and suppressing the binding code.  At this point, I'm inclined to leave as-is.  That implies some sort of backup protection mechanism if the MitM strips the binding and maybe even a hard failure if the MitM breaks it.  A backup mechanism will be required for clients that don't support token binding.

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Mar 2015 18:19:45 -0500

> On Mar 24, 2015, at 5:05 PM, Andrei Popov <[email-masked]> wrote:
> 

I can think of a few.

When we were coming up with ideas in websec, one suggestion was for the client to sign the request (or rather a selection of the fields from the request that the proxy was not likely to mess with). That way you are on the one hand not bound to TLS, and on the other hand not making a bearer token, because a signature over “GET / HTTP/1.1” works only for requests getting “/“.  The downside of this is that every single request needs a new signature, and the signatures can still be re-used for the same resources unless you add some URL randomization similar to anti-CSRF measures.

Another way is to add to HTTP (or whatever the protocol is) some way of getting a unique identifier for this connection and using that. For example, “GET /.well-known/sessionid” returning two values: identifier and challenge. After that the client would include both "Token-Binding: EncodedTokenBindingMessage” and “Token-Binding-Identifier: identifier” in all subsequent requests. This does create a constant token that lasts for the duration of the connection, and the proxy has to be trusted to not make use of it.

These two can be combined so that the client signs both the challenge and parts of the request. That only has the downside of needing to sign every request.

I don’t know how to make a method that will both work in the presence of a malicious proxy *and* not require a signature on every request. Perhaps something can be designed with a MAC that uses a per-session key, but that stinks of changing HTTP into TLS.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Mar 2015 18:33:31 -0500

> On Mar 24, 2015, at 6:19 PM, Yoav Nir <[email-masked]> wrote:
> 
> 

To be clear, I’m not suggesting text for the draft at this point. I think we’re at the spitball stage. 

I’m not entirely opposed to Martin’s suggestion to leave things as they are, if we can have advice for a UA what to do if a connection is detected (by heuristic) to be proxied, and have a good story on what happens in such a case. I guess this sort-of depends on how this is negotiated.

Yoav

---

From: Andrei Popov <[email-masked]>
Date: Tue, 24 Mar 2015 23:39:48 +0000

> When we were coming up with ideas in websec, one suggestion was for the client to sign the request (or rather a selection of the fields from the request that the proxy was not likely to mess with). That way you are on the one hand not bound to TLS, and on the other hand not making a bearer token, because a signature over “GET / HTTP/1.1” works only for requests getting “/“.

But what prevents the MITM from removing the signature, or from signing with a key of MITM's choosing?

> Another way is to add to HTTP (or whatever the protocol is) some way of getting a unique identifier for this connection and using that. For example, “GET /.well-known/sessionid” returning two values: identifier and challenge. After that the client would include both "Token-Binding: EncodedTokenBindingMessage” and “Token-Binding-Identifier: identifier” in all subsequent requests.

Why can't the MITM use the identifier and challenge in the same way?

Or do you mean that these approaches will work until the MITM is updated to detect and circumvent these mechanisms?

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, March 24, 2015 6:20 PM
To: Andrei Popov
Cc: Martin Thomson; [email-masked]
Subject: Re: [Unbearable] Some further thoughts about TLS proxies and tokbind

I can think of a few.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Mar 2015 19:07:53 -0500

> On Mar 24, 2015, at 6:39 PM, Andrei Popov <[email-masked]> wrote:
> 

The MITM is not malicious. It’s performing either caching or content filtering or anti-malware. In a sense it is trusted by the user, because the user has installed the proxy’s CA certificate to make it work.

If the UA is always behind the proxy, then the proxy can strip the client’s signature and sign with its own key, and then sign some fake requests with the same key. I don’t see how we can prevent that. But if the client is sometimes not behind the proxy, then there will be two keys and the UA won’t get the same authorizations behind the proxy as it gets when not behind the proxy, unless the proxy plays nice.  Perhaps the client should not generate the key pair until it has an unproxied connection.

Yoav

---

From: Andrei Popov <[email-masked]>
Date: Wed, 25 Mar 2015 00:44:03 +0000

Thanks for the clarification Yoav; now I see that you're talking about a MITM that inspects application data, and is willing to collaborate with the client in preventing token theft. Yes, this would work with a form of Token Binding protocol that does not use the tls_unique. Or the other options you've described.

If this is an important enough scenario and folks are passionate about supporting it, I'd prefer that it be documented in a separate I-D.

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, March 24, 2015 7:08 PM
To: Andrei Popov
Cc: Martin Thomson; [email-masked]
Subject: Re: [Unbearable] Some further thoughts about TLS proxies and tokbind

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Mar 2015 20:20:21 -0500

> Thanks for the clarification Yoav; now I see that you're talking about a MITM that inspects application data, and is willing to collaborate with the client in preventing token theft. Yes, this woul…

Another method would be to have an explicit delegation from the client
to the MitM.  Which would allow clients to avoid being affected by
moves between networks that have the proxy or not.  What concerns me
there is the complexity that introduces, so...

> If this is an important enough scenario and folks are passionate about supporting it, I'd prefer that it be documented in a separate I-D.

Yes, this seems best.

---

From: Bill Mills <[email-masked]>
Date: Wed, 25 Mar 2015 03:40:24 +0000 (UTC)

There are many possible TLS proxy types that can cause problems:
1) Local host based proxy like Fiddler2) Corporate egress proxy, almost the same as above but not under user control3) Great FW of China with mandatory trusted certs installed on many machines.  Same class as 2 but more evil.4) TOR which we don't need to solve for.5) Akami type CDN proxies6) Load balancer/accellerators

I think we can solve for #6, and perhaps #5, the rest are out. 

-bill

     On Tuesday, March 24, 2015 6:23 PM, Martin Thomson <[email-masked]> wrote:

Yes, this seems best.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Mar 2015 23:49:01 -0500

On 24 March 2015 at 22:40, Bill Mills <[email-masked]> wrote:
> 4) TOR which we don't need to solve for.

TOR doesn't MitM TLS connections.

If someone wants to build a protocol that allows a server to pull the
necessary information from a trusted gateway, or for a client to
delegate to a trusted proxy, then that might be worthy of
consideration.  My preference would be to do a) end-to-end, then maybe
b) gateway communication, but not c) proxy impersonation assistance.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 25 Mar 2015 01:17:10 -0700

> TOR doesn't MitM TLS connections.

Tor exit nodes are conveniently positioned to MitM traffic*

*That said, I am a fan of Tor**
**As a fan of Tor, I am rather dubious of the opinions people have about
Tor when they describe it as "TOR". It's not TOR, it's Tor***
***Also all of the discussions on this list scare me, but that's a
conversation for a different thread

-- 
Tony Arcieri

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Mar 2015 06:30:21 -0500

My personal opinion is that guaranteeing end to end integrity and confidentiality of the channel between the endpoints is a feature of token binding.

Intermediate transport boxes that inspect the content should prevent token binding from being established.

At that point the server can decide if it should use unbound tokens or perhaps not allow the user to even enter credentials because they are being compromised.

I think trying to differentiate between "good" and "bad" Man in the middle is problematic, the bad people will always try to look like the good people.  http://www.motherjones.com/politics/2013/09/flying-pig-nsa-impersonates-google

Don't get me wrong, I happen to think the NSA/GCHQ/CSE is doing a fine job, but they are not the only ones playing this game.

Having a way for a proxy that the end system knows about (perhaps not transparent) also proxy token binding may be reasonable. 
Having a fallback that doesn't use tlsunique and by having a challenge can establish keys over a channel that is not end to end is I think almost a different protocol.  Perhaps worth considering separately, but not something that should be the default.

The trend in the IETF is to not have transparent interception and tampering with TLS connections.

The SPUD https://datatracker.ietf.org/meeting/92/agenda/spud/ session this morning is looking at some of these issues.

John B.

> On Mar 24, 2015, at 7:44 PM, Andrei Popov <[email-masked]> wrote:
>