W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Bil's comment thread wrt Strict Transport Security (STS)

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Tue, 08 Dec 2009 13:31:23 -0800
Message-ID: <4B1EC5AB.20107@KingsMountain.com>
To: W3C Web Security Interest Group <public-web-security@w3.org>
------- Forwarded Messages

Date:    Sun, 08 Nov 2009 21:42:18 -0800
From:    Bil Corry <bil@corry.biz>
To:      "Hodges, Jeff" <jeff.hodges@paypal.com>
cc:      public-webapps@w3.org, Collin Jackson <collin.jackson@sv.cmu.edu>,
	 abarth@eecs.berkeley.edu, Andy Steingruebl <steingra@gmail.com>
Subject: Re: fyi: Strict Transport Security specification

Hodges, Jeff wrote on 9/18/2009 3:21 PM:
 > We wish to bring the following draft specification to your attention..
 >
 >    Strict Transport Security (STS)
 > <http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodge
s-strict-transport-sec-05.plain.html>
[...snip...]
 > We're looking forward to the WebApps WG's feedback and comments.

I responded to an announcement on the WASC list[3], but am posting it again her
e as I was told this was the relevant forum to do so.

Andy Steingruebl wrote on 11/6/2009 1:53 PM:
 > > 2. We've launched with a very small max-age parameter for testing
 > > purposes.  We expect that after more extensive testing we will deploy
 > > with a much larger max-age value to provide more robust protection for
 > > users.

What max-age value does PayPal expect to use in the future once your testing is
  complete?  I'm curious if there's a recommended value, or if it varies dependi
ng on the risk-model of the site.  Since the specification allows the value to
be updated in subsequent headers, is there any downside to making it very large
  (e.g. 10 years)?  Even if the site's certificate expires or is revoked, couldn
't the site then immediately expire STS if they want users to be able to still
use the site (foolish, but it happens[1])?  Oh, that wouldn't work because STS
headers are only sent over HTTPS, and if STS prevents loading a site with a pro
blematic cert, the site wouldn't be able to communicate a different expiration.
   Now I understand the note in the specification about considering expiring STS
  to coincide with the expiration of the cert.  In the case where a cert has bee
n revoked, the site's only choice would be to quickly replace the existing revo
ked cert with a new one (which they shoul

d anyhow).  It may be worthwhile to more explicitly call out these issues in th
e specification, or perhaps a separate implementation considerations document.

Thinking more about immediately expiring STS, what is the STS behavior when max
- -age is set to 0 or a negative number?  Is it immediately disabled, or disabled
  on subsequent visits to the site?

Is there a maximum number of cached entries for known STS servers?  If so, migh
t an attacker with a large number of domains be able to facilitate a 'STS evict
ion' attack?  If not, might an attacker be able to fill the cache with lots of
bogus entries, either causing a performance issue when looking up legitimate si
tes or perhaps consuming large quantity of drive space?

What happens where there is more than one STS header?  Which one prevails?

Is the STS header sent on every response (e.g. responses for html, images, css,
  etc)?  Or just for html?

How does the server identify the STS clients?  If there isn't a way (which I do
n't believe there is), then given the STS requirement that a server should redi
rect from non-HTTPS to HTTPS, what does that mean for UAs that don't understand
  STS -- does the best practice of not redirecting to HTTPS still apply[2]?

- - Bil


[1] American Express used revoked site certificate for weeks
     http://my.opera.com/yngve/blog/2009/10/01/american-express-used-revoked-sit
e-certificate-for-weeks

[2] OWASP: Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login Page
     http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_
- -_Do_Not_Perform_Redirects_from_Non-TLS_Page_to_TLS_Login_Page

[3] http://www.webappsec.org/lists/websecurity/archive/2009-11/msg00005.html



------- Message 2

Date:    Sun, 08 Nov 2009 23:06:26 -0800
From:    Collin Jackson <collin.jackson@sv.cmu.edu>
To:      Bil Corry <bil@corry.biz>
cc:      "Hodges, Jeff" <jeff.hodges@paypal.com>, public-webapps@w3.org, abarth
	  @eecs.berkeley.edu,
	 Andy Steingruebl <steingra@gmail.com>
Subject: Re: fyi: Strict Transport Security specification

On Sun, Nov 8, 2009 at 9:42 PM, Bil Corry <bil@corry.biz> wrote:
 > How does the server identify the STS clients?  If there isn't a way (whic=
h I don't believe there is), then given the STS requirement that a server s=
hould redirect from non-HTTPS to HTTPS, what does that mean for UAs that do=
n't understand STS -- does the best practice of not redirecting to HTTPS st=
ill apply[2]?
 >
 > [2] OWASP: Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login=
  Page
 >    http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#=
Rule_-_Do_Not_Perform_Redirects_from_Non-TLS_Page_to_TLS_Login_Page

It seems like a stretch to call this a "best practice" since it is so
rarely followed. What major web sites follow this practice?


------- Message 3

Date:    Mon, 09 Nov 2009 23:14:21 -0800
From:    Bil Corry <bil@corry.biz>
To:      Collin Jackson <collin.jackson@sv.cmu.edu>
cc:      "Hodges, Jeff" <jeff.hodges@paypal.com>, public-webapps@w3.org,
	 abarth@eecs.berkeley.edu, Andy Steingruebl <steingra@gmail.com>
Subject: Re: fyi: Strict Transport Security specification

Collin Jackson wrote on 11/8/2009 11:06 PM:
 > On Sun, Nov 8, 2009 at 9:42 PM, Bil Corry <bil@corry.biz> wrote:
 >> How does the server identify the STS clients?  If there isn't a way (which I
  don't believe there is), then given the STS requirement that a server should r
edirect from non-HTTPS to HTTPS, what does that mean for UAs that don't underst
and STS -- does the best practice of not redirecting to HTTPS still apply[2]?
 >>
 >> [2] OWASP: Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login Pa
ge
 >>    http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rul
e_-_Do_Not_Perform_Redirects_from_Non-TLS_Page_to_TLS_Login_Page
 >
 > It seems like a stretch to call this a "best practice" since it is so
 > rarely followed. What major web sites follow this practice?

I'm unattached to the label "best practice" -- consider my question changed to:

	"Does OWASP's recommendation of not redirecting to HTTPS still apply?"

Andy did respond to the above question and the rest here:

	http://www.webappsec.org/lists/websecurity/archive/2009-11/msg00008.htm
l


- - Bil



------- End of Forwarded Messages
Received on Tuesday, 8 December 2009 21:31:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:01 GMT