Re: Signed CSP

If the service operator loses control over their server to a malicious
operator (NSA, GCHQ, bored ex-zf0/PHC/dikline/HTP member, etc), this
contains the compromise to the server. Clients will see that hashes don't
match, or signatures don't match, so decloaking visitors becomes an
incredibly difficult problem. Unless you steal the airgapped signing key as
well.

It solves the problem of "once the FBI gains control over Tor hidden
services, they can implant malware to decloak users". How does TACK + HSTS
stop the feds from identifying clients if they gain complete access to the
correct server with a valid private key?

On Sun, Feb 15, 2015 at 8:48 PM, Crispin Cowan <crispin@microsoft.com>
wrote:

>  What does the Wired article tell us that helps? I get that it is an
> important problem, I just don't see how your proposes addresses that
> problem.
>
> Sent from my Windows Phone
>  ------------------------------
> From: Scott Arciszewski <kobrasrealm@gmail.com>
> Sent: ‎2/‎15/‎2015 2:27 PM
>
> To: Crispin Cowan <crispin@microsoft.com>
> Cc: public-webappsec@w3.org
> Subject: Re: Signed CSP
>
>  http://www.wired.com/2013/09/freedom-hosting-fbi/
>
> On Sun, Feb 15, 2015 at 5:15 PM, Crispin Cowan <crispin@microsoft.com>
> wrote:
>
>>  So the client trusts the offline signing key, but not the server.
>>
>>
>>
>> An attacker can compromise everything about the server, except it’s CSP:
>> JS, content, etc.
>>
>>
>>
>> So the attacker can load this server full of lies and such, but can’t
>> change its CSP. What threats does that defend the client against?
>>
>> ·         This site can’t be XSS’d by another site: don’t care, this
>> site is already completely p0wned.
>>
>> ·         Other sites can’t be XSS’d by this site: I don’t think that
>> this site’s CSP assures that, and don’t really care, the attacker will just
>> XSS you from a different place.
>>
>>
>>
>> So I’m still not seeing a real threat that this really mitigates.
>>
>>
>>
>> *From:* Scott Arciszewski [mailto:kobrasrealm@gmail.com]
>> *Sent:* Sunday, February 15, 2015 1:23 PM
>> *To:* Crispin Cowan
>> *Cc:* public-webappsec@w3.org
>> *Subject:* Re: Signed CSP
>>
>>
>>
>> What value does this proposal deliver, that you do not get by combining
>> HSTS pinning with CSP?
>>
>>
>> The signing key remains offline, so an attacker cannot forge signatures.
>> HSTS + CSP does not achieve this since the SSL private key must remain
>> accessible to the server.
>>
>> The goal here is to disrupt the US government's malware campaigns on the
>> Tor network, but it could also be advantageous against less sophisticated
>> threats.
>>
>> On Sun, Feb 15, 2015 at 3:35 PM, Crispin Cowan <crispin@microsoft.com>
>> wrote:
>>
>>  What value does this proposal deliver, that you do not get by combining
>> HSTS pinning with CSP?
>>
>>
>>
>> In particular, since the threat you are trying to defend against is a
>> compromised server, the most the client can do is ensure that this is still
>> the server you think it is. Even that is dubious, because a compromised
>> server gives the SSL private key to the attacker. Doing more than that
>> would seem to prevent the legitimate site admin from changing policy.
>>
>>
>>
>> *From:* Scott Arciszewski [mailto:kobrasrealm@gmail.com]
>> *Sent:* Sunday, February 15, 2015 7:28 AM
>> *To:* public-webappsec@w3.org
>> *Subject:* Signed CSP
>>
>>
>>
>> I love Content-Security-Policy headers, but I feel that they could do
>> more to protect end-users from malicious Javascript especially if the
>> entire host web server gets compromised and attackers are able to tamper
>> with headers at will.
>>
>>
>>
>> I would like to propose an extension to the Content-Security-Policy
>> specification to mitigate the risk of a hacked server distributing malware,
>> similar to what happened during the Freedom Hosting incident in 2013.
>>
>> The new proposed header looks like this:
>>
>> Signed-Content-Security-Policy: /some_request_uri publicKeyA,
>> [publicKeyB, ... ]
>>
>> WHEREBY:
>> --------
>>
>> * /some_request_uri is a message signed with one of the public keys
>> specified in the header
>>
>> * /some_request_uri contains a full CSP definition with one caveat:
>> hashes of script src files are required!
>>
>> * The proposed signing mechanism is EdDSA, possibly Ed25519 (depending on
>> CFRG's final recommendation to the TLS working group)
>>
>> * At least one public key is required, but multiple are allowed (more on
>> this below)
>>
>> With this mechanism in place on the client and the server, if you were to
>> compromise a server (say, a Tor Hidden Service), you would not be able to
>> tamper with the Javascript to deliver malware onto the client machines
>> without access to the EdDSA secret key (or a hash collision in the CSP
>> definition) or fooling the client into accepting a bad public key.
>>
>> Server Implementation:
>>
>>
>>
>> Let's say I wish to publish a Tor Hidden Service that hosts, say, the
>> unredacted Snowden files. These are the steps I would need to take to
>> prevent malware deployment:
>>
>> 1. Generate N EdDSA secret/public key pairs (N > 2).
>>
>> 2. Put all of the public keys in the SCSP header.
>>
>> 3. Use only one secret key for signing from an airgapped machine whenever
>> a website update is required. The rest should remain on encrypted thumb
>> drives which are in hidden caches.
>>
>> Client Implementation:
>>
>> Upon accessing a website with a CSP header, render the fingerprints and
>> ask the user if they trust this series of hexits. If someone attempts to
>> add/replace any of the public keys, immediately disable Javascript and
>> panic to the user. This is basically SSH model of trust, but in the event
>> of a signing key compromise, the other keys can be used and the untrusted
>> public key can be removed without causing a ruckus to the end user.
>>
>> Users' trust decisions should be stored in a separate file than cert8.db,
>> and users should be able to tell their browser where to store it. In
>> "private browsing" modes, this file should be cloned into memory and never
>> written back to disk without explicit user action (e.g. for Tor Browser
>> Bundle users).
>>
>>
>>
>> This is obviously a very rough draft, but I would love to get feedback on
>> it and, if everyone approves, move forward with developing it into
>> something greater. (Browser extension? Internet Standard? Not my place to
>> say :)
>>
>> Scott Arciszewski
>>
>>
>>
>
>