Excuse me if this question is really naive, but I searched as much as I could without being able to find relevant answers.
I spent the last three days trying to understand how https works.
All I knew before these days is how symmetric and asymmetric cryptography works.
It was about time for me to understand how these two are applied on ssl-https and achieve the so called data encryption and server identity verification.
Everything is clear regarding the data encryption and the prevention of man-in-the-middle attacks
It seems though that I don’t completely understand how server identity verification works, so your help will be highly appreciated.
My understanding so far is the following:
When a client connects to a server via https, the server sends a signed by a CA certificate.
This server certificate is a text file containing information regarding the server(name, owner email, public key etc..), plus a digital signature.
This signature is a hash of the content of the server information, encrypted by the CA private key.
The client checks the validity of the signature by producing again -on his own- the hash of server info and decrypting the signature using the CA’s public key. If the decrypted signature value is the same with the produced hash, the signature and the certificate subsequently are valid.
Note here that the public-private encryption scheme has a dual nature. A message can be encrypted by the public key and decrypted by the private key. The same message can be encrypted with the private key and decrypted by the public key as well.
What we need to keep in our minds here is that the certificate is a static and non change-able file. Any change on the file will result in a signature mismatch.
I will describe now a way to fool https:
Lets say theres an ebanking site with URL = https://wwww.TheBank.com/ebanking (public IP = 195.134.0.1)
I connect to this URL and my browser gets the server certificate. (theBank.cer)
On the same time I’m the owner of an internet cafe. My internet cafe has its own router, DNS and DCHP servers which I have the knowledge to control. It has a web server as well.
I configure the web server to own ip 195.134.0.1, same as the bank’s
I create a route to my router that sends connection requests for 195.134.0.1 to my web server
I configure my DNS to point the above bank URL to 195.134.0.1(my web server)
I place a fraudulent bank site on my web server. For any connections on this site, I instruct the web server to send to the client the certificate I downloaded before.( theBank.cer)
A user comes to my cafe, gets connected to my network and attempts to connect to this bank. My server sends to him the certificate of the bank. His browser will confirm the validity of the certificate, since its indeed the valid one and allow a connection to my fake web site since its URL, IP and hostname are the same with the real one.
So my fraud is successful.
Of corse, this security hole is too obvious to be true. Meaning I haven’t understood something in this server identity verification procedure. Can someone please explain to me what I am missing here?
Once his browser has confirmed the validity, it knows the bank’s real public key, since that’s in the certificate. Since your server can’t sign anything with the private key corresponding to that public key, nor can you decrypt anything encrypted with that public key, you can’t impersonate the bank at all. All you can do is convince the user of the bank’s real identity, which you can’t impersonate.
I think the key thing you’re missing is that the primary purpose of a certificate is for a trusted authority to bind a real-world identity to a public key, such that only the owner of that real world identity knows the corresponding private key.