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

[Adam Barth <[e-mail]>]

On Sat, Jul 17, 2010 at 12:35 PM, Steingruebl, Andy
<[e-mail]> wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Adam Barth
>> > It seems to me that this should be fixed by STS. Would something like
>> > 'once STS is enabled a STS server shouldn't allow HTTP to set secure
>> > cookies' (in better language) be enough? I am not really sure what are
>> > the attacks you are referring to.
>>
>> That's already true because the browser never issues HTTP requests to an
>> STS host and therefore can never receive an HTTP response containing a Set-
>> Cookie header.
>>
>> More generally, there are tons of random semantics we could layer onto the
>> STS bit.  However, that leads to a complex feature that's hard for sites to
>> reason about and deploy.  Instead, it's better to stick with a couple hard-
>> working primitives, which is what the current design aims for.
>
> Ok, I feel like I'm making a day of contradicting Adam, but one of the points of the HASMAT work is to see what other policy directives we can come up with, and they bestway to turn some of that into policy mechanisms.
>
> Lots of things are currently out there scattered all over:
>
> X-Frame-Options
> CSP
> STS
> No-Sniff
> And even headers to turn off XSS sanitization features in browsers for a given site.
>
> What we're hoping to do through some of the HASMAT work is condense a lot of that into a more coherent policy mechanism, and add a few things  (and I'm just brainstorming here).  Ideally these policies could be controlled in one place and wouldn't have to get set for every response by a site, they could be centrally controlled and authoritative.
>
>  - This site only sets "Secure" and "HTTPonly" cookies. Don't pay attention to the individual cookies, this policy statement is authoritative
>  - This site is always UTF-8. Don't ever sniff content here.
>  - This site should never be framed, or only framed under these conditions.

Oh, I agree with that.  I guess what I meant was we'd be better off
having more dials to turn, each of which does something clear and
understandable, rather than having a big on/off switch that does
something complicated and mysterious.

For example, in the original ForceHTTPS proposal, we had "I don't want
mixed content" layered on as well.  We took that out because we
thought it made sense to be able to control that piece of policy
independently.

Adam