6

If I understand right, there is a "handshake" where both the server and the browser verify who they are and agree on an encryption key. Why cannot a hacker just watch the network for the keys going through?

Why can't a hacker just watch for the handshake, collect the data, and run it through a easy-to-write piece of software?

Anonymous Penguin
  • 302
  • 2
  • 10
  • If this wasn't secure the Internet would be one big security nightmare. Clearly it isn't so this isn't an issue. – John Conde Feb 25 '14 at 01:10
  • 1
    @John Obviously, but I'm trying to figure out how they *are* secure. Why can't a hacker look at that and view the encryption? (I should reword my title.) –  Feb 25 '14 at 01:11

2 Answers2

3

See the Handshakes section of Thomas Porrin's answer to How does SSL work? for full details, but for the very short answer:

Because the first handshake of a sessions ends up using asymmetric cryptography to encrypt a symmetric key to the other side's public key (which is indeed available via packet sniffing), and then the other side uses their private key to decrypt it. This private key is not transmitted between the two, and without it, it is prohibitively difficult to decrypt the message containing the symmetric key (barring implementation or design flaws).

After the symmetric key is transferred, then a symmetric cipher can be used since there is a "shared secret" key.

Community
  • 1
Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • 1
    I think it's worth adding a paragraph about (EC)DH. SSL supports many different key exchange options; the other commonly used one is Diffie-Hellman, which doesn't transmit the secret key at all, not even encrypted. – Matt Nordhoff Feb 25 '14 at 04:14
  • That's an excellent suggestion. Regrettably, I'm going to have to leave that to those with more in-depth cryptographic background than I have; I merely know that I Am Not Dave. – Anti-weakpasswords Feb 25 '14 at 06:46
3

There are two types of cryptography. Symmetric and Asymmetric.

In Symmetric, the same key is used in both the parties to encrypt/decrypt the data. Examples include AES algorithm. If the MITM knows the symmetric key used by the client and server, he can easily decrypt the messages.

In Assymetric, a public-private key pair is used. One way of arriving at a common secret using asymmetric cryptography is as follows:

Server generates a pub/pri key-pair say using RSA algorithm. It puts the public key in a certificate and sends it to the client.

Client will generate a random pre-master secret and encrypts it using the public key got from server's certificate and sends the encrypted pre-master secret in the "client key exchange" message.

Server will then decrypt the encrypted message using its private key associated with the public key.

Now both server and client have the same pre-master secret. They will use that and some other random values(like clientHelloRandom, serverHelloRandom which are sent in plain text during clientHello and serverHello handshakes) to derive the same master key.

This master key is used to derive session keys using which the Applications data is encrypted/decrypted.

Please note that a MITM cannot impersonate a client because the pre-master key generated by the legitimate client is sent by encrypting with the public key. the MITM cannot decrypt it as long as he doesn't know the private key and only the server knows it.(private key is not shared.) And because the MITM doesn't know the private key, it cannot impersonate the server as well.

So, when a cipher suite like TLS_WITH_RSA_AES128_CBC_SHA is used, RSA is used to generate pub/pri key pair, DSA is used to sign the certificate sent by server, and once the symmetric (same) master-secret and session keys are derived by both client and server, AES128(symmetric key encryption/decryption algorithm) is used to encrypt/decrypt application data.

Hope this clarifies.

commanderdileep
  • 96
  • 3