Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your client-side certificate (or more precisely its private key), is only as secure as your company's online and/or physical security let it be. </p> <p>For extremely secure relations (which typically do not have the requirement of scaling much), it may be acceptable that the provider of the service requires an extra element in the protocol which allows them to identify your site (and more often than not, to identify <em>a particular computer</em> or <em>individual</em> within the company, which is something client certs do not fully do.)</p> <p>This of course brings the question: what is warranty that this extra bit of authentication device will be more securely held by your company? (as compared to the client-site certificate itself).<br> The standard response for this is that these extra bits of security elements are typically non-standards, possibly associated with physical devices, machine IDs and such, and are therefore less easily transportable (and the know-how about these is less common: hackers know what RSA files to look for, and what they look like, what do they know of the genesis and usage of the KBD-4.hex file ?)</p> <p>Extra question: Can Y make use of my client-side certificate elsewhere?<br> No they [normally] cannot! The integrity of this certificate lies in your safe keeping of its private key (and, yes, a similar safekeeping from the certificate providers...). Therefore, unless they are responsible for installing the said certificate, or unless their software on your client (if any) somehow "hacks" into certificate-related storage / files / system dlls, they should not be able to reuse the certificate. That is they cannot reuse the certificate any more easily (which is theoretically NP hard) than anyone that, say, would sniff the packets related to authentication as the client establishes a session with the Y site.</p> <p>Extra questionS ;-) <br> - What is the nature of the client cert?<br> - Man-in-the-middle concerns...</p> <p>Before getting to these, let's <strong>clear a few things up</strong>...<br> The question seems to imply <strong>TLS</strong> (<a href="http://en.wikipedia.org/wiki/Transport_Layer_Security" rel="nofollow noreferrer">Transport Layer Security</a>) which is indeed a good protocol for this purpose, but for sake of understanding, the keys (public and private) from the certs (server's and client's) could well be used with alternative protocols. And also, TLS itself offers several different possible <em>encryption algorithms</em> for its support (one of the initial phases of a TLS session is for both parties to negotiate the set of algorithms they'll effectively use).<br> Also, what goes without saying... (also goes if you say it): <strong>the respective private keys are NEVER transmitted in any fashion</strong>, encoded or not. The confusion sometimes arise because after the authentication phase, the parties <strong>exchange a key</strong> (typically for a symmetric cipher) that is used in subsequent exchanges. This key is typically randomly generated, and of totally different nature than the RSA keys whether public or private!<br></p> <p>In a simplified fashion, the <strong>client's certificate contains the following information</strong>:<br> - The Certificate Authority (CA aka issuer)<br> - The "owner" of the certificate (aka Subject)<br> - Validity date range<br> - the PUBLIC key of the certificate<br> In more detail, the certificates are typically found in an <a href="http://en.wikipedia.org/wiki/X.509" rel="nofollow noreferrer"><strong>X.509</strong> wrapper</a> (? envelope), which contains additional fields such as version number, algorithm used, certificate ID, a certificate signature (very important to ensure that the certificate received wasn't tempered with). The X.509 also provide for optional attributes, and is also used for transmitting other types of certificate-related data (such as the CRL)</p> <p>Therefore <strong>the certificate's content allow the recipient to</strong>:<br> - ensure the certificate itself was not tempered with - ensure that the issuer of the certificate is one accepted by the recipient - ensure that the certificate is valid/current and not revoked - know the public key and its underlying size and algorithm</p> <p>With regards to <strong>man-in-the-middle concerns</strong>, in particular the possibility of "re-playing" a possibly recorded packet exchange from a previous session.</p> <p>The protocol uses <em>variable</em>, possibly random MACs (Message Authentication Codes) for that purpose. Essentially, during the negotiation phase, one of the parties (not sure which, may vary...) produces a random string of sorts and sends it to the other party. This random value is then used, as-is (or, typically, with some extra processing by an algorithm known by both parties) as part of the messages sent. It being encoded with the private key of teh sending party, if the the receiving party can decode it (with sender's public key) and recognize the (again variable) MAC, then it is proof that the sender is in possession of the private key of the certificate, and hence its identity is asserted. Because the MACs vary each time, pre-recorded sessions are of no help (for this simple purpose).</p>
    singulars
    1. This table or related slice is empty.
    1. POClient-side SSL theoretical question
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USmjv
    1. USmjv
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POClient-side SSL theoretical question
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COvery helpful, i added some more detail to my question (see original question), per your follow-up, can you possibly check it out?
      singulars
      1. PO
      1. USkvista
    2. COthanks again, one more clarification above, any response appreciated...
      singulars
      1. PO
      1. USkvista
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload