LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Public key, private key explained (http://www.linuxquestions.org/questions/linux-security-4/public-key-private-key-explained-648761/)

calande 06-12-2008 06:03 AM

Public key, private key explained
 
Hello,

I'm trying to understand how encryption and authentication work. I read that for the case of a web site and an SSL certificate, let's take the example of you buying from Amazon, there is a private key that only Amazon knows, and the Amazon.com public key that anyone can get. So you access https://www.amazon.com, the web site sends you its public key, and its web page encrypted using their private key. Using the public key, you know it came from Amazon and you can read the content of the HTML file. Ok. But if between my computer and the Amazon servers, there is some one who snifs the packets sent back and forth, he knows I'm visiting Amazon, he also knows the public key, and therefore, he can intercept HTML data and decrypt it using the public key, right? Then it's not secure. Or am I missing something? :)
Thanks,

billymayday 06-12-2008 06:14 AM

That's why certificate authorities come into play.

What you are suggesting works, but is hard, because unless I know what encrypted sites you plan to visit, the middleman would need to create a certificate on the fly which takes time. But what you describe it the classic middleman vulnerability

calande 06-12-2008 06:19 AM

Thanks. If the middle man reads the information sent back and forth, he knows what site the victim is visiting, right? So he can decrypt the information sent by Amazon using the Amazon public key. Or am I missing something? For what purpose would he have to create a certificate on the fly? What kind of certificate would it be?

win32sux 06-12-2008 06:23 AM

Quote:

Originally Posted by billymayday (Post 3182394)
That's why certificate authorities come into play.

What you are suggesting works, but is hard, because unless I know what encrypted sites you plan to visit, the middleman would need to create a certificate on the fly which takes time. But what you describe it the classic middleman vulnerability

The thing is, what he described is totally erroneous. Additionally, you don't need to have any prior knowledge of what sites the victim will be using or anything like that. Creating fake certificates is a piece of cake, and if it wasn't for a trusted third-party (the CA), there would be no way to know with a fair degree of certainty that the server's certificate actually belongs to it. So yes, checking for properly signed certificates protects you from a man-in-the-middle attack, but the attacker having prior knowledge of the sites is irrelevant - as it should be.

Quote:

Originally Posted by calande (Post 3182385)
I'm trying to understand how encryption and authentication work. I read that for the case of a web site and an SSL certificate, let's take the example of you buying from Amazon, there is a private key that only Amazon knows, and the Amazon.com public key that anyone can get. So you access https://www.amazon.com, the web site sends you its public key, and its web page encrypted using their private key. Using the public key, you know it came from Amazon and you can read the content of the HTML file. Ok. But if between my computer and the Amazon servers, there is some one who snifs the packets sent back and forth, he knows I'm visiting Amazon, he also knows the public key, and therefore, he can intercept HTML data and decrypt it using the public key, right? Then it's not secure. Or am I missing something?

That's not how it works. The client connects to the HTTPS server, and the server provides the client with a certificate (which includes the server's public key). The client verifies that the certificate is good (in other words, that it is digitally signed by a trusted third party), then proceeds to encrypt a random session key using the server's public key and sends it to the server. The session key is used from then on to secure the connection for that session. Keep in mind that only the server can decrypt content encrypted with its public key (you need the private key to decrypt it). If you Google for something like how does HTTPS work (or maybe how does SSL work) you should be able to find tons of info.

Quote:

Originally Posted by calande (Post 3182385)
But if between my computer and the Amazon servers, there is some one who snifs the packets sent back and forth, he knows I'm visiting Amazon, he also knows the public key, and therefore, he can intercept HTML data and decrypt it using the public key, right?

No. He needs the private key in order to decrypt.


All times are GMT -5. The time now is 09:51 AM.