?
Solved

SSL hand shake

Posted on 2009-12-21
7
Medium Priority
?
992 Views
Last Modified: 2012-08-14
1)When a gmail user opens gmail dot com in his web browser, the user is directed to https.
2)now the ssl hand shake goes through process-
      first the gmail client says hello
      gmail server says hello
      gmail server sends the public key certificate
      gmail server hello done
      client key exchange
      client change cipher spec
      client encrypted handshake message
      server change cipher spec
      server encrypted handshake message


now the client uses the public key to encrypt the message it sends to gmail server and gmail
server uses his private key to decrypt the message.
My question is, which key gmail server is going to use to encrypt the message( his private or public key)
and can any one explain the things happening in each of those 9 process.
0
Comment
Question by:sanfran83
  • 4
  • 2
7 Comments
 
LVL 31

Expert Comment

by:Paranormastic
ID: 26100606
The answer to the primary question is: neither.  The negotiated synchronous key will be used on both ends - the public/private key is not used past the process you just laid out.
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 26100704
I will post the breakdown of communications in the morning - if anyone else wants to jump on that feel free.
0
 
LVL 7

Expert Comment

by:askb
ID: 26101726
>>> My question is, which key gmail server is going to use to encrypt the message( his private or public key) and can any one explain the things happening in each of those 9 process?
The initial encryption/decryption takes place using  Public / Private Keys, using which a symetric key is later exchanged and latter used for encrypting and exchanging the payload. Remember in case of pub keys crypto, always the pub key is used for encrypting and the private keys are used for decrypting.

How how SSL works with https refer to the following link:
  http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

SSL Handshake:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzas.doc/sy10660_.htm

Hope this helps!
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 7

Assisted Solution

by:askb
askb earned 800 total points
ID: 26101741
>>> now the client uses the public key to encrypt the message it sends to gmail server and gmail
server uses his private key to decrypt the message.
SSL uses Pub and Priv keys for init exchange a client / server random. Later the client generate a pre-master secret and sends it the server. Now both client and server know client / server random + pre-master secret which is used to generate a master secret - which is actually becomes the shared symetric key between the client and the server. Later on the handshake is completed with establishing the master secret with the client and server which is actually used to encrypt and decrypt the payload.

Hope this helps
0
 
LVL 31

Accepted Solution

by:
Paranormastic earned 1200 total points
ID: 26105466
Here's a few other links:
MS description of SSL handshake:
http://support.microsoft.com/kb/257591

Troubleshooting SSL:
http://www.prefetch.net/articles/debuggingssl.html

The SSL v3 specification - see section 5.6:
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt



      first the gmail client says hello
      gmail server says hello
- Hopefully these 2 are self explanatory as SYN & ACK, if you need these broken down more let me know.  They start the general network session anyways - nothing encrypted yet.  this may be resent later to renogiate another session (e.g. to prevent session expiration) but can be done at any time.

*      gmail server sends the public key certificate
- Server sends his cert with the public key so the client can use it to encrypt back.  

*      gmail server hello done
- server passes the microphone to the client to talk and goes into listen mode.  

(if there was a client certificate, that would be passed here between these steps)

*      client key exchange
- The client checks the digital signatures and revocation lists to make sure it is trustworthy.
- Client starts chatting.
- Opening statement for the next step in the process.
- A pre-master token is established from the server's public key and is used for negotiation.

*      client change cipher spec
- The client uses the server's public key to encrypt what synchronous key (e.g. RC-4, 3DES, AES, etc.) it supports to use for the main session, as well as the strength.  Typically the strongest algorithm will be used by default (except Windows picks AES-128 before AES-256 for some reason), but the order can be changed (sent in order of preference, which is usually the strongest first).
- If the server supports that then they will both be happy, otherwise they keep handshaking - if you remember modems handshaking for connection speed - its like that only choosing cipher methodologies and strengths supported.  Start at the top and move down the list if no match, if no match by the end then no connection.

*      client encrypted handshake message
- A message is sent to establish the session encryption key and is encrypted with server's public key.  If accepted, it will later become the new session encryption method (synchronous key).

*      server change cipher spec
- this would be if the server did not support the client's suggested algorithm.  For example, client requests AES but server only supports up to 3DES.  Server sends best algorithm back to client as next step in handshake.  Further client and server change cipher specs may follow until agreement is reached or both lists are exhausted.
- server's private key is used to decrypt the message of suggested protocols

*      server encrypted handshake message
server accepts encrypted session key from client, decypts using server's private key, and establishes the encrypted session ID which it will relate to the client.  Since they both have the secret key and they can transfer this securely now, reducing the likelihood of an eavesdropper catching the new session and understanding the communications.  Now that they agree, the pre-master token is dropped and the new master token is used

- The certificate is now out of the picture.
- Finish is sent to complete the handshake.
0
 
LVL 31

Expert Comment

by:Paranormastic
ID: 26105661
Quick terminology:
Synchronous key/encryption - both sides use a preshared secret (a password) as the encryption and decryption method.  Examples include RC-4, DES, 3DES, AES and many more.  This is common for zip files, flash drives, etc. - you type a password to encrypt it and you type the same password to decrypt it.

Asynchronous encryption/public-private keyset - PKI / certificate stuff.  A certificate represents the identity and is trusted by the client.  The certificate contains information about the server's public key, which the client will then use to encrypt.  The server is the only place where the private key should exist, and will be used to decrypt any encrypted message from the client.

Synchoronous is much much faster than Asynch since the bit lengths are typically shorter they require less computation - this also results in smaller sizes of the ciphertext.  The security is in the secret key being secret.

Asynch is slower and requires much more CPU to do the calculations.  Since half of the keyset is public, the key lengths are much larger to slow down potential attacks.  The private key is the secure part and remains private on that server.

For SSL, email encryption, EFS, whatever - generically speaking the same type of process happens - you use the initially more secure asynch process to negotiate a common synch key and to pass the password, then everything is synch after that.
0
 

Author Closing Comment

by:sanfran83
ID: 31668650
Thanks!
0

Featured Post

What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

It’s time for spooky stories and consuming way too much sugar, including the many treats we’ve whipped for you in the world of tech. Check it out!
This article is about my experience upgrading my consulting machine to Windows 10 Version 1709 (The Fall 2017 Creator Update)
Email security requires an ever evolving service that stays up to date with counter-evolving threats. The Email Laundry perform Research and Development to ensure their email security service evolves faster than cyber criminals. We apply our Threat…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question