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

Kai Engert <kaie@kuix.de> Mon, 19 July 2010 07:49 UTC

Return-Path: <kaie@kuix.de>
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 8DE3C3A6843 for <hasmat@core3.amsl.com>; Mon, 19 Jul 2010 00:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VF4cRDlMkqEh for <hasmat@core3.amsl.com>; Mon, 19 Jul 2010 00:49:47 -0700 (PDT)
Received: from s15277822.onlinehome-server.info (s15277822.onlinehome-server.info [87.106.189.147]) by core3.amsl.com (Postfix) with ESMTP id 80E4E3A68BD for <hasmat@ietf.org>; Mon, 19 Jul 2010 00:49:31 -0700 (PDT)
Received: from [192.168.2.11] (p4FF35C55.dip.t-dialin.net [79.243.92.85]) by s15277822.onlinehome-server.info (Postfix) with ESMTPSA id 88BCB56E97E; Mon, 19 Jul 2010 09:49:44 +0200 (CEST)
Message-ID: <4C440397.3030904@kuix.de>
Date: Mon, 19 Jul 2010 09:49:43 +0200
From: Kai Engert <kaie@kuix.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100626 Remi/fc13 Lightning/1.0b2pre Thunderbird/3.1
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <4C40B0F7.4010008@KingsMountain.com> <AANLkTiknk-L7XalNxfNZdWQuxH9HmrWM8vRsJO1jsDuq@mail.gmail.com>
In-Reply-To: <AANLkTiknk-L7XalNxfNZdWQuxH9HmrWM8vRsJO1jsDuq@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000807080002030204040009"
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 07:49:52 -0000

  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?

Thanks,
Kai