Cryptographic same origin policy

Using DNSSEC/DANE to protect your Javascript application against the
threat of CSRF and CSS.

Old fashioned Same Origin Policy

Currently, browsers use the protocol, domain name and port number as a
way to tell origins apart. It is used to tell browsers that some
disjount group of servers belong to the same trust domain.

In simple language: It tells the browser which servers belong to my
web site and all other servers are ‘some one else’. The browser can
tell which javascript is served by me and which is not. The browser
can decide to treat these two classes with different trust levels. It
can run my javascript and disallow that from other trust domains.

But it is based upon domain names. And these have been proven to be
unreliable.

The Cryptograhic Same Origin Policy has the same goal, to tell trust
domains apart but it deploys DSNSEC with DANE and web server
certificates to do so.

Cryptograhic Same Origin Policy

The Cryptograhic Same Origin Policy (CSOP) uses the new DNSSEC and
DANE protocol. It also uses server certificates (HTTPS). However,
these certificates are not signed by the current bunch of global
CAs.

Instead the server certificates are signed by the site’s own
CA. This is called First Party CA. (FPCA).

First Party CA

The site owner runs his own Certificate Authority. He signs all the
server certificates of the servers that are under his direct control,
i.e. where he has the say over the contents of the sites.

He MUST only sign his own server certificates. It MUST NOT sign any other
server certificate.

The Root Certificate of the FPCA is what the server certificates have
in common. This root certicate has become the identity of the servers.

It allows browser to validate the root certificates of each resource
on the page and assign trust domains on the root certificates. Notice:
Browsers MUST only trust First Party CAs. Browsers MUST NOT assume a
trust domain for server certificates signed by global CAs. We solve
that with DANE.

DANE and DNSSEC

DANE is the
protocol that allows us to specify server certificates in DNS.

The site owner specifies the Root Certificate of his FPCA in a
DANE-TLSA record in DNS. As all servers are signed by that same FPCA,
all TLSA-records contain the same data.

The TLSA-record must specify Usage selector 2. That states the Trust
Anchor for the server. Other usage selector values cannot be used for
CSOP.

The DNS zone with the server records MUST be signed according to the
DNSSEC standard.

Browser

When the browser is requested – by the user – to retrieve a URL and
render it, it follows this procedure to determine which of the
resources are from the same origin.

  1. The browser resolves and validates the DNSSEC/DANE TLSA record and
    takes it that this is the Origin of the page. If there is any
    validation error, the browser displays an error and refuses to render
    this page.

  2. The browser resolves the IP-address, connects and validates that
    the server certificate matches the TLSA record. If there is any
    validation error, the browser displays an error and refuses to render
    the page.

  3. The browser downloads every resource (image, javascript) that it
    can retrieve from this connection and labels these resources to belong
    to the Origin. (It comes from the same server).

  4. For every resource specified in the that are on different
    servers, the browser performs steps 1 to determine the Origin of that
    resource
    . Then it performs step 2 to retrieve it. When there is any
    validation error, the browser discards this resource and displays the
    appropriate error in the page. Ie, broken image symbol.

  5. The browser has established the origins of each resource. It COULD
    treat all resources labeled with the Same value of Origin at the same
    trust level. It MUST treat all resources with different Origin values
    at a different trust level.

It’s up to the browser how much trust to give these trust domains.

For example, we can distribute a javascript application over serveral
servers, even cdn-hosted servers. For example, a web mail or photo
manipulation app. The browser can run our javascript while it forbids
the hostile code from a spying or hacked advertisement platform.

Notice: To prevent any trust where none should be granted, the
browser checks that the record has TLSA usage selector 2 and that the
Certificate specified is not a sub Certificate of any of the known
global CAs. They don’t deliver trust, they just establish a domain name)