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,

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

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?

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.

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.

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