I am only a beginner and doesn't know much about https. I have heard that they uses somekind of a key and is shared between them. If an attacker wishes to attack could he be able to capturebthe key and attack?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
No, an attacker listening to the SSL connection is unable to get a copy of the keys.
This is actually a fairly fundamental property of SSL (or any other protocol that encrypts traffic); we're encrypting the traffic because someone might be listening in, and we want to prevent them from being able to understand the traffic. We do this by having the two side share keys, and using those keys to encrypt the traffic. If the guy in the middle could recover the keys, they could listen in. Hence, any encryption protocol must have some story why someone in the middle cannot recover the keys.
Actually, SSL can do it a number of ways, depending how what the two sides agree on (the "ciphersuite"). I'll describe the most common method.
This method (which I believe is used when, say, you're doing a connection with Amazon) depends on the magic of Public Key Cryptography. What this allows us to do is have one side (the Server) generate two related keys, the "public key" and the "private key". Someone can encrypt a message with the "public key"; however the public key does not allow you to decrypt; in essence, it acts as a "one-way" box. However, someone with the private key can decrypt messages.
So, here is a simplified summary of it works: you (the client) ask the Server for a copy of its public key; it gives it to you. Then, you pick a random value (the "premaster secret"; at your level, you can think of it as the session key), and encrypt that with the servers public key, and send that. The server then receives the encrypted value, and then decrypts it. At this point, both sides share the same premaster secret (the client because it originally picked it, the server because he just decrypted it), and so can use that value to come up with the session keys.
Now, here is what someone in the middle hears:
Now, the Server's public key does not allow him to decrypt the random value (remember, the public key allows only encryption), and so he cannot learn the value that was shared.
Now, if you think about this, one thing may occur to you: how does the client know that the public key he got was actually the Server's public key; couldn't someone who can modify messages in the middle substitute his own public key and pretend to be the server? Well, SSL does have defenses against that; however, that involves more Public Key Cryptography, and so I'll leave that out for another day.
Of course - the whole important question is the one you "left out for another day."
If a party in the middle can spoof IP addresses for some poor browser, then the party in the middle can act like a server to the browser, and act like a browser to the server. There will be two "premaster secrets", and how will either the browser or the server know?? AFAICT, if any real browser connected directly to a real server can decrypt and display everything, so can a party in the middle.
How is that secure??
(Meanwhile I am typing my credit card number over HTTPS to buy a pair of jeans..)