[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Strict-Transport-Security on https://www.paypal.com
- From: Bil Corry <bil@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] Strict-Transport-Security on https://www.paypal.com
- Date: Sat, 07 Nov 2009 08:33:20 -0800
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 depending 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 problematic 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 been revoked, the site's only choice would be to quickly replace the existing revoked cert with a new one (which they shoul
d anyhow). It may be worthwhile to more explicitly call out these issues in the 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, might an attacker with a large number of domains be able to facilitate a 'STS eviction' 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 sites 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 don't believe there is), then given the STS requirement that a server should redirect 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]?
Apologies if any of this is already covered in the specification. And if there is a better forum to discuss this, then please let me know.
- Bil
[1] American Express used revoked site certificate for weeks
http://my.opera.com/yngve/blog/2009/10/01/american-express-used-revoked-site-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
----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA
Brought to you by http://www.webappsec.org
Search this site
|