Today at W2SP I presented a new paper making the case for distributing security policy in hyperlinks. The basic idea is old, but I think the time is right to re-examine it. After the DigiNotar debacle, the community is getting serious about fixing PKI on the web. It was hot topic at this week’s IEEE Security & Privacy (Oakland), highlighted by Jeremy Clark and Paul van Oorschot’s excellent survey paper. There are a slew of protocols under development like key pinning (HPKP), Certificate Transparency, TACK, and others. To these I add s-links, a complementary mechanism to declare support for new proposals in HTML links.
Though it’s unclear which proposals will take hold, deployment will probably be fragmented: some servers will require HTTPS (using HSTS), some may pin keys or use another new protocol, and many will continue to not support HTTPS at all. Clients must know what the server supports prior to initially connecting, or else a middleperson attacker can simulate a server which only supports insecure HTTP (often called a stripping attack). Thus hardening HTTPS includes an enormous policy distribution problem.
The consensus is that querying a new out-of-band trusted server to learn security policy is a non-starter. OCSP, a protocol to check if certificates are revoked, provides a painful example. It was never reliable enough for browsers to fail closed if OCSP servers couldn’t be reached, so it provided negligible security and Chrome eventually disabled it. This leaves very few channels to distribute security policy prior to initial connections. Browser preloads are great, but can’t scale indefinitely. DNSSEC (via extensions like DANE) is a promising approach, but many deployment issues remain.
This leaves secure introduction: if a user agent is referred to a new domain by an already-trusted domain, the referring domain can indicate a minimum security policy required for the initial connection. S-links are a proposal to enable secure introduction in HTML. A stricter HTTPS policy (such as key pins) can be declared in a new “link-security” attribute, which will apply only to requests caused by that element itself (for example, clicks on a link or loading a JavaScript library).
S-links aren’t a panacea: they can’t protect users who manually type a new URL. Still, compared to the alternatives s-links are an efficient and easy-to-deploy channel for security policy. An important lesson from past PKI failures is to build for robustness: multiple protocols will have to be supported and we should build multiple ways of advertising security upgrades. S-links is still a very early-stage project with important details to get right about the user experience and some subtle interactions with the browser’s same-origin policy. I would greatly appreciate feedback.
So this has to be additive to the CA system, not an alternative – otherwise there’d be a major phishing/sslstrip type attack possible. (This will happen in the first browser implementations if they come)
This proposal is certainly an addition to the current CA system and not a replacement. One key aspect of the proposal is that s-links can only be used to specify a stricter security policy than whatever the browser would otherwise enforce for a domain-this is a “do no harm” mechanism, except for the possible harm of causing a link to appear broken if a security policy is declared which can’t be satisfied.
This is important, because otherwise a malicious (or XSS-compromised) site could initiate an insecure connection to an otherwise-secure domain. This is explained in more detail here: https://sites.google.com/site/slinkspec/faq