Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer

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:

  • The Server's public key.

  • The random value encrypted with the public key.

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.

share|improve this answer
    
But we also get encrypted reply from the server and we need the private key, I hope. So how is this private key shared? Or is there only one way encryption? –  DDR Jul 8 '13 at 1:54
    
@NithinJose: The above procedure (with the server's public/private key pair) is used to establish the session keys, which are symmetric. Once both sides have establish their common session keys, they can use that to send messages; that session key is what is used to protect the actual HTTP traffic. –  poncho Jul 8 '13 at 1:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.