0

How does the client ensure the ssl certificate that the server send is the true owner of the certificate? How does it prevent a hacker from cloning, for example, the google ssl certificate, and trick me that he is the google site during the handshaking? can the hacker clone the certificate and modify the domain or ip info from network packet to trick people?

Bryan Fok
  • 3,277
  • 2
  • 31
  • 59
  • 1
    Because the hacker doesn't have the private key. – user207421 Jul 06 '15 at 09:46
  • isnt the private key only for encrypt the message? – Bryan Fok Jul 06 '15 at 09:48
  • 1
    No. It isn't used for that at all in SSL. It *is* used in a handshake message that proves that the certficate is owned by the party that sent it, by creating a digital signature. Only the party that has the private key can do that. – user207421 Jul 06 '15 at 09:52
  • I just answered that. 'It isn't used for that at all in SSL.' – user207421 Jul 06 '15 at 10:16
  • I just answered that too. 'By creating a digital signature.' The server signs a message with its private key: the client verifies it with the public key. This is Digital Signatures 101. And it is all explained, again, in your link. – user207421 Jul 06 '15 at 10:21
  • His explanation kind of clear my confusion - http://security.stackexchange.com/a/20923. – Bryan Fok Jul 06 '15 at 10:43
  • You might be interested in [this](http://stackoverflow.com/a/13155623/372643) or [this](http://security.stackexchange.com/a/13953/2435). In short, depending on the cipher suite, the certificate's key pair is used for signing something or enciphering something. Only the party with the legitimate private key (and the client) is able to put the pieces back together (the pre-master secret). – Bruno Jul 06 '15 at 13:32

1 Answers1

4

An SSL certificate for e.g. www.google.com is signed by a 3rd party named a Certificate Authority (CA). In the case of google that 3rd party is currently "GeoTrust Global CA". Too look up who it is, you need to inspect the certificate (browsers typically will let you do that rather easily, but each has their own way) That links the certificate with the name "www.google.com".

Your client(s) have a list of CAs they trust on your behalf. That list is either maintained by the vendor of your OS and/or by the creator of your client/browser.

So how does the client know it's talking to the right server ? The certificate is signed by a CA it trusts, the certificate is for the name the client wants to connect to, and the server delivered proof it knows the corresponding secret key to the public key that's in the certificate.

  • A hacker who would copy a valid certificate from www.google.com and place it on their own machine would only have the public key and not have the private key.
  • A hacker who would try to get their certificate request signed by a reputable CA would get rejected because they cannot proof to own the google.com domain. And hence the name would not match.
  • A hacker who would sign their own certificate request, would fail as their self-built CA is not in the trusted list.

  • A hacker who would break into google's servers and copy the secret key somehow, could pass muster for a while, but once the folks at Google detect it, they would contact their CA and revoke the certificate.

    Now this process is the weak point in most implementations as these revoked certificates are published by the CA as Certificate Revocation Lists (CRLs) or as an OCSP (Online Certificate Status Protocol) service, but clients typically take the shortcut and do not validate that a certificate has not been revoked.

  • This answer makes valid points, but does not answer the initial question, which is about what prevents someone from copying an existing (public) cert and trying to use it as their own (the answer being the need for the private key during the handshake). – Bruno Jul 06 '15 at 13:35
  • A hacker who would copy a valid certificate from www.google.com and place it on its own machine *would* have the public key. It's in the certificate. He wouldn't have the *private* key. – user207421 Jul 06 '15 at 13:48
  • Correct EJP: a mistake that had escaped the rereading. Corrected. –  Jul 07 '15 at 14:47