Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A more secure form of 'cookie' could be created for SSL communications through the following method.

  • The client generates and requests the server to sign a certificate.

  • Then the client authenticates to the https server using the client certificate.

  • Additional basic auth is used to tie the client certificate to the site credentials.

That would allow the 'client computer' to be able to prove it's identity (knowledge of private key) to the server (also assuming that the server certificate is authenticated using PKI).

I am not aware of this protocol being used, advantages? disadvantages? or is it just pointless because cookies give us enough security?

share|improve this question
up vote 5 down vote accepted

I suspect that you may wish to read the current Internet draft on TLS Origin-Bound Certificates and note the organisation of the authors at the bottom.

share|improve this answer
Thanks @agl, even more proof that there is nothing new under the sun. – Andrew Russell Jul 14 '11 at 23:33

Certificates use asymmetric cryptography: here, the client generates a public key, gets it "authenticated" (signed) by the server, and later on proves his knowledge of the private key to the server (as part of certificate-based client authentication in SSL).

Certificates are useful when the certification authority (the party which "issues" the certificate, i.e. computes the signature on the certificate) is distinct from the party which uses the certificate (the one which authenticates the client afterwards, by looking at the client certificates and having the client use his private key as part of certificate-based client authentication in SSL). This separation of roles is what asymmetric cryptography is about.

In your proposal, the server is both certification authority and verifier, so the separation is pointless. Cryptographically speaking, certificates add nothing to the security model, that you did not already get from a classical symmetric authentication, i.e. a random cookie given to the client during registration, and simply sent back afterwards.

However, for practical reasons, some banks go to the trouble of issuing certificates to their customers, because usual Web browsers tend to be much better at protecting private keys than cookie values. For a start, cookies are normally stored in cleartext as files somewhere on the user computer. Also, customer certificates may be used, at some future point, to have them sign documents with non-repudiation (e.g. bank orders, such that the bank can prove later on to a third party, such as a litigation judge, that the customer really issued the order); getting the customer to store and use a certificate requires a bit of training, and some banks feel that this is a useful investment for a future deployment of a signature solution.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.