Need some insight on Https

Question

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?

Answer 1

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.

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.

Answer 2

theBank.cer is a public key.
You cannot use it to decrypt or sign anything.

Answer 3

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.

This is more or less what happens with RSA, but not with DSA, which is signature only (no encryption).

In general, you shouldn't talk about "encrypting" with a private key. It doesn't make any sense, since anyone would be able to decrypt with the public key (since it's public). Encryption is about hiding information.

What you can do with a private key is sign and decrypt/decipher. What you can do with a public key is encrypt and verify a signature.

If you mix up when encryption is required and when signatures are required (despite the fact the algorithm are very similar with RSA), you can end up designing systems that don't provide any security.

More generally, the purpose of a public key certificate (X.509 certificate, or even PGP certificate) is to bind an identity (e.g. the server host name) to a public key. (See this question on Security.SE.)

The data my web server will receive will be encrypted by the public key of the bank

Note that the SSL/TLS traffic is not encrypted using the certificate's private key, but shared keys negotiated during the SSL/TLS handshake.

During the SSL/TLS handshake, that public key is used either to encrypt the pre-master secret or to sign other parameters (depending on the cipher suite), which end up proving to the client that it's communicating with a server that has the private key for this public key.

Since the certificate also binds the server name to the public key, the client then knows it's communicating with the right server.

This is why it's important to verify that (a) the certificate is trusted and (b) it's issued to the server name the client wanted to connect to.