Ports, Protocols, and Services (PPS) help us in identifying the types of applications running on a system and subsequently any potential weaknesses. This is due to that fact that, in the past, security researchers not only discovered vulnerabilities for specific applications but also, created exploits that would allow adversaries to take advantage of these weaknesses. The best option in identifying PPS would be to scan all ports

of the remote system. Despite the fact that this is true, you should be aware that scanning all 65535 ports takes a very long time. Moreover, this type of scan will surely expose your presence on the network therefore, it is best to create jobs for specific smaller port ranges.

By default, most of the tools that we are going to use scan only a small set of ports. This means that they will scan only the most common applications and services such as telnet, FTP, SSH, HTTP, etc. Be sure to experiment with all of the tools in order to see how they effectively scan ports and protocols.

The Three Way HandShake

In order to understand how to acquire information from networked assets, it is important to have a basic understanding of how Transmission Control Protocol/Internet Protocol (TCP/IP) establishes communications between two entities.  All TCP based connections begin with a simple exchange of messages called three way handshake, or three message handshake.

THREE-WAY HANDSHAKE or a TCP 3-way handshake is a process which is used in a TCP/IP network to make a connection between the server and client. It is a three-step process that requires both the client and server to exchange synchronization and acknowledgment packets before the real data communication process starts.

TCP message types

TCP Three-Way Handshake Process

TCP traffic begins with a three-way handshake. In this TCP handshake process, a client needs to initiate the conversation by requesting a communication session with the Server:

During the first step, the client sends a TCP packet to the server. This packet has the SYN flag enabled and a random sequence number set.

In the second step, the server replies by sending a packet with both the SYN and ACK flag set and contains another random sequence number.

The ACK number is always a simple increment of the SYN number sent by the client.

Finally, the client completes the synchronization by sending an ACK packet. Note that the client behaves just like the server when sending ACK packets.

This is the process that makes TCP/IP such a reliable protocol. Knowing how hosts communicate via TCP and UDP can help testers in analyzing packet traces and identifying the responses in discovery scans.

Summary

• TCP 3-way handshake or three-way handshake or TCP 3-way handshake is a process which is used in a TCP/IP network to make a connection between server and client.
• Syn use to initiate and establish a connection
• ACK helps to confirm to the other side that it has received the SYN.
• SYN-ACK is a SYN message from local device and ACK of the earlier packet.
• FIN is used for terminating a connection.
• TCP handshake process, a client needs to initiate the conversation by requesting a communication session with the Server
• In the first step, the client establishes a connection with a server
• In this second step, the server responds to the client request with SYN-ACK signal set
• In this final step, the client acknowledges the response of the Server
• TCP automatically terminates the connection between two separate endpoints.

SSL/TLS Handshake

What Is an SSL/TLS Handshake?

An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection. It determines what version of SSL/TLS will be used in the session, which cipher suite will encrypt communication, verifies the server (and sometimes also the client), and establishes that a secure connection is in place before transferring data.

As it goes with all handshakes, the SSL/TLS Handshake is where it all starts. 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. Fundamentally, the SSL handshake is nothing but a conversation between two parties (client and server) wanting to accomplish the same purpose – securing the communication with the help of symmetric encryption. Imagine this SSL Handshake Process as a dialog between the two.

Let’s see how it goes.

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.”