Something confusing about digital certificates

Question

A digital certificate is a digital document that certifies that a certain public key is owned by a particular user. Thus if you trust the CA that signed the certificate C, then you can trust that specific public/private key pair is owned by the owner of certificate C.

a) Assume client A wants to establish a connection with server B located at url www.some_domain.com. When establishing a connection with B, A may receive from the other end a X.509 certificate C and a public key, belonging to the owner of certificate C.

But how can client know that owner of C is really a server B and not some other entity that hijacked ( if that is the correct term ) the connection and sent its own certificate and public key to A?

Only way I can think of for client to know whether owner of C is really B, is if C's Subject field also specifies the domain for which this certificate is valid or if it specifies the organization to which this certificate belongs ( but that only helps if client knows to which organization www.some_domain.com belongs )?!

thank you

Answer 1

Because 'C' is signed by a CA certificate authority that is already on your system. That is why the scheme can be broken by governments that control the CA's.

If you look at a certificate in your browser then you can see who signed it. For instance gmail is signed by Thawte which is signed by Verisign. The CN field is marked www.google.com so it will only be valid for that domain.

Maybe you are talking about man in the middle: http://en.wikipedia.org/wiki/Man-in-the-middle_attack

A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other—it is an attack on mutual authentication. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, SSL authenticates the server using a mutually trusted certification authority.

So in your scenario only one side would be fooled. Check out step 2 below:

https://ssl.trustwave.com/support/support-how-ssl-works.php

• Step 1: A customer makes a connection to xyz.com on an SSL port, typically 443. This connection is denoted with https instead of http.

• Step 2: xyz.com sends back its public key to the customer. Once customer receives it, his/her browser decides if it is alright to proceed.

  • The xyz.com public key must NOT be expired
  • The xyz.com public key must be for xyz.com only
  • The client must have the public key for Trustwave installed in their browser certificate store. 99.9% of all modern browsers (1998+) include the Trustwave root certificate. If the customer has Trustwave trusted public key, then they can trust that they are really communicating with XYZ, Inc.

• Step 3: If the customer decides to trust the certificate, then the customer will be sent to xyz.com his/her public key. -Step 4: xyz.com will next create a unique hash and encrypt it using both the customer's public key and xyz.com's private key, and send this back to the client.

• Step 5: Customer's browser will decrypt the hash. This process shows that the xyz.com sent the hash and only the customer is able to read it.
• Step 6: Customer and website can now securely exchange information.

Answer 2

All a certificate can do is ensure that the communications between A and C are encrypted such that C (or whatever has the certificate installed) is the only one able to decrypt it.

It makes absolutely no representation with regards to who C is owned by. Some Certificate Authorities will try and establish that a given entity is who they say they are prior to disbursing a certificate. However, quite frankly, all of that can be duped and most sites don't bother paying for that level of research anyway (called Extended Validation).

Now, if some crook has stolen the certificate from server C and set up their own server (with the same fully qualified domain name), then yes they can impersonate away. However, this would require an additional step of poisoning DNS resolution so that requests to www.some_domain.com go to the hacker's server and not the original. It's usually much easier just to crack the original server and install your own data capture software.

As a side note there are huge security issues with DNS resolution.

Another note, recently the stuxnet worm used a stolen code signing certificate to get past some of the windows installation protections.

Answer 3

A is typically configured with a set of trusted CAs, which map C's public key to trusted entities, in this case B. Did you not answer your own question in the first paragraph, or am I missing something?

Answer 4

So the client A needs to know if certificate C is genuine. Whose task is to verify this? Ans: A's browser. How will it verify? Ans: Browser checks who signed the certificate. Who signed the certificate? Ans: A C.A(Certification Authority) named AweCerts.Inc Does the browser know this CA. And does the broswer trust CA? Ans: Yes. If the broswer does not trust then A cannot proceed further. And not only does the broswer trust AweCerts but her/his friends as well (the whole chain that is). How does the browser know this certificate was signed by AweCerts.Inc? Ans: Browser had an agreement with AweCerts. Microsoft does this in IE's case.
If the browser is able to unlock the message(outer covering) with AweCerts public key then it is sure that it was 'encrypted with AweCerts private key' or signed by Awecerts.

We usually encrypt with public keys and have it decrypted with private keys. But the other way around is possible as well and that is infact what we call Digital Signature. And you can check my blog for more interesting info on certificates and messaging.

There is an interesting blog here http://the-blueclouds.blogspot.nl/2011/11/public-key-private-key-hashing-blah.html