8

Let's imagine our user's computer wants to talk to some server for the first time in history via https. The computer sends a hello message, the server sends his public key and the certificate, containing: server name, CA name, expiry date and server's public key hash, encrypted with the private key of the CA (aka digital signature).

But what stops a hacker from changing the "server name" in the certificate? Does the server encrypt all these fields with his (server's) public key? And how does the user know that the site he is going to visit corresponds to the certificate. Does the user compare URLs?

If the certificate is unencrypted - the hacker may send the user his own certificate, signed with the same CA, but with the server's urls field changed. So how does it work?

Improve this question
6
  • 1
    Anything changed in the certificate will invalidate the hash that's encrypted using the CA's private key. The hash is the only thing that's actually encrypted.
    – Jonathan Gray
    Dec 15, 2015 at 7:50
  • I'm pretty sure there is a security against that kind of attack (which is the hacker intercepting the certificat to redirect it to the user). It consists in destroying the certificat package if it makes more than n pauses before it reaches the user. if the package never reach the user it means someone is trying to intercept it beeing in the middle. There might be other type of securities though
    – JohnnyBgud
    Dec 15, 2015 at 7:51
  • 2
    @JohnnyBgud No. The only way to ultimately ensure a certificate's validity is to decrypt the hash using the public key of the CA and check it against a recalculated hash of the certificate.
    – Jonathan Gray
    Dec 15, 2015 at 7:53
  • @JonathanGray what is the encrypted hash calculated from? Is it the hash of open key or hash of entire certificate?
    – yanpas
    Dec 15, 2015 at 7:55
  • 2
    It is the hash of the entire certificate. Which is encrypted then included with the certificate (this is referred to as a digital signature).
    – Jonathan Gray
    Dec 15, 2015 at 7:56

2 Answers 2

Reset to default
13

All certificates are signed in whole (protected against changes), so you can't change the name, or any other data inside it.

The certificate of the server you connect to is signed by the issuer certificate, which in turn may be signed by other certificates higher up, this is the certificate chain. The top, aka root is signed by itself. If you make any changes to any of these certificates, it won't have a valid signature anymore. If you replace the public key and the signature, the certificates below can't verify using this certificate anymore.

The owner of a root certificate is able to change anything in their own certificate at will, so they can for example extend the validity (replace the expiration date), while still keeping all issued certificates valid.

The browsers are expected to have all current root, and some intermediate certificates stored already, so you are able to verify all certificates issued by any of those with the security of how securely you acquired your operating system or browser (which may not be very safe, after all).

Whether users compare URLs is a different thing - the browser will warn you if you wanted to go to a site and the certificate is issued for a different name - but if the name you typed is misleading, and it has a valid certificate, it's still a problem. CAs are expected to only issue certificates to names they can vouch for - and they invented those green EV - extendend verification certificates, which they check even more.

For example if you wanted to go to storemymoneypal, but mistyped storemymoneypai, and the site presented itself as storemymoneypaI (with a capital i at the end), it's hard to see the difference - this is what the verification is expected to avoid. With unicode characters there are even more similar characters, but these dangers are well known, and any CA worth their salt to earn the trust of browser vendors will be aware of them.

Improve this answer
0

it works in the way as step below: 1. admin generate a pair of public and private keys on the server. 2. public key and other info ( dommain name, contact, organization etc.) 3. trusted CA ( like verisign) verifies those declaration 4. if all are ok, trusted CA sign all provided info to and send to admin a certificate ( this is how CA earn from customer) 5. whenever a client access HTTPS, he/she will receive that certificate and he/she has to verify whether certificate is ok, valid and not tampered. Since client's machine/browser( windows, linux) has a list of all trusted CA, therefore, client can efficiently verify the certificate.

In that way, if hacker change certificate, client will detect those changes.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .