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

Brian Campbell <> Fri, 14 July 2017 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D02012EC2B for <>; Fri, 14 Jul 2017 15:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ihU29YOaf29p for <>; Fri, 14 Jul 2017 15:07:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA7DD12EC57 for <>; Fri, 14 Jul 2017 15:07:29 -0700 (PDT)
Received: by with SMTP id e7so51201718pfk.0 for <>; Fri, 14 Jul 2017 15:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yaws0+tlzmQhK3CXQVCNsFSBxUn644e3SdXdCxPg+lc=; b=bLtu1fhf3RFyiOmAhvXJ07sXvJZA9M3xlz6A5tHx9m8m1H8tNRIwVJ46CBkA59nIqB CYFNozXV/TxrDzBJqCcwZFzbXcAVa46xRXjeX5p56u8WV732Jr+USCPtanzwCaz0P6oP Ubm1oojvE4yN3IC2+w0i8dy6rPvGf8zFEHEHY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yaws0+tlzmQhK3CXQVCNsFSBxUn644e3SdXdCxPg+lc=; b=UQsbulGoZyzZrXWLSA0/dQGjH1lzGLJer7KvFf+hwuBPZZt8L+VWTtyAvsJR84GiW6 KYEfpJEBeRXWShgBSHLNzL+DcsEJeqml+lIVJ+Ot2auEMyQZftBQwjblLWzmXewImspx njSsvr/JmTt9pfAYzchHI4ypZVJ6gZieRP9/n7cP9zrbsT94Q75qPUWeT7M3Hf2LwRb1 ZwFT7szs344Zlj/eU/TsGx1gQ57NKdrPEUXXcykYdEG9LlMk5G+75Lk/fon3Z6th8Pdg nZSUTpwdLqC0xvPkpk5KMfOzovtGnIu5cLkIWAmK0anCRNvPLieAvWpQng6H04wt28bf RPYw==
X-Gm-Message-State: AIVw113Dy5DjFdQ3o6Rrc134eWAm7IiVH0o1xlOAxljIib0k5uIOFrk5 JbVmCvQLDxsw17segWvzL47U480WKvvHmKZmPs4tqx3zdKcmbJuvElMmPmXzZ6zL3S0fIjcdLQe 01Pn8IN1AYbdnug==
X-Received: by with SMTP id s15mr18596996plk.100.1500070049323; Fri, 14 Jul 2017 15:07:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Jul 2017 15:06:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Fri, 14 Jul 2017 16:06:57 -0600
Message-ID: <>
To: Amos Jeffries <>
Cc: IETF Tokbind WG <>
Content-Type: multipart/alternative; boundary="94eb2c1ceb7e6dbd8905544e464c"
Archived-At: <>
Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jul 2017 22:07:32 -0000

The "Sec-Token-Binding" header is defined in and the WG decided not
to list "Sec-Token-Binding" in the Connection header field in that
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 <> wrote:

> 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:
>> aft-campbell-tokbind-ttrp-00 <
>> raft-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.

*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.*