Re: [HASMAT] wrt port numbers - comment 51 bug 495115 (bugzilla.mozilla.org)

Adam Barth <ietf@adambarth.com> Mon, 19 July 2010 09:08 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: hasmat@core3.amsl.com
Delivered-To: hasmat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A973A69FD for <hasmat@core3.amsl.com>; Mon, 19 Jul 2010 02:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVBDqOmzLWck for <hasmat@core3.amsl.com>; Mon, 19 Jul 2010 02:08:10 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 229183A68E9 for <hasmat@ietf.org>; Mon, 19 Jul 2010 02:08:08 -0700 (PDT)
Received: by iwn38 with SMTP id 38so4860438iwn.31 for <hasmat@ietf.org>; Mon, 19 Jul 2010 02:08:22 -0700 (PDT)
Received: by 10.42.36.132 with SMTP id u4mr1614877icd.82.1279530502265; Mon, 19 Jul 2010 02:08:22 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id e8sm24333269ibb.20.2010.07.19.02.08.20 (version=SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 02:08:21 -0700 (PDT)
Received: by iwn38 with SMTP id 38so4860410iwn.31 for <hasmat@ietf.org>; Mon, 19 Jul 2010 02:08:20 -0700 (PDT)
Received: by 10.231.193.135 with SMTP id du7mr3892288ibb.176.1279530500266; Mon, 19 Jul 2010 02:08:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.143.145 with HTTP; Mon, 19 Jul 2010 02:08:00 -0700 (PDT)
In-Reply-To: <4C440397.3030904@kuix.de>
References: <4C40B0F7.4010008@KingsMountain.com> <AANLkTiknk-L7XalNxfNZdWQuxH9HmrWM8vRsJO1jsDuq@mail.gmail.com> <4C440397.3030904@kuix.de>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 19 Jul 2010 02:08:00 -0700
Message-ID: <AANLkTintbghCc-fn3XfMVi6ZZbPqyI5lMg7b-uO20cv6@mail.gmail.com>
To: Kai Engert <kaie@kuix.de>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IETF HASMAT list <hasmat@ietf.org>
Subject: Re: [HASMAT] wrt port numbers - comment 51 bug 495115 (bugzilla.mozilla.org)
X-BeenThere: hasmat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <hasmat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hasmat>
List-Post: <mailto:hasmat@ietf.org>
List-Help: <mailto:hasmat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jul 2010 09:08:18 -0000

On Mon, Jul 19, 2010 at 12:49 AM, Kai Engert <kaie@kuix.de> wrote:
> On 17.07.2010 02:29, Adam Barth wrote:
> Here's the response I gave on the bug:
>
> [[
> With respect to port numbers, I think that's not well covered in the spec.
> The
> way it works in chrome is that the STS state is for the whole host (this is
> important to protect secure cookies, which are shared by the whole host).
> For
> the redirect behavior: port numbers are preserved except port 80 is changed
> to
> port 443 because 80 is the default port for http.
> ]]
>
> If you want to keep it simple, and only address the standard configuration,
> my
> proposal is:
>
> - restrict the redirection to http requests that go to port 80
>
> That's not a good idea.  It's an importnat security property that the
> browser never issues an HTTP request for hosts with STS enabled.  The
> reasons for this are somewhat subtle and revolve around deficiencies
> in the cookie protocol.  Essentially, because cookies do not have
> integrity, you want to rule out the possibility of an active network
> attacker responding to such requests with a Set-Cookie header.
>
> Another way of thinking about the situation is as follows:
>
> 1) An STS server is promising never to use HTTP or send broken certificates.
> 2) If we're trying to issue an HTTP request to example.com:8080, then
> that's not what example.com wants and we shouldn't do it.
>
> Adam
>
> Let me try to summarize your proposed behaviour:
>
> plain http is forbidden for all ports on a known HSTS host
> (it's not possible to run any additional http services on a known HSTS host,
> because HSTS-compliant browsers are expected to never connect to it)
> a browser is expected to catch http://host:80 requests and transfer them
> into https://host:443
> http to any port other than 80 gets changed into https to the same port
> number, e.g. the browser must change requests to http://host:81 into
> requests for https://host:81
>
> Is my understanding right?

Yes, precisely.

Adam