Re: [websec] HSTS Hole Punching

Yoav Nir <ynir@checkpoint.com> Wed, 16 January 2013 07:11 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150CA21F8839 for <websec@ietfa.amsl.com>; Tue, 15 Jan 2013 23:11:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.492
X-Spam-Level:
X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryvSyIdabmQf for <websec@ietfa.amsl.com>; Tue, 15 Jan 2013 23:11:02 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF421F882C for <websec@ietf.org>; Tue, 15 Jan 2013 23:11:01 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0G7Amjg006061; Wed, 16 Jan 2013 09:10:52 +0200
X-CheckPoint: {50F64FF7-1-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Wed, 16 Jan 2013 09:10:48 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: tav <tav@espians.com>
Thread-Topic: [websec] HSTS Hole Punching
Thread-Index: AQHN83PXECiDiGlZPEC12SVPh4OWp5hLZ8IA
Date: Wed, 16 Jan 2013 07:10:47 +0000
Message-ID: <4613980CFC78314ABFD7F85CC30277211198598D@IL-EX10.ad.checkpoint.com>
References: <CAJThFW4vBWUEA3ZC1FQ25vdJC95cFgsFs2Z=6rAJNdfUWowJ8w@mail.gmail.com>
In-Reply-To: <CAJThFW4vBWUEA3ZC1FQ25vdJC95cFgsFs2Z=6rAJNdfUWowJ8w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.157]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <83BE1F81DBF0164A98C9437D71F9FAA6@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<websec@ietf.org>" <websec@ietf.org>
Subject: Re: [websec] HSTS Hole Punching
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jan 2013 07:11:04 -0000

Hi tav

It's not just late in the process. The process is pretty much over. What you are proposing could be either an extension to HSTS, or a revision to HSTS.

Furthermore, support of HSTS is not negotiated: the server just sends the header, and the client either parses it or ignores it. There's no version negotiation. So suppose your server sends the header that you propose, there are three possible outcomes:
 1. The client is old, and ignores HSTS
 2. The client is current, registers HSTS, but ignores the exclusion
 3. The client supports your extension.

#1 and #3 are OK, but #2 (which is most of the desktop browsers in use today), means that either from.espra.com will have STS applied (bad) or that none of the subdomains will have STS (if you drop the includeSubDomains keyword - somewhat bad)

As a practical matter, this is one case where backwards compatibility will cause you a lot of grief, unless you try to identify supporting implementations by user agent string. 

I guess the best thing would be to avoid the includeSubdomains keyword, and just have an HSTS header for each of the servers except for from.espra.com

Yoav


On Jan 16, 2013, at 12:57 AM, tav <tav@espians.com> wrote:

> Hi there,
> 
> I realise that this proposal might be rather late in the process, but
> would it be possible to add a list of excluded subdomains in the STS
> header?
> 
> My use case is that I am setting up a new service which has the STS
> header set so that users might have a more secure experience. However,
> for the purposes of sending referrer path information to non-HTTPS
> sites, I have one subdomain which does redirects over plain HTTP, e.g.
> http://from.espra.com/some/referrer/path.
> 
> In an ideal world, I would be able to set a comprehensive STS header
> which excluded just that one subdomain, e.g.
> 
>  Strict-Transport-Security: max-age=31536000; includeSubDomains;
> exclude=from.espra.com
> 
> And since having an exclude implicitly suggests includeSubdomains, it
> could be shortened to just:
> 
>  Strict-Transport-Security: max-age=31536000; exclude=from.espra.com
> 
> There are, of course, alternative solutions, e.g. using another domain
> for the HTTP redirect or setting STS on individual subdomains without
> specifying includeSubdomains. But this seems like it would be a more
> elegant and secure solution.
> 
> Thank you for your time!
> 
> -- 
> All the best, tav
> 
> plex:espians/tav | tav@espians.com | +44 (0) 7809 569 369
> http://tav.espians.com | http://twitter.com/tav | skype:tavespian
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
> 
> Email secured by Check Point