RE: Signed CSP

I don’t see how CSP helps as a place to start. Suppose you create a perfect PKI that lets clients recognize sever CSPs that are “in the club” (no easy feat in itself). That only prevents the attacker who p0wns the server from changing the CSP, it does not stop them from changing all the rest of the content, which can have quite bad effects on the user.

Even if it prevents the attacker from *changing* the CSP, it does not prevent them from *deleting* it. If the CSP is an obstacle for the attacker, they will just remove it.

So instead of delving into mechanism just yet, what semantics are you trying to achieve? A threat model that assumes a compromised server is very challenging to get right.

From: Scott Arciszewski [mailto:kobrasrealm@gmail.com]
Sent: Sunday, February 15, 2015 6:15 PM
To: Michal Zalewski
Cc: Crispin Cowan; public-webappsec@w3.org
Subject: Re: Signed CSP

> CSP is probably not the right place to solve it.
Fair point. I was using this as a starting point because it seemed like a logical place to begin.

> You'd probably just want a signature attached as an extra HTTP header or so, with a browser add-on plugging into the HTTP stack and taking care of the validation steps.
By this, I assume you mean the whole meta idea of verifying the script hashes and whitelisting redirects (an idea I hadn't considered)?
What would we even call this then, if it's not to be tied in with CSPs?

On Sun, Feb 15, 2015 at 9:10 PM, Michal Zalewski <lcamtuf@coredump.cx<mailto:lcamtuf@coredump.cx>> wrote:
So your model is to have a manually curated whitelist of trusted keys;
and then use a browser that refuses to load any Internet content at
all unless it is signed with one of these (hopefully offline) keys?

The "can't navigate anywhere else" seems like a prerequisite, because
otherwise, what stops pwn3d.com<http://pwn3d.com> from just a 30x redirect to evil.com<http://evil.com>,
and letting evil.com<http://evil.com> do any fingerprinting / decloaking it wants? (In
fact, for optimal safety, you'd probably want a whitelist of keys
*and* of navigable origins).

This seems like an incredibly narrow / impractical use case, with a
whole lot of new browser logic to tackle on, and even then, CSP is
probably not the right place to solve it. You'd probably just want a
signature attached as an extra HTTP header or so, with a browser
add-on plugging into the HTTP stack and taking care of the validation
steps.

/mz