0

Quote from an article on computerworld.com:

"The private key is used to sign the server's TLS public key, which is currently used by browsers to validate SSL certificates."

My understanding is that SSL certificates are verified using the signing CA's public key, or the public keys in a chain of trust, where necessary. Once the certificate is verified, you can be assured about the authenticity of the server's public key that is found in the certificate. The sentence that I quoted above makes it sound like the TLS public key is used to verify the authenticity of the certificate, which doesn't make sense to me. Can someone confirm that what I said is correct, or explain why what the author said is correct? I bolded the pertinent part of the quote, since the rest of it is about TACK, a new protocol intended to strengthen TLS certificates.

Improve this question

1 Answer 1

Reset to default
3

The article is about an extension called TACK, which works more like SSH than a traditional CA system.

With a traditional CA system the CA signs (with the CA's private key) the certificate which contains the servers public key, then the browsers use a built in store of public keys of trusted CA's to verify it, with the ability to have chains and intermediary CA's there is over 600 organisations at last count (EFF's SSL Observatory data).

TACK works more like SSH where we remember the servers public key from the first connection and verify it matches. One still needs to do some kind of other verification on the first connect but after that one can then verify that the key is as expected without the need for a certificate authority. Also one widespread automatic use would also have to handle invalidation in case of key compromise. In TACK to manage this, there is a second keypair that is the one remembered by the server instead of the main one this allows for a clever way to handle invalidation.

Improve this answer
8
  • Can you explain further what was meant by "In TACK to manage this, there is a second keypair that is the one remembered by the server instead of the main one this allows for a clever way to handle invalidation." Also, the articles I read about TACK indicated that it was a secondary authentication mechanism used to provide assurance about the server's certificate not being compromised... it made it sound like the server's public TLS key (from TACK) and the server's public key in the certificate would be the same thing. IDK, I was somewhat confused by the numerous articles I read.
    – Kyle
    Jan 7, 2013 at 14:09
  • 'A "tack" contains a "TACK key" which is used to sign the public key from the TLS server's certificate. Hostnames can be "pinned" to a TACK key.' from ietf draft: tools.ietf.org/html/draft-perrin-tls-tack-01
    – ewanm89
    Jan 8, 2013 at 21:52
  • Yeah I read the IETF draft. I don't see how TACK helps anyone. Why is it more effective than using certificates? You seem to be saying that TACK doesn't use certificates at all, that it bypasses the current CA-based system and uses the TACK keys instead. Is that true, because my initial understanding was that TACK allows you to detect fraudulent certificates. Is the server's TLS key in 'TACK' the same as the server's public key found in a server's CA-issued certificate? That's the only way I could see TACK providing a benefit, since you could then compare the public keys for a match.
    – Kyle
    Jan 8, 2013 at 22:34
  • No tack signs the servers public key with its own keypair. We have the server sign it's public key with another keypair and after first connect we remember this second keypair and check that signature. Now the certificate is due for renewal and the server admin legitimately goes to another call, now just stop signing the old public key and start signing the new one with TACK, signature is valid so all is well. However for other changes the TACK signature will be invalid or missing and there is an error.
    – ewanm89
    Jan 12, 2013 at 9:58
  • Ok so: the TACK keypair is used to sign the server's public key, which is the SAME key that can be found in the server's digital certificate. If that's the case, then why doesn't TACK simply add an additional layer of security to digital certificates by allowing the client's browser to verify the public key? (Your initial post in this thread says that TACK operates "without the need for a certificate authority")... TBH this is confusing, I don't see why you'd use it by itself, I only see why you'd use it as a "second check" to verify the server's public key hasn't been changed by an adversary
    – Kyle
    Jan 14, 2013 at 15:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .