Subject: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies

From: Brian Campbell <[email-masked]>
Date: Fri, 14 Jul 2017 10:59:21 -0600

Just a not-so-subtle reminder that HTTPS Token Binding with TLS Terminating
Reverse Proxies is one of the agenda items for Monday's meeting in Prague
and it would be great if there was some familiarity with it going into the
meeting. It's relativity short as drafts go, if you're looking for
something to read en route to the meeting: https://tools.ietf.org/html/
draft-campbell-tokbind-ttrp-00

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 15 Jul 2017 09:23:52 +1200

On 15/07/17 04:59, Brian Campbell wrote:
> Just a not-so-subtle reminder that HTTPS Token Binding with TLS 
> Terminating Reverse Proxies is one of the agenda items for Monday's 
> meeting in Prague and it would be great if there was some familiarity 
> with it going into the meeting. It's relativity short as drafts go, if 
> you're looking for something to read en route to the meeting: 
> https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 
> <https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00>
> 

I wont be at the meeting. But reviewing anyway.

Several of the processing requirements in section 2.2 appear to be 
re-inventing already existing HTTP mechanisms without referencing them, 
nor integrating with them to support proxies that only implement HTTP - 
not TB.

Firstly;

Section 2.2 bullet item #1 places a normative MUST requirement on 
removing "Sec-Token-Binding" header from the clients request when 
forwarding.

Since the TLS connection is one "hop" this duplicates HTTP hop-by-hop 
header requirements. Such headers are governed by RFC 7230 section 6.1 
and required (also a normative MUST) to be listed in the HTTP Connection 
header by the sender. Such that even if the receiving proxy is not 
implementing this specification, it will still fail-safe by removing the 
header.

Secondly;

Section 2.2 bullet item #4 and the paragraph following it define the 
same behaviour for the "Provided-Token-Binding-ID" and 
"Referred-Token-Binding-ID" headers.

These two are not such a clear case of hop-by-hop since without the TLS 
there is the possibility of other hops between reverse-proxy and origin 
server. I believe it still worth at least referencing the HTTP 
Connection header as something that SHOULD be used to improve secure 
behaviour for messages containing those headers - the exception being 
when there are known to be multiple HTTP hops within the backend network.

NP: I know the TLS layer should be negotiating use of TB, so the sender 
"knows" the recipient implements this draft. But there is a possibility 
of the TLS decryption being done by other software than the HTTP 
processing, or opaquely relayed by an agent that negotiates TB, while 
the HTTP is processed by a proxy that does not support it. Use of the 
HTTP Connection header ensure the TB security is maintained even in 
those type of misconfiguration scenarios.

AYJ

---

From: Brian Campbell <[email-masked]>
Date: Fri, 14 Jul 2017 16:06:57 -0600

The "Sec-Token-Binding" header is defined in
https://tools.ietf.org/html/draft-ietf-tokbind-https and the WG decided not
to list "Sec-Token-Binding" in the Connection header field in that
document. https://mailarchive.ietf.org/arch/search/?email_list=
unbearable&q=%22on+not+listing+%27Sec-Token-Binding%
27+in+the+Connection+header+field%3F%22 will turn up at least some of that
discussion. It wouldn't make sense for this draft to require different
behavior of the client. Especially when the client won't know (and
shouldn't know) if it's talking to a reverse proxy or not.

"Provided-Token-Binding-ID" and "Referred-Token-Binding-ID" are not
hop-by-hop. They are providing info from the TTRP to the backend, whatever
that backend is. And the backend may involve additional layers of proxies
or it may not. But that's beyond the scope of this document.

On Fri, Jul 14, 2017 at 3:23 PM, Amos Jeffries <[email-masked]> wrote:

>> Terminating Reverse Proxies is one of the agenda items for Monday's meeting
>> in Prague and it would be great if there was some familiarity with it going
>> into the meeting. It's relativity short as drafts go, if you're looking for
>> something to read en route to the meeting: https://tools.ietf.org/html/dr
>> aft-campbell-tokbind-ttrp-00 <https://tools.ietf.org/html/d
>> raft-campbell-tokbind-ttrp-00>
>>
>>
> re-inventing already existing HTTP mechanisms without referencing them, nor
> integrating with them to support proxies that only implement HTTP - not TB.
>
>
> Firstly;
>
> Section 2.2 bullet item #1 places a normative MUST requirement on removing
> "Sec-Token-Binding" header from the clients request when forwarding.
>
> header requirements. Such headers are governed by RFC 7230 section 6.1 and
> required (also a normative MUST) to be listed in the HTTP Connection header
> by the sender. Such that even if the receiving proxy is not implementing
> this specification, it will still fail-safe by removing the header.
>
>
> Secondly;
>
> Section 2.2 bullet item #4 and the paragraph following it define the same
> behaviour for the "Provided-Token-Binding-ID" and
> server. I believe it still worth at least referencing the HTTP Connection
> header as something that SHOULD be used to improve secure behaviour for
> messages containing those headers - the exception being when there are
> known to be multiple HTTP hops within the backend network.
>
>
>
> "knows" the recipient implements this draft. But there is a possibility of
> the TLS decryption being done by other software than the HTTP processing,
> or opaquely relayed by an agent that negotiates TB, while the HTTP is
> processed by a proxy that does not support it. Use of the HTTP Connection
> header ensure the TB security is maintained even in those type of
> misconfiguration scenarios.
>
> AYJ
>

---

From: Piotr Sikora <[email-masked]>
Date: Mon, 17 Jul 2017 12:37:56 +0200

Hey Brian,
looks good, thanks for working on that!

One question:

>   Reverse proxies SHOULD only add the headers to requests that are
>   forwarded to trusted backend servers.

Why? What's the attack vector, security and/or privacy implications here?

Best regards,
Piotr Sikora

On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell
<[email-masked]> wrote:
> meeting. It's relativity short as drafts go, if you're looking for something
> to read en route to the meeting:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> computer. Thank you.
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 17 Jul 2017 12:53:30 +0200

To be honest, I didn't have a specific attack vector or security/privacy
implication in mind around that. It just seemed like something that should
generally be part of reverse proxy set up. Do you think it's too
restrictive/perspective? Or do you know of some use-case where a reverse
proxy wouldn't know/trust the servers that it sits in front of?

On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora <[email-masked]>
wrote:

> Terminating
> something

---

From: Piotr Sikora <[email-masked]>
Date: Mon, 17 Jul 2017 13:18:02 +0200

Hey Brian,
from the CDN point of view, all backend servers are untrusted, but I
don't see any reason why CDNs shouldn't forward
Provided-Token-Binding-ID to the origin servers.

Also, Token Binding is supposed to protect Cookies (among other
things), which don't have such restriction, so this seems unnecessary.

Best regards,
Piotr Sikora

---

From: Brian Campbell <[email-masked]>
Date: Mon, 17 Jul 2017 14:29:40 +0200

For any given domain, a CDN would know the origin server(s) where it should
forward requests it cannot fulfill, right?

That's what I was trying to get at in the statement in the draft - that the
reverse proxy only dispatch requests to origin sever(s) known/configured to
be associated with the domain of the original request. Perhaps "trust"
isn't the right word and that sentence can be reworded to be more
reflective of that? Or is such a restriction/requirement so implicit in the
deployment of any reverse proxy so doesn't need any treatment in this
document?

---

From: Piotr Sikora <[email-masked]>
Date: Mon, 17 Jul 2017 15:35:11 +0200

Well, it's kind of given that requests are sent only to backends that
are configured for a particular domain. That applies to whole
requests, and not only to Provided-Token-Binding-ID header, so I think
this is unnecessary restriction that will only confuse readers.

Best regards,
Piotr Sikora

On Mon, Jul 17, 2017 at 2:29 PM, Brian Campbell
<[email-masked]> wrote:
> be associated with the domain of the original request. Perhaps "trust" isn't
> the right word and that sentence can be reworded to be more reflective of
> that? Or is such a restriction/requirement so implicit in the deployment of
> any reverse proxy so doesn't need any treatment in this document?
>
>> >> > and it would be great if there was some familiarity with it going
>> >> > into
>> >> > the

---

From: Brian Campbell <[email-masked]>
Date: Tue, 18 Jul 2017 07:16:59 +0200

Fair enough. I'll plan to remove the sentence in a future draft.

Thanks for the review and feedback, Piotr.

On Mon, Jul 17, 2017 at 3:35 PM, Piotr Sikora <[email-masked]>
wrote:

> isn't
> >> >> > distribution or disclosure by others is strictly prohibited.  If
> you
> >> >> > have