How does SSL handshake work?

 

• Does TLS use symmetric or asymmetric encryption?

Both.

the initial exchange is done using asymmetric.

bulk data encryption requires speed and therefore symmetric algorithms.

• Describe the process of a TLS session being set up when someone visits a secure website.

Look for the standard responses, with the client sending helo with ciphers, server responding with a public key and picking a cipher, agreement on a shared key, etc

The SSL/TLS handshake involves a series of steps through which both the parties – client and server, validate each other and start communicating through the secure SSL/TLS tunnel.

The reason it’s called a handshake is that it’s when two parties – client and server come across each other for the first time

The handshake involves a number of steps that start from validating the identity of the other party and concludes with the generation of a common key – secret key if you may call it

a conversation between two parties (client and server) wanting to accomplish the same purpose – securing the communication with the help of symmetric encryption.

Client: “Hello there. I want to establish secure communication between the two of us. Here are my cipher suits and compatible SSL/TLS version.”

Server: “Hello Client. I have checked your cipher suits and SSL/TLS version. I think we’re good to go ahead. Here are my certificate file and my public key. Check ‘em out.”

Client: “Let me verify your certificate. (After a while) Okay, it seems fine, but I need to verify your private key. What I’ll do is, I will generate and encrypt a pre-master (shared secret key) key using your public key. Decrypt it using your private key and we’ll use thing master key to encrypt and decrypt the information”

Server: “Done.”

[Now that both the parties know who they’re talking to, the information transferred between them will be secured using the master-key. Keep in mind that once the verification part is over, the encryption takes place through the master-key only. This is symmetric encryption.]

Client: “I’m sending you this sample message to verify that our master-key works. Send me the decrypted version of this message. If it works, our data is in safe hands.”

Server: “Yeah, it works. I think we’ve accomplished what we were looking for.”

Breaking Down the TLS Handshake

secret key is used to encrypt/decrypt conversation

claim1

http over ssl thus on application layer of OSI model

claim2

encryption decryption processes thus on presentation layer of OSI model

claim3 

point to point session security thus on session layer of OSI model

ssl protocol in application layer in TCP/IP model 

• Asymmetric vs symmetric encryption

The handshake itself uses asymmetric encryption – two separate keys are used, one public and one private. Since asymmetric encryption systems have much higher overhead, they are not usable to provide full-time, real-world security. Thus, the public key is used for encryption and the private key for decryption during the handshake only, which allows the two parties to confidentially set up and exchange a newly-created “shared key”. The session itself uses this single shared key to perform symmetric encryption, and this is what makes a secure connection feasible in actual practice (the overhead is vastly lower). So the full and correct answer to “Is SSL/TLS encryption asymmetric or symmetric?” is “First one, then the other.”

• What is a “cipher suite”?

The handshake itself has multiple stages, each managed according to different rules.

a series of separate back and forth negotiations (about what keys to use, how to encrypt the handshake itself, how to authenticate the handshake and so forth) the parties can agree to use a “cipher suite” – a pre-existing selection or kit of agreed-upon components. 

TLS specifications allow for quite a number of cipher suites, and the client and server will almost always have access to one they can both employ.

Basic vs mutually-authenticated handshake

Another confusing point is that the basic model we described above lets the client verify the server, and the vast majority of sessionssecured by TLS only require this.

some cipher suites will require the client to also send a certificate and public key for mutual authentication of both parties. This two-way authentication will of course add overhead to the handshake

Different sessions will have different security parameters

Each new handshake creates a new session, and the settings used in one can differ drastically from another depending on the cipher suite chosen.

Depending on the cipher suite, some steps may be added (like the requirement for two-way authentication) or absent. In fact, there are actually cipher suites that negotiate a session to use no encryption whatsoever

https://www.ssl.com/article/ssl-tls-handshake-overview/

• 12. What are the differences between HTTPS, SSL, and TLS?

HTTPS is hypertext transfer protocol and secures communications over a network. TLS is transport layer security and is a successor protocol to SSL.

https://www.springboard.com/blog/25-cybersecurity-job-interview-questions-and-answers/

• An Overview of One-Way SSL and Two-Way SSL

SSL (Secure Socket Layer) is the standard technology used for enabling secure communication between a client and sever to ensure data security & integrity. 

How One-Way SSL Works?

In one way SSL, only client validates the server to ensure that it receives data from the intended server. For implementing one-way SSL, server shares its public certificate with the clients

How Two-Way (Mutual) SSL works?

both client and server authenticate each other to ensure that both parties involved in the communication are trusted. Both parties share their public certificates to each other and then verification/validation is performed based on that.

https://tutorialspedia.com/an-overview-of-one-way-ssl-and-two-way-ssl/