Re: [WEB SECURITY] Strict-Transport-Security on https://www.paypal.com

[Andy Steingruebl <steingra@xxxxxxxxx>]

On Sat, Nov 7, 2009 at 8:33 AM, Bil Corry <bil@xxxxxxxxx> wrote:
> 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?

We're trying to keep much of the public discussion about this on the
public-webapps mailing list, but I don't mind replying here.  On
Monday I might cross-post some of this there when I get a chance...

We've been mulling this over a lot actually.  The goal of course is to
make sure that the entry is still in a user's cache next time they
come to visit your site so that the bootstrapping of their original
connection is effective long term.  So, you're right that just setting
this to a long value would probably do the trick.  There are a few
considerations on this though, especially if a few of the proposed
features such as LockCA get added.  In that case you wouldn't
necessarily want the max-age to be longer than your existing
certificate lifetime, just in case you wanted to change CA's.  For
some people they won't worry about that (I don't) but other folks do
switch CAs periodically, so that is a concern.

Though we don't have an official answer, I think I'll probably settle
on something like 1 year or so for max-age, though my colleagues might
talk me out of it for good reasons :)


> (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.

I'll let Jeff weigh in on whether we want these items in the spec.  We
do not however expect that most sites that deploy STS will go back to
HTTP and stop using HTTPS.

> 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?

I think there is a subtle nuance here but essentially it should kill
the cache and immediately revert to non-STS behavior.  Links are only
converted at the time of dereference, so an HTTP link on a page for a
site with STS that just got its status cleared would dereference as
HTTP.

> 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?

We expect this to be a browser implementation issue. The specification
doesn't say there is a max limit.

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

This will probably be in an updated version of the spec as Eric
Lawrence asked the same question.  We expect the last value would
prevail.  We could also specify that this is non-conformant, but
probably won't because of how people will likely implement this in
practice.

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

It is effective on every non-error code message regardless of
content-type.  Since the browser caches the response it doesn't need
to be on every reply, but it can be.

> 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]?

A server should always redirect its HTTP traffic to HTTPS to really
make this effective.  Most sites that want to implement HTTPS only do
this right now.  There is not currently a way to identify STS-enabled
clients.  An STS client though should never make a request to HTTP
though once it has the status cached.

> [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

So, nothing about STS says that people can't muck up their
certificates.  This is still a logistical issue for a site regardless
of STS.  Though, STS is a little stricter and will not allow a user to
override the certificate warnings for a site with a cached STS status.
 So, it does raise the bar operationally.

> [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

Well, I'm not entirely sure I agree with this as  it isn't clear its a
security issue vs. a usability issue, but I'll have to take that up
with the authors of the TLS cheat sheet.

-- 
Andy Steingruebl
steingra@xxxxxxxxx

----------------------------------------------------------------------------
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