

TACK: certificate pinning to solve the SSL CA problem - NateLawson
http://tack.io/

======
NateLawson
This is an excellent proposal for an SSL extension to solve the problem of
rogue CAs. It's by Trevor Perrin (a former co-worker and great crypto
engineer) and Moxie Marlinspike, from Whisper Systems (now Twitter).

The way it works is simple. The admin for a site signs a message that "pins" a
given public key to the domainname. This message is delivered by an SSL
extension or appended to the SSL cert chain (a hack, but requires no protocol
changes).

The pin message states that the public key won't change for a given period. If
it changes, a rogue CA has issued a different cert and you are under attack.
The browser will reject the session.

The admin can "break" the pin early by signing another message, distributed
the same way. Then they can re-pin a new cert. This allows certificate
mobility, fully under the control of each site admin.

This accomplishes the same goal as whole-cert pinning (as practiced in
Chrome), but with many advantages. First, when you pin the cert (not public
key), you don't allow for CA mobility. So if you keep the same server key but
get a new cert, this appears to be an attack. Second, you have to notify
Google and wait for them to issue a browser update when you do get a new cert.
This is complicated and too costly.

Whole-cert pinning is used extremely rarely (not even all top 500 sites) and
will never gain widespread adoption.

TACK is an extremely simple protocol, and the messages are tiny. It is very
well-designed, and the site has working code on Github in addition to the
Internet draft.

Trevor and Moxie are doing great things, so please do all you can to support
them in this. It really is one of the few initiatives in recent times to have
a huge impact on your family's actual security, as well as dissidents in
countries like Iran.

~~~
ivanr
TACK is not competing with Chrome, but with the Public Key Pinning Extension,
currently in draft (see <http://tools.ietf.org/html/draft-ietf-websec-key-
pinning-01>). As the name says, they too are proposing to pin public keys, not
certificates. I prefer TACK, because it makes sense to solve this problem on
the TLS level, rather than on the HTTP level.

EDIT: It's difficult to find a confirmation online, but I recall that Public
Key Pinning is already live in Chrome, starting with version 18.

~~~
NateLawson
Correct. Even though Chrome calls its feature "certificate pinning", it is
actually pinning public keys. Trevor pointed me at their code below:

[http://src.chromium.org/viewvc/chrome/trunk/src/net/base/tra...](http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=107993&view=markup&pathrev=107993)

The criticism of Chrome's pinning is still valid though. The pinned key is
allowed to show up anywhere in the cert chain, not just at the leaf
certificate. Also, they have to pin several CAs, as well as multiple keys per
CA to deal with sub-CAs.

------
jimrandomh
I like it! This is long overdue, and I want an actual implementation. That
said, I think the spec as currently written is _much_ too slow to accept
newly-seen pins and much too eager to expire old ones. In section 3.2, it says

> When a client sees a new hostname and TACK key combination, an inactive pin
> is created. Every subsequent time the client sees the same pin, the pin is
> "activated" for a period equal to the timespan between the first time the
> pin was seen and the most recent time, up to a maximum period of 30 days.

But this means failing to protect in many cases where protection is possible.

If a pin is seen _once_ , then any future certificate without that pin should
generate a warning, immediately and forever. If there is reason to suspect
that a tack is invalid (say, because it's very old), then soften the warning
message. (This would probably mean that a domain has changed owners. In that
case, I want to at least clear cookies for that domain, and would appreciate a
warning and an easy user interface for doing so.)

And if I visit a site exactly twice, I see a tack the first time, and I don't
see it the second time, then regardless of whether it was an attack the first
time and is okay now, or was okay the first time and is an attack now, I
_absolutely must know_ because that is _not_ something that will happen
legitimately.

Also, I would add the following language: "If TACK validation fails, the
client SHOULD provide an easily accessible mechanism for submitting the
certificate and associated information to a third party for analysis." Because
that's what it'll take for rogue CAs to be discovered.

~~~
NateLawson
Those are interesting comments you should probably email to the authors.
Contact info should be on their website.

The general goal of this part of the spec, I think, is to deal with the case
where an attacker forges a pin (using his own key) for a third-party site.

Think firesheep, where the attacker could make a fake pin for yahoo.com and
send it to all coffee shop patrons. If the victim had not visited yahoo.com
before, their browser would cache the fake pin, and it would report errors
when the real one was seen.

To prevent the user from having to manage a known-hosts file by hand, like
ssh, they went the route of making it take a second visit before a TACK pin is
activated and the interval it is valid for is related to the delta between
first and last visits.

SSH takes the route of forcing the user to verify the host key the very first
time it's seen, and then it has an infinite lifetime. The user has to manually
delete it to restart the cycle.

That wouldn't fly if it's a browser and your grandfather, so they came up with
something more clever but slightly less secure in one specific way.

~~~
ivanr
I am not convinced the current spec addresses that particular attack well. The
second visit could happen while the victim is still in the coffee shop.
Perhaps a 24 hour delay on the pin activation would be more appropriate.

On the other end, it concerns me that the upper limit is set to 30 days. I
understand it is all about damage control, but it also means that the pinning
is not going to protect me when visiting web sites only once in a while. For
example, I am an infrequent PayPal user. I will log into their web site once
every couple of months. TACK wouldn't work for for my use case.

~~~
NateLawson
If the second visit happens then, the activation is still only valid for the
delta between first/last seen times. So if it's over a couple hours in the
coffee shop, it's deactivated by the time you go home. TACK can definitely
benefit from being paired with Convergence, so you don't have to "start cold"
the first time you visit a site.

Yes, I think their main concern was about admins testing out pinning and
accidentally locking their customers to the wrong key due to a configuration
error. Perhaps the default UI action if a previously-activated pin has expired
and a new pin key is being presented should be to warn the user.

------
casca
This looks like the next iteration of Moxie Marlinspike's Convergence[1]
project.

For anyone who doesn't understand why SSL for browsers as deployed is broken,
a quick exercise is to look at how many CA certificates come trusted with your
favourite browser. For example, Firefox trusts the "Hongkong Post Root CA".
This means that anyone who has access to the signing key can claim to be any
SSL site. So they could issue a certificate for www.gmail.com which would
allow someone to transparently intercept all your traffic.

Certificate Pinning is a very good start to somewhat mitigate this.

[1] <http://convergence.io/details.html>

~~~
NateLawson
TACK benefits from Convergence, but isn't based on it. It also doesn't require
it. Convergence could be used as a source of information on existing pins it
has seen, but TACK is still useful even if it's just supplied by the website
itself.

Think of it like ssh known-hosts, but with the added feature that the server
side (sshd) can securely tell you to stop using an old entry in known-hosts
and use a new one instead when its server key changes.

Also, TACK is not certificate pinning. It's public-key pinning (the thing
inside the cert). You can change certs all you want without changing the
public key, and the same TACK pin will be valid for all of them. This is
better than cert pinning since you can change CAs without having to redo all
your cert pins.

