TACK: certificate pinning to solve the SSL CA problem(tack.io)
tack.io
TACK: certificate pinning to solve the SSL CA problem
http://tack.io/
3 comments
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.
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.
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...
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.
http://src.chromium.org/viewvc/chrome/trunk/src/net/base/tra...
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.