title: Client-side SSL theoretical question
body: <p>I work at company X and we want to engage in a B2B transaction with company Y.  In doing so, Y is requiring client side authentication; they already provide server-side authentication - so this would be a mutual SSL transaction.</p>
  
  <p>My understanding is that I simply need to provide my CA-signed cert as part of my client side HTTPS communication.  In doing so, asymmetric cryptographic guarantees (i.e., public/private key technology) ensures that I am who I claim I am - in effect, it is not possible to impersonate me.  (the root CA has ensured I am who I am, that is why they signed my cert, and it's possible to prove that I didn't "manufacture" the certificate).</p>
  
  <p>Here's my question: is this all I need to provide company Y?  </p>
  
  <p>Alternatively, do I have to provide them with <em>another</em> key in advance, so that they can ensure I am not a rogue who happens to have "gotten a hold" of a root-signed certificate for me (company X)?  It would seem that if one has to provide this extra key to all parties he wishes to engage with on the client side, it would seem to make client-side SSL not as scalable as server-side SSL.  My guess is that it's not possible for one to "get a hold" of a client side cert; that the actual transmission of the client side cert is further encoded by some state of the transaction (which is not reverse-engineerable, feasibly).</p>
  
  <p>Does this make sense and am I right or am I wrong?  If I'm wrong, does Y in effect need to get an "extra" pre-communication key from every party that connects to it? (which they want to verify)?</p>
  
  <p>Thanks. </p>
  
  <p>=== </p>
  
  <p>Thanks for the responses below, at least the first two have been helpful so far (others may arrive later).  </p>
  
  <p>Let me talk in a bit more detail about my technical concern.</p>
  
  <p>Suppose company Y attempts to "re-use" my client side cert to impersonate me in another client-side transaction with another company (say "Z").  Is this even possible?  I am thinking - again, perhaps poorly stated - that some part of the <em>transmission of the client side certificate</em> prevents the entire key from being compromised, i.e., that is not technically feasible to "re-use" a client certificate received because you could not (feasibly) reverse engineer the communication which communicate the client cert.  </p>
  
  <p>If this is not the case, couldn't Y re-use the cert, impersonating X when communicating (client-side) to Z?</p>
  
  <p>ps: I realize that security is never 100%, just trying to understand what is technically feasible here and what is not.</p>
  
  <p>Thanks very much!</p>
  
  <p>===</p>
  
  <p>Further technical details, I appreciate any additional input very much - this has been very quite helpful.</p>
  
  <p>From a layman's point of view, my concern is that when a client sends his client cert, what is he sending?  Well, he has to encrypt that cert using his private key.  He sends the ciphertext with the public key, and then a receiving party can use that public key to decrypt the private-key-encoded payload, right?  That makes sense, but then I wonder -- what prevents someone from hearing that communication and simply re-using the private key encoded payload in a replay attack.  Just replay the exact ones and zeroes sent.</p>
  
  <p>Here's what I believe prevents that -- it can be found in the TLS RFC, in multiple places, but for example in F.1.1:</p>
  
  <pre>
  F.1.1. Authentication and key exchange
  
     TLS supports three authentication modes: authentication of both
     parties, server authentication with an unauthenticated client, and
     total anonymity. Whenever the server is authenticated, the channel is
     secure against man-in-the-middle attacks, but completely anonymous
     sessions are inherently vulnerable to such attacks.  Anonymous
     servers cannot authenticate clients. If the server is authenticated,
     its certificate message must provide a valid certificate chain
     leading to an acceptable certificate authority.  Similarly,
     authenticated clients must supply an acceptable certificate to the
     server. Each party is responsible for verifying that the other's
     certificate is valid and has not expired or been revoked.
  
     The general goal of the key exchange process is to create a
     pre_master_secret known to the communicating parties and not to
     attackers. The pre_master_secret will be used to generate the
     master_secret (see Section 8.1). The master_secret is required to
     generate the certificate verify and finished messages, encryption
     keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
     a correct finished message, parties thus prove that they know the
     correct pre_master_secret.
  </pre>
  
  <p>I believe it's the randomization associated with the session that prevents these replay attacks.</p>
  
  <p>Sound right or am I confusing things further?</p>