XFSC-7011

NETWORKING FOUNDATION

DAY 2 NETWORK PROTOCOLS

 UDP
There are two main attributes that describe UDP (User Datagram
Protocol): simple and fast. It is a simple protocol that uses a very
straight-forward messaging structure that is similar to the message
format used by many other TCP/IP protocols.
Like TCP, UDP layers on top of IP a method of transport-layer
addressing and process identification through the use of UDP port
numbers. It does include an optional checksum capability for error-
detection, but adds virtually no other functionality.
 UDP

The User Datagram Protocol (UDP) was developed for use by appli-
cation protocols that do not require reliability, acknowledgment or
flow control features at the transport layer. It is designed to be
simple and fact, providing only transport layer addressing in the
form of UDP ports and an optional checksum capability.
UDP's task is to take data from higher-layer protocols and place it in
UDP messages, which are then passed down to the Internet Protocol
for transmission.
 UDP
The basic steps for transmission using UDP are:
1. Higher-Layer Data Transfer: An application sends a message to
the UDP software.
2. UDP Message Encapsulation: The higher-layer message is
encapsulated into the Data field of a UDP message. The headers of
the UDP message are filled in, including the Source Port of the
application that sent the data to UDP, and the Destination Port of the
intended recipient. The checksum value may also be calculated.
3. Transfer Message To IP: The UDP message is passed to IP for
transmission.
 UDP

What UDP Does Not:

UDP does not establish connections before sending data; it just
packages it and send it
UDP does not provide acknowledgments to show that data was
received.
UDP does not provide any guarantees that its messages will arrive.
UDP does not detect lost messages and retransmit them. UDP does
not ensure that data is received in the same order that they were sent.
UDP does not provide any mechanism to manage the flow of data
between devices, or handle congestion.
UDP

UDP Message
Format
 UDP

UDP is most often used by a protocol instead of TCP in two situations:

1. when an application values timely delivery over reliable delivery, and
where TCP's retransmission of lost data would be of limited or even no
value.
2. when a simple protocol is able to handle the potential loss of an IP
datagram itself at the application layer using a timer/retransmit strategy,
and where the other features of TCP are not required. UDP is also used
for applications that require multicast or broadcast transmissions, since
these are not supported by TCP.
UDP
Common UDP Applications and Server Port Assignments:
DNS Port 53 Domain Name Server
BOOTP/DHCP Port 67 or 68 Bootstrap and Dynamic Host Protocol
TFTP Port 69 Trivial File Transfer Protocol
SMNP Port 161 and 162 Simple Network Management Protocol
RIP-1/RIP-2 Port 520 and 521 Routing Information Protocol
NFS Port 2045 Network File System – now only TCP
UDP
There are some protocols that use both UDP and TCP. This is often
the case either for utility protocols that are designed to accept
connection using both transport layer protocols, or for applications
that need the benefits of TCP in some cases, but not others.
The classic example is DNS, which normally uses UDP port 53 for
simple requests and replies, which are usually short. Larger
messages requiring reliable delivery, such as zone transfers, use TCP
port 53 instead.
 TCP

Internet Protocol (IP) is the foundation upon which the other protocols
of the suite are built.
TCP (Transmission Control Protocol) provides to applications a
method of easily making use of IP, while filling in the capabilities
that IP lacks. It allows TCP/IP devices to establish and manage
connections and send data reliably, and for applications, TCP could
be considered a nice user interface to the rudimentary capabilities
of IP.
TCP
The TCP/IP protocol suite is named for the two main protocols that provides
these capabilities, allowing software to run on a network: the Transmission
Control Protocol (TCP) and the Internet Protocol (IP). IP deals with network
datagram delivery and routing, while TCP handles connections and provides
reliability.
TCP is a full-featured transport layer protocol that provides all the functions
needed by a typical application for the reliable transportation of data across
an arbitrary internetwork. It provides transport-layer addressing for application
processes in the form of TCP ports, and allows these ports to be used in
establishing connections between machines. Once connections have been
created, data can be passed bidirectionally between two devices.
TCP
The primary transport layer protocol in the TCP/IP suite is the Transmission
Control Protocol (TCP). TCP is a connection-oriented, acknowledged,
reliable, fully-featured protocol designed to provide applications with a
reliable way to send data using the unreliable Internet Protocol. It allows
applications to send bytes of data as a stream of bytes, and
automatically packages them into appropriately-sized segments for
transmission. It uses a special sliding window acknowledgment system to
ensure that all data is received by its recipient, to handle necessary
retransmissions, and to provide flow control so each device in a connection
can manage the rate at which it is sent data.
 TCP
Six main tasks that TCP performs:
1.Addressing/Multiplexing: multiplexing the data received from these different
processes so they can be sent out using the underlying network-layer protocol.
At the same time, these higher-layer application processes are identified using
TCP ports.
2.Connection Establishment, Management and Termination: TCP provides a set
of procedures that devices follow to negotiate and establish a TCP connection
over which data can travel. Once opened, TCP includes logic for managing
connections and handling problems that may result with them. When a device is
done with a TCP connection, a special process is followed to terminate it.
TCP
Data Handling and Packaging: TCP defines a mechanism by which
applications send data to it from higher layers. This data is then
packaged into messages to be sent to the destination TCP software. The
destination software unpackages the data and gives it to the application
on the destination machine.
Data Transfer: Conceptually, the TCP implementation on a transmitting
device is responsible for the transfer of packaged data to the TCP
process on the other device. Following the principle of layering, this is
done by having the TCP software on the sending machine pass the data
packets to the underlying network-layer protocol, which again normally
means IP.
TCP
Providing Reliability and Transmission Quality Services: TCP includes a set of
services and features that allow an application to consider the sending of data
using the protocol to be "reliable". This means that normally, a TCP application
doesn't have to worry about data being sent and never showing up, or arriving
in the wrong order. It also means other common problems that might arise if IP
were used directly are avoided.
Providing Flow Control and Congestion Avoidance Features: TCP allows the flow
of data between two devices to be controlled and managed. It also includes
features to deal with congestion that may be experienced during communication
between devices.
 TCP

TCP is designed to have applications

send data to it as a stream of bytes,
rather than requiring fixed-size
messages to be used.
TCP takes care of packaging these
bytes into messages called segments.
 TCP

A basic technique for ensuring

reliability in communications uses
a rule that requires a device to
send back an acknowledgment
each time it successfully receives
a transmission. It is very slow.
This system is called positive
acknowledgment with
retransmission (PAR).
 TCP

Enhanced Positive
Acknowledgment With
Retransmission
 TCP
Common ports:
20/21 FTP – Control
22 SSH Remote Login Protocol
23 Telnet
25 Simple Mail Transfer Protocol (SMTP)
53 Domain Name System (DNS)
80 HTTP
110 POP3 – Post office Protocol
143 IMAP – Internet Message Access Protocol
389 Lightweight Directory Access Protocol (LDAP)
443 HTTPS
DNS
Domain Name Server - DNS - is the TCP/IP facility that lets you use names
rather than numbers to refer to host computers. DNS uses a hierarchical naming
system that’s how folders are organized hierarchically on a Windows computer.
 DNS
Nobody knows the number of unique domains that have ever existed. The full
set of ever-existent domains is the sum of historic information held respectively
at all TLD (Top Level Domains) Registries worldwide.
Specifics:
• DNS names are not case sensitive
• The name of each DNS node can be up to 63 characters long (not
including the dot) and can include letters, numbers, and hyphens.
• A subdomain is a domain that’s beneath an existing domain.
• DNS is a hierarchical naming system that’s similar to the hierarchical folder
system used by Windows.
• The DNS tree can be up to 127 levels deep
 DNS
The administration of the Domain Name System (DNS) is structured in a hierarchy
using different managed areas or “zones”, with the root zone at the very top of
that hierarchy. Root servers are DNS nameservers that operate in the root zone.
These servers can directly answer queries for records stored or cached within the
root zone, and they can also refer other requests to the appropriate Top Level
Domain (TLD) server. A common misconception is that there are only 13 root
servers in the world. There are many more, but still only 13 IP addresses used to
query the different root server networks. Limitations in the original architecture
of DNS require there to be a maximum of 13 server addresses in the root zone.
Ultimate authority over the root zone belongs to the National Telecommunications
and Information Administration (NTIA), which is a part of the US Department of
Commerce.
DNS

These are the 13

root servers:
DNS

They can use IPv4 or IPv6 – DNS

server running on a Microsoft
Windows server :
 DNS
Report numbers from 2018

Geographical:
DNS
Hosts File
Hosts file listed the name and IP address of every host on the network. Each
computer had its own copy of the Hosts file. Precursor for DNS and it is still used
Windows c:\windows\system32\drivers\etc
Unix/Linux /etc/hosts
DNS SERVERS AND ZONES
A DNS server is a computer that runs DNS server software, helps to maintain the
DNS database, and responds to DNS name resolution requests from other
computers.
The entire DNS namespace is divided into zones, and the responsibility for each
zone is delegated to a particular DNS server. The subdomains that make up a
domain can be divided out to separate zones.
DNS
Primary and secondary servers

A primary zone is the master copy of a zone. The data for a primary
zone is stored in the local database of the DNS server that hosts the
primary zone.
A secondary zone is a read-only copy of a zone, it obtains its copy
of the zone from the zone’s primary server by using a process called
zone transfer.
 DNS

DNS query
 DNS
Zone Files and Resource Records
Each DNS zone is defined by a zone file (also known as a DNS database or a
master file). For Windows DNS servers, the name of the zone file is domain.zone.
A zone file consists of one or more resource records.
Owner TTL Class Type RDATA

Owner: The name of the DNS domain or the host that the record applies to
TTL: Also known as Time to Live; the number of seconds that the record should be
retained in a server’s cache before it’s invalidated.
Class: Defines the protocol to which the record applies IN, for the Internet protocol
Type: The resource record type
RDATA: Resource record data that is specific to each record type
 DNS
Common Resource Record Types
SOA Start of Authority Identifies a zone
NS Name Server Identifies a name server that is authoritative for the zone
A Address Maps a fully qualified domain name to an IP address
CNAME Canonical Name Creates an alias for a fully qualified domain name
MX Mail Exchange Identifies the mail server for a domain
PTR Pointer Maps an IP address to a fully qualified domain name for reverse
lookups
 DNS
SOA records
Every zone must begin with an SOA record, which names the zone and
provides default information for the zone.
MNAME The domain name of the name server that is authoritative for the
zone.
RNAME An email address (specified in domain name format; not regular
email format) of the person responsible for this zone.
SERIAL The serial number of the zone. Secondary zones use this value to
determine whether they need to initiate a zone transfer to update their
copy of the zone.
 DNS
REFRESH A time interval that specifies how often a secondary server should
check whether the zone needs to be refreshed. A typical value is 3600 (one
hour).
RETRY A time interval that specifies how long a secondary server should wait
after requesting a zone transfer before trying again. A typical value is 600 (ten
minutes).
EXPIRE A time interval that specifies how long a secondary server should keep
the zone data before discarding it. A typical value is 86400 (one day).
MINIMUM A time interval that specifies the TTL value to use for zone resource
records that omit the TTL field. A typical value is 3600 (one hour).
DNS
bcit.ca. IN SOA (
ns1.bcit.ca ; authoritative name server
webmaster.bcit.ca ; responsible person
17645 ; version number
3600 ; refresh (1 hour)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ) ; minimum TTL (1 hour)
 DNS
NS records
Name server (NS) records identify the name servers that are authoritative for the zone.
Every zone must have at least one NS record. Using two or more NS records is better
so that if the first name server is unavailable, the zone will still be accessible.
bcit.ca. IN NS ns1.bcit.ca.
bcit.ca. IN NS ns2.bcit.ca.
A records
Address (A) records are the meat of the zone file: They provide the IP addresses for
each of the hosts that you want to make accessible via DNS.
printer1 IN A 192.168.168.203
router1 IN A 207.126.127.129
www IN A 64.71.129.102
 DNS

CNAME records
A Canonical Name (CNAME) record creates an alias for a fully qualified
domain name.
ftp.bcit.ca. IN A 207.126.127.132
files.bcit.ca. IN CNAME ftp.bcit.ca.
PTR records
A Pointer (PTR) record is the opposite of an address record: It provides the fully
qualified domain name for a given address.
102.129.71.64.in-addr.arpa. IN PTR www.bcit.ca
 DNS
MX records
Mail Exchange (MX) records identify the mail server for a domain. The owner
field provides the domain name that users address mail to.
bcit.ca. IN MX 0 mail1.bcit.ca.
bcit.ca. IN MX 10 mail2.bcit.ca.
Reverse Lookup Zones
Normal DNS queries ask a name server to provide the IP address that
corresponds to a fully qualified domain name. A reverse lookup is the opposite
of a forward lookup: it returns the fully qualified domain name of a host based
on its IP address. To enable a reverse lookup for a particular IP address, you
have to create a PTR record in a reverse lookup zone. The PTR record maps the
in-addr.arpa domain name for the address to the host’s actual domain name.
 NSLOOKUP
The nslookup command is a powerful tool for diagnosing DNS problems
name Queries the current name server for the specified name.
server name Sets the current name server to the server you specify.
root Sets the root server as the current server.
set type=x Specifies the type of records to be displayed, such as A, CNAME, MX,
NS, PTR, or SOA. Specify ANY to display all records.
set debug Turns on Debug mode, which displays detailed information about each
query.
set nodebug Turns off Debug mode.
set recurse Enables recursive searches.
set norecurse Disables recursive searches.
exit Exits the nslookup program and returns you to a command prompt.
PING
Ping Command

ping is probably the most basic TCP/IP command line tool. Its main
purpose is to determine whether you can reach another computer
from your computer. It uses Internet Control Message Protocol (ICMP)
to send mandatory ECHO_REQUEST datagrams to the specified host
computer. When the reply is received back from the host, the ping
command displays how long it took to receive the response.
PING
Ping Command
The ping command sends four packets to the specified host. It displays the result
of each packet sent. Then it displays summary statistics: how many packets were
sent, how many replies were received, the error loss rate, and the approximate
round-trip time.
PING
A Ping of Death attack is a denial-of-service (DoS) attack, in which the attacker
aims to disrupt a targeted machine by sending a packet larger than the
maximum allowable size, causing the target machine to freeze or crash. The
original Ping of Death attack is less common today. While some ping packets
are very small, IP4 ping packets are much larger, and can be as large as the
maximum allowable packet size of 65,535 bytes. Some TCP/IP systems were
never designed to handle packets larger than the maximum, making them
vulnerable to packets above that size.
 PING
When a maliciously large packet is transmitted from the attacker to the target,
the packet becomes fragmented into segments, each of which is below the
maximum size limit. When the target machine attempts to put the pieces back
together, the total exceeds the size limit and a buffer overflow can occur,
causing the target machine to freeze, crash or reboot.
One solution to stop an attack is to add checks to the reassembly process to
make sure the maximum packet size constraint will not be exceeded after
packet recombination. Another solution is to create a memory buffer with
enough space to handle packets which exceed the guideline maximum.
A new Ping of Death attack for IPv6 packets for Microsoft Windows was
discovered more recently, and it was patched in mid 2013.
 TRACERT
tracert Command
The tracert command (traceroute in Unix/Linux implementations) is one of the
key diagnostic tools for TCP/IP. It displays a list of all the routers that a packet
must go through to get from the computer where tracert is run to any other
computer on the Internet. Each one of these routers is called a hop. If you can’t
connect to another computer, you can use tracert to find out exactly where the
problem is occurring.
IPCONFIG

ipconfig Command is used to display the basic IP configuration for a computer.

• ipconfig/all
• ipconfig/release
• ipconfig/renew
• ipconfig /flushdns
 DHCP
When a new host comes online, it must be assigned an IP address that’s within
the correct range of addresses for the subnet but not already in use. Although
you can manually assign IP addresses to each computer on your network, that
task quickly becomes overwhelming if the network has more than a few
computers.
DHCP - Dynamic Host Configuration Protocol - automatically configures the IP
address for every host on a network, thus assuring that each host has a valid,
unique IP address. DHCP even automatically reconfigures IP addresses as hosts
come and go.
 DHCP
Step 1. When a host computer starts up, the DHCP client software sends a
special broadcast packet, known as a DHCP Discover message.
Step 2. The DHCP server receives the broadcast DHCP Discover message and
responds by sending a DHCP Offer message.
Step 3. The client receives the DHCP Offer message and sends back a message
known as a DHCP Request message.
Step 4. When the server receives the DHCP Request message, it marks the IP
address as assigned to the client and broadcasts a DHCP Ack message.
Step 5. When the client receives the DHCP Ack message, it configures its TCP/IP
stack by using the address it accepted from the server.
DHCP - SCOPES
A scope is a range of IP addresses that a DHCP server is configured to
distribute, and a single DHCP server can serve more than one scope.
Required:
A scope name, which helps you to identify the scope and its purpose
A scope description, which lets you provide additional details about the
scope and its purpose
A starting IP address for the scope
An ending IP address for the scope
A subnet mask for the scope - dotted-decimal notation or network prefix
One or more ranges of excluded addresses
DHCP - SCOPES
Required:
One or more reserved addresses - these are addresses that will always
be assigned to a particular host
The lease duration - which indicates how long the host will be allowed to
use the IP address
The router address for the subnet - the Default Gateway address.
The domain name and the IP address of the network’s DNS servers and
WINS servers
Other specific options
WHAT IS MTA

A mail server can have many names: mail relay, mail router, Internet mailer. But
the most common alias is an MTA. This may refer to a mail transfer agent, a
message transfer agent, or a mail transport agent. No matter which name you
use, MTAs play an essential role in the Internet message handling system. They
transfer electronic mail messages between users.
A mail/message transfer agent (MTA) is a software that transfers emails
between the computers of a sender and a recipient.
 WHAT IS MTA
An MTA is just an element of the email delivery process. It receives an email
from the mail/message submission agent (MSA), which, in turn, receives it from
the mail user agent (MUA). The MUA is commonly known as an email client – an
app you use to handle the email-related operations. Once the MTA gets the
email, relaying comes into play. That’s why mail transfer agents are often called
mail relays.
WHAT IS MTA
The email can be forwarded to other MTAs if the recipient is not hosted locally.
Then it hits the mail delivery agent (MDA). This is the email’s last stopover
before it will be delivered to the recipient’s mailbox.
The email sending is carried out using SMTP (or extended SMTP), and for the
final stage (MDA to MUA), POP3 or IMAP4 is used.
MTAs do the following:
accept emails sent from mail user agents
query the MX records and select a mail server to transfer emails
send auto-response messages if an email has failed to reach the
destination
 WHAT IS MTA
Mail queueing in MTAs
Usually, MTAs use a store-and-forward model of mail handling. This means that
outgoing mail is put into a queue and waits for the recipient’s server response. An MTA
will recurrently try to send emails. If the mail fails to be delivered during the
established term, it will be returned to the mail client.
There are three major factors that email deliverability is based on:
sender’s reputation
infrastructure & authentication
content
The reputation of the domain and IP address the email is sent from is the most
important thing. When receiving mail servers identify the sender as untrustworthy, all
emails from it will end up in the spam folder, or even bounced back. MTAs can protect
and strengthen the reputation of the sender. That’s why they directly impact email
deliverability.
THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
The Simple Mail Transfer Protocol (SMTP) is a TCP/IP protocol used in sending
and receiving e-mail.
The Mail Transfer Protocol (MTP), which was first defined in RFC 772 in
September 1980. The commands of MTP are based directly on those of the FTP
Protocol.
This protocol was first defined in RFC 788, published in November 1981: the
Simple Mail Transfer Protocol (SMTP).
The only part of the e-mail system for which SMTP is not used is the final
retrieval step by an e-mail recipient.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
The TCP/IP electronic mail communication model describes the way e-mail
messages are conveyed from the sender to the recipient. In most cases, this
involves the sender's client machine sending the e-mail to its local SMTP server,
which in turn sends it to the recipient's local SMTP server, and finally to the
recipient's local host.
The creation of DNS radically changed how e-mail delivery worked. DNS
includes support for a special mail exchanger (MX) record that allows easy
mapping from the domain name in an e-mail address to the IP address of the
SMTP server that handles mail for that domain.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

SMTP communication is simpler and more direct.

The sending SMTP server uses DNS to find the MX record of the domain to
which the e-mail is addressed.
This gives the sender the DNS name of the recipient's SMTP server. This is
resolved to an IP address, and a connection can be made directly from the
sender's SMTP server to the recipient's to deliver the e-mail.
While SMTP still supports relaying, direct email delivery using MX records is
faster and more efficient.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

Each transfer of an e-mail

message between SMTP
servers involves the
establishment of a TCP
connection and then the
transfer of the e-mail
headers and body using
the SMTP mail transfer
process.
THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
The SMTP mail transaction process itself consists of three steps:

1. Transaction Initiation and Sender Identification: The SMTP

sender tells the SMTP receiver that it wants to start sending a
message, and gives the receiver the e-mail address of the message's
originator.
2. Recipient Identification: The sender tells the receiver the e-
mail address(es) of the intended recipients of the message.
3. Mail Transfer: The sender transfers the e-mail message to the
receiver.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

All SMTP communication is

done using the TCP.
The SMTP sender establishes a
SMTP session with the SMTP
receiver. Once the session is
established, mail transactions
can be performed, to allow
mail to be sent between the
devices. When the SMTP
sender is done, it terminates
the connection.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
MAIL FROM:<john@originator.net>
250 <john@originator.net> ... Sender ok
RCPT TO:<jane@destination.net>
250 <jane@destination.net> ... Recipient ok
DATA
354 Enter mail, end with ". " on a line by itself
From: John Sender <john@originator.net>
To: Jane Receiver <jane@destination.net>
Date: Sun, 1 Sep 2020 14:17:31 -0700
Subject: Lunch tomorrow
Hey Jane,
Let’s meet for lunch tomorrow.
John
.
250 OK
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
After an SMTP session is established, e-mail messages are sent using the SMTP
mail transaction process. The SMTP sender starts the transaction by identifying
the sender of the e-mail, and then specifying one or more recipients. The e-mail
message itself is then transmitted to the SMTP receiver. Each e-mail is sent a
separate transaction.
SMTP Security Issues - The theme is a common one in TCP/IP: a lack of security
in how a protocol is implemented. SMTP doesn’t have any real security
mechanism, the original relaying model of SMTP communication is entirely
designed around the idea of "cooperation" and "trust" between servers.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
Encrypt the SMTP communication using SSL/TLS handshake:
The handshake consists of several steps and it goes as follows:
The email client sends a “hello” message in which it states which SSL/TLS
versions it’s compatible with and the encryption types it supports.
The server says ‘“hello” back but its response is different. It includes its TLS
Digital Certificate and its public encryption key.
The email client verifies if the certificate is legitimate. If so, it proceeds with
generating a Shared Secret Key with the server’s public encryption key it just received
two steps ago.
The server then decrypts the received Shared Secret Key.
If everything went smoothly, both sites can now use this Shared Secret Key to
encrypt and decrypt messages sent between each other.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

Opportunistic vs Forced TLS. STARTTLS

For a Handshake to happen in the first place, the connection between both sides needs
to be established. TLS comes with the choice of two different approaches to
establishing communication:
With Opportunistic (Explicit) TLS, an email client during a Handshake will tell
an email server that it wants to talk but in private. In other words, it will suggest a
change from a plain, not encrypted SMTP connection to a TLS-encrypted connection. If
the attempt fails, however, it will start the transmission in plain text, without any
encryption applied.
With Forced (Implicit) TLS, an email client will demand that they talk in private
(and use the encrypted connection) An email server will then respond whether such an
arrangement works for it or not. If it’s not compatible with the version of TLS used by
the client, doesn’t support TLS at all or the connection fails, the transmission will be
stopped and the email won’t be moved any further.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
End-to-end encryption methods
S/MIME
Secure/Multipurpose Internet Mail Extensions is a very popular encryption
method. It relies on asynchronous encryption and again, a set of a public and a
private key. As was the case with TLS, a sender willing to encrypt a message
uses a recipient’s public key. When a message is received, a recipient utilizes
his/her own private key to see the content of an email. S/MIME also allows you
to add a digital signature to an email, certifying that you’re really a sender.
This helps to prevent spoofing.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

PGP
Pretty Good Privacy is probably the most popular encryption method and has
been around since the early 90s. It’s not only used to encrypt emails but also
files, directories, and entire disk partitions. Email-wise, the way it works is no
different than S/MIME. It also relies on the combination of private and public
keys but an encrypted data is even more difficult to crack. PGP uses the mix of
data compression, public-key cryptography and hashing to achieve a nearly
unbreakable string of characters representing the protected data. To validate
the sender, their private key is also used to certify the ownership of an account.
Since 1997, PGP is available as a non-proprietary standard called OpenPGP
and everyone is free to implement it into their software.
 DOMAIN SPOOFING
Domain spoofing, a common form of phishing, occurs when an attacker appears
to use a company’s domain to impersonate a company or one of its employees.
This can be done by sending emails with false domain names which appear
legitimate, or by setting up websites with slightly altered characters that read
as correct. Commonly, a spoof website or email will use logos, or any other kind
of accurate visual design to effectively imitate the styling and branding of a
legitimate enterprise or business. Users will commonly be prompted to enter
financial details or other sensitive data, trusting that they are being sent to the
right place.
 DOMAIN SPOOFING
Email Spoofing: forging of an email header so that the message seems to originate
from someone or somewhere different from the actual source. Email spoofing is a
scheme used in both phishing and spam campaigns because users don't want to open
an email if they don’t trust the legitimacy of the source. The purpose of email spoofing
is to trick recipients into opening, or even corresponding with a solicitation.
Website spoofing: Website spoofing is the act of building a fake website with the goal
of misleading users, gaining their trust, and assuming the identity of a legitimate group
or organization. The spoof website will frequently adopt the design of the target
website and sometimes mimic the URL with alternate characters. A more sophisticated
attack can involve the perpetrator building a ‘shadow’ version of the World Wide
Web by routing all of the user’s web traffic through the attackers console. This type of
attack captures all of the victims sensitive information. Another method used by domain
spoofing attackers is to use a cloaked URL. By using domain forwarding, or inserting
control characters, the URL can appear to be genuine while concealing the address of
the actual website.
 DOMAIN SPOOFING
Email spoofing is possible because the Simple Mail Transfer Protocol (SMTP) does not provide a
mechanism for address authentication.
Sender Policy Framework (SPF): an email validation system, SPF allows domain
managers to authorize individual hosts to use a domain in email. This list of approved domain
names in protected and can be used to verify authenticity.
Domain-based Message Authentication, Reporting and Conformance (DMARC): is an
email authentication protocol based on reporting and enforcement components. Built on two
components, reporting and enforcement. Through reporting, DMARC can automate authenticity
verification, and alert administrators to false email domains immediately. When false domains
are used DMARC will stop the email from entering the inbox.
DomainKeys Identified Mail: (DKIM) which provides a way to validate a domain name
identity associated with a message. When a message is built, a digital signature is added to the
email to ensure authenticity. DKIM does not offer filtering capabilities but can be used to
guarantee legitimacy of the message.
Sender ID (SID): a protocol based largely on SPF and promoted by Microsoft, SID is
built into exchange servers, by reading the SMTP header. The service the queries the DNS
records to verify the sender's address.
THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

Prevent spoofing of your communication:

SPF is used to identify a sender by uploading to the DNS records the IP
addresses used to send emails on behalf of a given domain. The receiving
client, before delivering a message, checks if the right address was used and
might discard a message if it detects any abnormalities.
DKIM is a digital certificate that’s sent with an email. It allows a recipient of a
message to verify if the content of an email or headers were not modified
(forged) during a transmission. Failed DKIM test affects the deliverability of a
message and might be a reason for it to skip an inbox.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

DMARC is the most sophisticated of all three methods and it leverages the other
two methods to perform additional checks. It’s the only method that except for
running a test, can also suggest to a receiving server what to do if a message
fails a check.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
Sender Policy Framework or SPF
SPF is a protocol according to which the mail servers decide whether to receive or
reject an incoming email. The decision is made using the SPF information in TXT records
as for the list of authorized IP addresses within a particular domain. If the email has
been sent from one of these addresses, it’s not forged and can be let in.
Creating an SPF record. This establishes an authentication policy and defines
mail servers authorized to send emails from a particular domain.
DNS lookup. An incoming message is being verified in the DNS. The domain
name should be listed as the “envelope from” address. Then, the inbound server checks
whether the IP address the email is sent from is authorized in the SPF record. If it
doesn’t match any address present in the record, the SPF authentication is marked as
failed.
Authentication outcome. The mail server either delivers, flags, or rejects the
message based on the rules specified in the SPF record (and a multitude of other
factors).
THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

DomainKeys Identified Mail (DKIM) is a digital signature that’s added to every

email sent from a given email address. It’s not a typical signature you expect to
see on the bottom of a corporate email. It’s a seemingly random set of
characters that are hidden in the source code of an email – a place where
people don’t usually look but servers accepting incoming emails definitely will.
 THE SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
DMARC (Domain-based Message Authentication Reporting and Conformance) is the
most complicated method.
With DMARC, a domain owner can specify its own authentication procedure (known as
a DMARC policy). Using it, they instruct an incoming server on what to do if an email
fails to pass the DMARC test. Finally, the policy can also provide reports with the
details of each check to improve processes and provide immediate warning if anyone
spoofs the account.
DMARC will succeed in the following scenarios:
If only one of the authentications is set up, its check must be successful along
with a respective alignment test
If both methods (DKIM and SPF) are set up, either of them needs to be
successful with the respective alignment test, but not both are required
 CLIENT EMAIL PROTOCOLS

TCP/IP Post Office Protocol (POP/POP3)

One of the access methods is the simple offline access model, where a client
device accesses a server, retrieves mail and deletes it from the server. The Post
Office Protocol (POP) was designed for quick, simple and efficient mail access.
In 1988, RFC 1081 was published, describing version 3 of the Post Office
Protocol (POP3). By this time, the personal computer (PC) was transitioning from
a curiosity to a place of importance in the worlds of computing and networking.
POP3 was based closely on POP2, but refined and enhanced with the idea of
providing a simple and efficient way for PCs and other clients not normally
connected to the Internet to access and retrieve e-mail.
 CLIENT EMAIL PROTOCOLS
POP3 is a regular TCP/IP client/server protocol. To provide access to
mailboxes, POP3 server software must be installed and continuously running on
the server where the mailboxes are located.
POP3 uses the Transmission Control Protocol (TCP) for communication, to ensure
the reliable transfer of commands, responses and message data. POP3 servers
"listen" on well-known port number 110 for incoming connection requests from
POP3 clients. After a TCP connection is established, the POP3 session is
activated. The client sends commands to the server, which replies with responses
and/or e-mail message contents.
 CLIENT EMAIL PROTOCOLS

User
Authentication
Process
CLIENT EMAIL PROTOCOLS
IMAP (Internet Message Access Protocol) – Is a standard protocol for accessing
e-mail from your local server. IMAP is a client/server protocol in which e-mail is
received and held for you by your Internet server. As this requires only a small
data transfer this works well even over a slow connection such as a modem.
Only if you request to read a specific email message will it be downloaded
from the server. You can also create and manipulate folders or mailboxes on the
server, delete messages etc.
IMAP4 uses the Transmission Control Protocol (TCP) for communication. This
ensures that all commands and data are sent reliably and received in the
correct order. IMAP4 servers listen on well-known port number 143 for incoming
connection requests from IMAP4 clients. After a TCP connection is established,
the IMAP4 session begins
 CLIENT EMAIL PROTOCOLS
This is the usual sequence for an IMAP session:
1. Not Authenticated State: The session normally begins in this state after a TCP connection is
established, unless the special IMAP pre-authentication feature has been used. The client at this
point cannot really do much aside from providing authentication information so it can move to
the next state.
2. Authenticated State: The client has completed authentication, either through an authentication
process in the prior state or through pre-authentication. The client is now allowed to perform
operations on whole mailboxes. The client must select a mailbox before individual message
operations are permitted.
3. Selected State: After a mailbox has been chosen, the client is allowed to access and
manipulate individual messages within the mailbox. When the client is done with the current
mailbox it can close it and return to the Authenticated state to select a new one to work with, or
can log out to end the session.
4. Logout State: The client may issue a Logout command from any of the other states to request
that the IMAP session be ended. The session may also enter this state if the session inactivity
timer expires. The server sends a response and the connection is terminated.
CLIENT EMAIL
PROTOCOLS
IMAP Status
CLIENT EMAIL PROTOCOLS
MAPI stands for Messaging Application Programming Interface. MAPI is a
proprietary Microsoft protocol that allows the Microsoft Outlook email client to
fully utilize all of the features of an Exchange server including email, shared
address books, calendars and public folders. When Outlook is configured as a
MAPI client, also known as an Exchange client, email is stored in the cloud on
Exchange secure mail server with a copy on your computer. Messages retained
in the cloud are accesible via webmail from any internet connected computer.
With MAPI, you can move messages from the cloud into a local file on your
computer called a .PST file, a process through which copies of messages are
deleted from the cloud and stored on your computer. This can allow for valuable
storage space and help you create backups of your business-critical emails.
 CLIENT EMAIL PROTOCOLS
MAPI was designed to be used exclusively on the internal network, and it was
created even before the current Internet existed. It just defined a series of
remote procedure calls (RPC) that are also very old and did not address any
security concerns. These problems made it particularly unsafe to make it
available on the Internet.
To be able to connect to mail servers across the internet the MAPI protocol was
encapsulated in protocols that can be secured over internet.
CLIENT EMAIL PROTOCOLS
RPC over HTTP
CLIENT EMAIL PROTOCOLS
MAPI over HTTP
CLIENT EMAIL PROTOCOLS

Internet headers
In Outlook client you
select the message,
and from the top
menu select File:
CLIENT EMAIL PROTOCOLS

This is where you find the

Internet headers:
CLIENT EMAIL PROTOCOLS

Hotmail
CLIENT EMAIL PROTOCOLS

Hotmail:
Select
message
source:
CLIENT EMAIL PROTOCOLS
Gmail
 CLIENT EMAIL PROTOCOLS
A message send from gmail.com to shaw.ca
Local Mail Transfer Protocol (LMTP) – internal uses port 24 usually
 CLIENT EMAIL PROTOCOLS
We check if the sender’s SMTP IP address is the real one:
CLIENT EMAIL PROTOCOLS
SMTP signatures
CLIENT EMAIL PROTOCOLS
This is the message:
CLIENT EMAIL PROTOCOLS
Message from Outlook client shaw.ca to gmail.com
 CLIENT EMAIL PROTOCOLS
Sender information
CLIENT EMAIL PROTOCOLS
More information
CLIENT EMAIL PROTOCOLS

The message:
EMAIL HEADERS

A “Bad” email
EMAIL HEADERS

When you hover your mouse on ”Verify account”: the address is

authamazonmanage.partrespects.com/tcn/tcn7CZ48 – location of malware

Sender
Destination
EMAIL HEADERS

Sender IP:
209.85.128.67
 EMAIL HEADERS

SMTP information
between
Gmail and Hotmail
 EMAIL HEADERS

Return Path:
IP address of the receiver
20.52.47.26
 EMAIL HEADERS

SPAM filters
Whois.net:
EMAIL HEADERS

Anti SPAM info

DNS lookup:
 EMAIL HEADERS

Anti SPAM info

EMAIL HEADERS

Sender:
Home depot

All the links

point to:
EMAIL HEADERS

Receiving information
EMAIL HEADERS

Sender
EMAIL HEADERS
EMAIL HEADERS

Tenant Microsoft
EMAIL HEADERS

AntiSPAM
Results:
 SPEAR PHISHING
Spear phishing is a personalized phishing attack that targets a specific
organization or individual. These attacks are carefully designed to elicit a
specific response from a specific target. Attackers invest time in researching
their targets and their organizations to craft a personalized message, often
impersonating a trusted entity. All this makes the message look trustworthy to
the recipient.
To increase success rates, these attacks often convey a sense of urgency to get
their victims to react. They may be asked to wire money right away, to open
malicious attachments, or to click on a link that takes them to a phishing site that
requires them to provide login credentials or other sensitive data.
The data gathered can be used to access existing business or personal accounts
with fraudulent intent.
 SPEAR PHISHING

Business Email Compromise (BEC): This is also known as CEO fraud, whaling, and
wire transfer fraud. In a BEC attack, criminals impersonate an employee, usually
an executive or manager, within the organization. Using convincing details and
giving plausible reasons, they instruct their targets - who are often employees
with access to company finances or personal information - to wire money or to
send sensitive data such as financial information about customers, employees, or
partners. These attacks utilize social engineering and compromised accounts,
and they typically include no malicious attachments or links.
 SPEAR PHISHING

Impersonation: This includes a large number of spear-phishing attacks that

impersonate a trusted entity such as a well-known company or a commonly used
business app such as Office 365, Gmail, or DocuSign. They may also
impersonate a trusted colleague or business partner. These attacks typically try
to get recipients to give up account credentials or click on malicious links. For
example, you might receive an email claiming your account has been frozen and
giving you a link to reset your password. If you click, you’ll go to a fake portal
and enter your credentials. They can use that access to steal confidential data,
conduct financial fraud using your account, or launch a more targeted attack
within your organization.
 SPEAR PHISHING

Technology: Anti-phishing solutions use alternative methods to spot and block

spear-phishing attempts. One approach that is shown to be effective uses
machine learning to analyze normal communication patter 8ns within your
organization. This allows the solution to spot anomalies that may indicate an
attack. You should choose a solution that, at a minimum, includes:
Anti-spoofing functionality to help detect impersonation attempts
Account-takeover protection to block attacks from compromised accounts
Social-engineering attack prevention to detect anomalies in email
headers, senders, or body that indicate malicious intent
 SPEAR PHISHING
Security Awareness: Many organizations employ homegrown or low-tech security
awareness training to make staff more able to spot and report phishy emails. However,
today’s advanced computer-based training programs are dramatically more effective.
The best, most effective programs include:
Phishing Simulation to evaluate and identify users that are more vulnerable to
socially engineered attacks
Security Training to proactively detect and report phishing attacks, lowering
the risk of future attacks
Multi-vector simulation training that includes email, SMS, voicemail, and
portable-media
Reporting and Insight to detect trends and patterns and assess the
effectiveness of security awareness training
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
The World Wide Web (WWW) began in 1989 as a project designed to
facilitate the representation of relationships between documents and the
sharing of information between researchers. A researcher at CERN, Tim
Berners-Lee, proposed the idea of creating a "web" of electronically-
linked documents. The rapidly-growing Internet was the obvious conduit
for this project. He designed the first version of the Hypertext Transfer
Protocol (HTTP) for TCP/IP in 1990. He was also responsible for
developing or co-developing several of the other key concepts and
components behind the Web, such as Uniform Resource Identifiers (URls)
and the Hypertext Markup Language (HTML).
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
Major Functional Components of the Web
HyperText Markup Language (HTML): A text language used to
define hypertext documents. The idea behind HTML was to add
simple constructs, called tags, to regular text documents, to enable
the linking of one document to another, as well as to allow special
data formatting and the combining of different types of media.
HTML has become the standard language for implementing
information in hypertext, and has spawned the creation of numerous
other related languages.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

Hypertext Transfer Protocol (HTTP): The TCP/IP application-layer

protocol that implements the World Wide Web, by enabling the
transfer of hypertext documents and other files between a client
and server. HTTP began as a very crude protocol for transferring
HTML documents between computers, and has evolved to a full-
featured and sophisticated messaging protocol. It supports transfers
of many kinds of documents, streaming of multiple files on a
connection, and various advanced features including caching,
proxying and authentication.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

Uniform Resource Identifiers (URls): A method of defining labels that

identify resources on an internet so that they can be easily found
and referenced. URls were originally developed to provide a means
by which the users of the Web could locate hypertext documents so
they could be retrieved. URls are actually not specific to the Web,
though they are most often associated with the Web and HTTP.
Uniform Resource Locators (URLs) are a subset of Uniform Resource
Identifiers (URls). The terms are often used interchangeably in World
Wide Web discussions.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

HTTP/1.1 – current version from June 1999 – working on version 2.

Important improvements in version 1.1 are:
Multiple Host Name Support: In HTTP/1.0, there was no way to
specify the host name of the server to which the client needed to
connect. As a result, the Web server at a particular IP address could
only support one domain name. HTTP/1.1 allows one Web server to
handle requests for dozens or even hundreds of different virtual
hosts.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
Persistent Connections: HTTP/1.1 allows a client to send multiple requests for
related documents to a server in a single TCP session. This greatly improves
performance over HTTP/1.0, where each request required a new connection to
the server.
Partial Resource Selection: In HTTP/1.1, a client can ask for only part of a
resource rather than the entire document, which reduces the load on the server
and saves transfer bandwidth.
Better Caching and Proxying Support: HTTP/1.1 includes many provisions to
make caching and proxying more efficient and effective than they were in
HTTP/1.0. These techniques can improve performance by providing clients with
faster replies to their requests while reducing the load on servers, as well as
enhancing security and implementing other functionality.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

Content Negotiation: A negotiation feature was added that allows

the client and server to exchange information to help select the best
resource or version of a resource when multiple variants are
available.
Better Security: HTTP/1.1 defines authentication methods and is
generally more "security aware" than HTTP/1.0 was.
HYPERTEXT TRANSFER PROTOCOL (HTTP)
HTTP Operational Model and Client/Server Communication
The Hypertext Transfer Protocol is the application-layer protocol
that implements the World Wide Web. While the Web itself has
many different facets, HTTP is only concerned with one basic
function: the transfer of hypertext documents and other files from
Web servers to Web clients. In terms of actual communication, clients
are chiefly concerned with making requests to servers, which
respond to those requests.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
Basic HTTP Client/Server Communication
In its simplest form, the operation of HTTP involves only an HTTP client, usually a Web
browser on a client machine, and an HTTP server, more commonly known as a Web
server. After a TCP connection is created, these two steps follow:
Client Request: The HTTP client sends a request message formatted according to the
rules of the HTTP standard-an HTTP Request. This message specifies the resource that
the client wishes to retrieve or includes information to be provided to the server.
Server Response: The server reads and interprets the request. It takes action relevant
to the request and creates an HTTP Response message, which it sends back to the client.
The response message indicates whether the request was successful, and may also
contain the content of the resource that the client requested, if appropriate.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

HTTP is a client/server-oriented, request/reply protocol. Basic

communication consists of an HTTP Request message sent by an HTTP
client to an HTTP server, which returns an HTTP Response message
back to the client.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
Intermediaries and the HTTP Request/Response Chain
Intermediaries are devices such as proxies, gateways or tunnels that are
used to improve performance, provide security or perform other
necessary functions for particular clients or servers.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

The normal HTTP communication model is changed through the

application of caching to client requests.
The client itself will cache recently-accessed Web documents so that
if the user asks for them again they can be displayed without even
making a request to a server. If a request is in fact required, any
intermediary device can satisfy a request for a file if the file is in its
cache.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

HTTP/0.9 and HTTP/1 .0 only supported transitory connections between

an HTTP client and server, where just a single request and response could
be exchanged on a TCP connection. This is very inefficient for the modern
Web, where clients frequently need to make dozens of requests to a
server. HTTP/1.1 operates by default using persistent connections: once a
TCP connection is established, the client can send many requests to the
server and receive replies to each in turn. This allows files to be retrieved
more quickly, and conserves server resources and Internet bandwidth. The
client can even pipeline its requests, sending the second one immediately,
without having to first wait for a reply to the first one.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
HTTP Generic Message Format
All of the communication between devices using the Hypertext
Transfer Protocol takes place via HTTP messages, of which there are
only two types: requests and responses. Clients usually send requests
and receive responses, while servers receive requests and send
responses. Intermediate devices such as gateways or proxies may
send and receive both types of message. All HTTP messages are
created to fit a message structure that the standard calls the generic
message format. HTTP messages are similar in construction to e-mail
messages but do not strictly follow all of the e-mail or MIME format
requirements.
HYPERTEXT TRANSFER PROTOCOL (HTTP)
The HTTP generic message format is as follows:
<start-line> # nature of the message in the form of a method
<message-headers> # optional only host header must exist
<empty-line>
[<message-body>] # carries an entity as an error message
[<message-trailers>] # same as headers except for their position
HYPERTEXT TRANSFER PROTOCOL (HTTP)
HTTP Request Message Format
Most used methods: GET, HEAD and POST ( 8 in total)
 HYPERTEXT TRANSFER PROTOCOL (HTTP)

HTTP Response Message Format

The status code is a three-digit number that indicates the formal
result that the server is communicating to the client:
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
Status codes
1xx Informational message Provides general information; does not
indicate success or failure of a request.
2xx Success The method was received, understood and
accepted by the server.
3xx Redirection The request did not fail outright, but additional
action is needed before it can be successfully completed.
4xx Client Error The request was invalid, contained bad syntax or
could not be completed for some other reason that the server believes was the
client's fault
5xx Server Error The request was valid, but the server was unable
to complete it due to a problem of its own.
 HYPERTEXT TRANSFER PROTOCOL (HTTP)
HTTP Authentication Methods
Basic Authentication: This is a conventional user/password type of authentication.
When a client sends a request to a server that requires authentication to access a
resource, the server sends a response to the client's initial request that contains a
WWW-Authenticate header. The client then sends a new request containing the
Authorization header, which carries a base64-encoded username and password
combination.
Digest Authentication: Basic authentication is not considered strong security
because it sends credentials "in the clear", which means that they can be
intercepted. Digest authentication uses the same headers as basic authentication,
but employs more sophisticated techniques, including encryption, that protect
against a malicious person "snooping" credentials information
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)

Hypertext transfer protocol secure (HTTPS) is the secure version of HTTP,

which is the primary protocol used to send data between a web browser
and a website. HTTPS is encrypted in order to increase security of data
transfer. This is particularly important when users transmit sensitive data,
such as by logging into a bank account, email service, or health insurance
provider.
HTTPS uses an encryption protocol to encrypt communications. The
protocol is called Transport Layer Security (TLS), although formerly it was
known as Secure Sockets Layer (SSL). This protocol secures communications
by using what’s known as an asymmetric public key infrastructure.
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)

This type of security system uses two different keys to encrypt

communications between two parties:
The private key - this key is controlled by the owner of a website
and it’s kept private. This key lives on a web server and is used to
decrypt information encrypted by the public key.
The public key - this key is available to everyone who wants to
interact with the server in a way that’s secure. Information that’s
encrypted by the public key can only be decrypted by the private
key.
HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)

HTTPS prevents websites from having their information broadcast in a way that’s
easily viewed by anyone snooping on the network. When information is sent
over regular HTTP, the information is broken into packets of data that can be
easily “sniffed” using free software.
With HTTPS, traffic is encrypted such that even if the packets are sniffed or
otherwise intercepted, they will come across as nonsensical characters.
Before encryption: This is a string of text that is completely readable
After encryption:
ITM0IRyiEhVpa6VnKyExMiEgNveroyWBPlgGyfkflYjDaaFf/Kn3bo3OfghBPDWo
6AfSHlNtL8N7ITEwIXc1gU5X73xMsJormz
HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
HTTPS is not a separate protocol from HTTP. It is simply using TLS/SSL
encryption over the HTTP protocol. HTTPS occurs based upon the
transmission of TLS/SSL certificates, which verify that a particular
provider is who they say they are.
When a user connects to a webpage, the webpage will send over its SSL
certificate which contains the public key necessary to start the secure
session. The two computers, the client and the server, then go through a
process called an SSL/TLS handshake, which is a series of back-and-forth
communications used to establish a secure connection.
HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
TLS Handshake
TLS is an encryption protocol designed to secure Internet communications.
A TLS handshake is the process that kicks off a communication session that
uses TLS encryption. During a TLS handshake, the two communicating sides
exchange messages to acknowledge each other, verify each other,
establish the encryption algorithms they will use, and agree on session
keys. TLS handshakes are a foundational part of how HTTPS works. SSL,
or Secure Sockets Layer, was the original encryption protocol developed
for HTTP. SSL was replaced by TLS, or Transport Layer Security, some time
ago. SSL handshakes are now called TLS handshakes, although the "SSL"
name is still in wide use.
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)

A TLS handshake takes

place whenever a user
navigates to a website
over HTTPS.
TLS handshakes occur
after a TCP connection
has been opened via a
TCP handshake.
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
During the course of a TLS handshake, the client and server together
will do the following:
Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
Decide on which cipher suites they will use
Authenticate the identity of the server via the server’s public key
and the SSL certificate authority’s digital signature
Generate session keys in order to use symmetric encryption after
the handshake is complete
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
RSA key exchange algorithm
1. The 'client hello' message: The client initiates the handshake by sending a
"hello" message to the server. The message will include which TLS version the
client supports, the cipher suites supported, and a string of random bytes known
as the "client random."
2. The 'server hello' message: In reply to the client hello message, the server
sends a message containing the server's SSL certificate, the server's chosen
cipher suite, and the "server random," another random string of bytes that's
generated by the server.
3. Authentication: The client verifies the server's SSL certificate with the
certificate authority that issued it. This confirms that the server is who it says it is,
and that the client is interacting with the actual owner of the domain.
HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)

RSA key exchange algorithm

4. The premaster secret: The client sends one more random string of
bytes, the "premaster secret." The premaster secret is encrypted with
the public key and can only be decrypted with the private key by
the server. (The client gets the public key from the server's SSL
certificate.)
5. Private key used: The server decrypts the premaster secret.
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
6. Session keys created: Both client and server generate session keys
from the client random, the server random, and the premaster
secret. They should arrive at the same results.
7. Client is ready: The client sends a "finished" message that is
encrypted with a session key.
8. Server is ready: The server sends a "finished" message encrypted
with a session key.
9. Secure symmetric encryption achieved: The handshake is
completed, and communication continues using the session keys.
HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
Diffie-Hellman handshake proceeds as follows:
1. Client hello: The client sends a client hello message with the protocol version,
the client random, and a list of cipher suites.
2. Server hello: The server replies with its SSL certificate, its selected cipher
suite, and the server random. In contrast to the RSA handshake described above,
in this message the server also includes the following
3. Server's digital signature: The server uses its private key to encrypt the client
random, the server random, and its DH parameter(Diffie-Hellman algorithm uses
exponential calculations to get the same premaster secret). This encrypted data
functions as the server's digital signature, establishing that the server has the
private key that matches with the public key from the SSL certificate.
HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)
Diffie-Hellman handshake proceeds as follows:

4. Digital signature confirmed: The client decrypts the server's digital

signature with the public key, verifying that the server controls the
private key and is who it says it is. Client DH parameter: The client
sends its DH parameter to the server.
5. Client and server calculate the premaster secret: Instead of the
client generating the premaster secret and sending it to the server,
as in an RSA handshake, the client and server use the DH
parameters they exchanged to calculate a matching premaster
secret separately.
 HYPERTEXT TRANSFER PROTOCOL SECURE (HTTPS)

Diffie-Hellman handshake proceeds as follows:

6. Session keys created: Now, the client and server calculate session
keys from the premaster secret, client random, and server random,
just like in an RSA handshake.
7. Client is ready
8. Server is ready
9. Secure symmetric encryption achieved