Lec 12

Need of SSH

• Telnet (short for "telecommunications network") is a

client/server application protocol that provides access to
virtual terminals of remote systems on local area
networks or the Internet.

• Initially designed to work within private network 

lacks modern security measures
• Transmits data in plain text on port 23
• Uses simple credential authentication

• Security vulnerabilities: Prone to session hijacking

and MITM attacks.
Secure Shell (SSH)
• Encrypted alternative to Telnet to securely access and manage remote systems over an insecure network.
• Ensures secure communication by encrypting data (confidentiality), verifying integrity, and
authenticating user and host identities through one of the following methods.
• Password: User enters a password for access.
• Public/Private Key: Server stores the user’s public key; the private key stays on the user's device.
• Certificate: Trusted CAs issue certificates to authenticate users and hosts
• Uses: Secure remote login, command execution, file transfers, and secure network backups.
How SSH Works?

Port 22

Best Practices:
• Disable Password Authentication: Use keys instead.
• Use SSH Config Files: Simplify connections and enforce settings in ~/.ssh/config.
• Limit SSH Access: Restrict IP addresses, enforce firewall rules.
• Regularly Rotate Keys: Periodically update SSH keys for enhanced security.
Basic SSH Commands
• SSH Login: ssh server_username@hostname

• Remote Command Execution: ssh server_username@hostname command

• Secure Copy (SCP): Command-line tool designed for quick file transfers
• SCP to remote server: scp [Link] server_username@hostname:/remote/path
• SCP from remote server scp server_username@hostname:/remote/[Link] /local/path

• Secure File Transfer (SFTP) is SSH based interactive file transfer protocol that allows file transfer and
file/ directory management (rename, delete, etc.)
• sftp server_username@hostname
How is SSH different from FTP and FTPS
6

 SSH: Provides secure remote access, allowing command execution.

 SFTP: Combines secure file transfer with SSH, ideal for encrypted file transfers.

 FTP: Simple but insecure file transfer protocol. Uses separate ports for commands (port 21) and data.
 FTPS: Adds SSL/TLS encryption, suitable for secure transfers.

Practical Use:
 For secure file transfers, SFTP is generally recommended because of strong security, single-port
operation for easier firewall management, and ability to resume interrupted transfers.
 FTPS can be used for its compatibility with legacy systems, regulatory compliance, familiarity with
SSL/TLS, detailed auditing capabilities, etc.
How Email Works
7

Email: username@domain is analogous to house@street

Initial Protocols used for emails:

• For sending emails:
• SMTP (Simple Mail Transfer Protocol) is a push
protocol that transfers emails from the sender’s device to
their mail server and then to the recipient’s mail server.
• For receiving emails:
• POP3 (Post Office Protocol version 3): Downloads
emails to the client, typically deleting them from the
server. Allows offline access but lacks multi-device
synchronization. (Less common)
• IMAP (Internet Message Access Protocol):
Synchronizes emails between the server and devices
without deleting them, enabling access across multiple
devices and maintaining folder structures. (Common)
How Email Works today?
8

• A user sends an email via user agent (browser or desktop app):

• For web browser (e.g., Gmail, [Link]) connection is
secured with HTTPS.
• For desktop client (e.g., Outlook, Thunderbird),
connection uses secure version of SMTP (next slide).

• Next, sender's SMTP server determines the recipient's domain

(e.g., [Link] in user@[Link]). It queries DNS to
find the MX (Mail Exchange) record of the recipient's
domain, which specifies the recipient's mail server. Finally, it
transmits the email to the recipient's mail server using SMTP.

• The recipient retrieves the email through:

• Web browser: Securely via HTTPS.
• Desktop client: Using secure POP3/ IMAP.
Securing Email Communication
9
Standard email protocols (SMTP, IMAP, POP) lack inherent security features – no
confidentiality, integrity, authentication, etc.

Secure Protocols:
• Implicit TLS (e.g., SMTPS, IMAPS, POP3S): Starts with encrypted TLS connection
from the beginning.
• StartTLS: Starts unencrypted, then upgrades to TLS. (More common)

Why is StartTLS preferred?

• Standardized by IETF for encrypting emails.
• Allows both encrypted and unencrypted connections, ensuring broader compatibility
across different clients and servers that might not yet support encryption, or for systems
that prefer to upgrade the connection once they know the other party supports encryption.
• Works seamlessly in scenarios where firewalls, middleboxes, or proxies exist as it can
work on standard ports.
STARTTLS
10

• StartTLS secures transmission between servers but

does not provide end-to-end protection. Email
remains secure during transit and storage but email
providers (e.g., Gmail) can analyze stored emails for
• Spam filtering,
• Data mining for advertising,
• Integration with services like Google Assistant.

• Note: If the recipient’s email provider does not

support TLS, the email may not be encrypted.
Clients are warned with red sign.
 Alternatives for End-to-End Encryption:
• S/MIME (Secure/Multipurpose Internet Mail Extensions):
• MIME refers to images, audio, and files,
• S/MIME provides end-to-end encryption and digital signatures for confidentiality,
integrity and authenticity,
• Uses X.509 certificates for centralized key management via trusted CAs,
• Widely used in corporate environments, with support from major email clients like
Gmail, Outlook, and Apple Mail for business use.

• PGP (Pretty Good Privacy):

• Utilizes symmetric-key and asymmetric encryption to secure emails,
• Relies on user-managed keys without a CA, offering more control but requiring
manual key exchange,
• Traditional PGP only supports text, but PGP/MIME supports MIME data,
• Lacks built-in support from major providers, but popular among privacy-focused
individuals for its independence from governments and corporations.

• Email Encryption Services like ProtonMail and Tutanota offer built-in E2E encryption.
Email Security Issues
12

Common Email threats:

• Spam: Unsolicited bulk emails that can contain malicious links.
• Malware: Viruses, ransomware, or spyware sent as attachments.
• Email Spoofing: Faking sender identity to trick recipients.
• Phishing: Fraudulent emails designed to steal sensitive information
(e.g., passwords, financial details) by tricking the recipient into
clicking malicious links or attachments. It accounts for 90% of data
breaches. Phishing emails usually:
• Creates a false sense of urgency to prompt quick action.
• Contains spelling mistakes/ awkward phrasing to bypass filters.

Consequences: Identity theft, financial loss, reputational damage.

Email Security Best Practices
13

For Service Providers: (Sign → Compress → Encrypt)

 Sign: Ensures the signature is valid by signing the original, unaltered content.
 Compress: Reduces message size efficiently. Compressing before signing invalidates the signature, and
compressing after encryption is ineffective due to the random nature of encrypted data.
 Encrypt: Secures both the message and the signature, ensuring confidentiality.

For Users:
 Use Strong Passwords: Protect accounts with unique, complex passwords.
 Enable Two-Factor Authentication: Adds extra security with a second verification step.
 Be Wary of Links and Attachments: Avoid suspicious links and attachments to prevent phishing.
 Regular Software Updates: Keep email clients and security software updated to fix vulnerabilities.
Email Dissection
14

Scenario:
• Attacker: narmeen91@[Link] (True Sender, i.e.,
the one in MailFrom field)

• Spoofed address: blackhat@[Link] (i.e., the

one in HeaderFrom field, which is visible to the
Receiver. Attacker is pretending to send email from
this address.

• Receiver: narmeen_shafqat@[Link]
 Email Dissection
15
Email Dissection – Important Header Fields
16

1. [Link] refers to the true sender address i.e., narmeen91@[Link] here

2. Return Path: Specifies where bounced emails (non-delivery reports or errors) are sent. It usually
matches the [Link] address unless specified otherwise.
3. Reply-To: An address where responses to the email will go (narmeen91@[Link]). Attackers often set
this to their own address to intercept responses.
4. X-Originating-IP - Points to the real source IP of the sender (narmeen91’s IP). But email servers may
strip out this information for privacy reasons.
5. "Mailed by" field indicates the mail server that sent the email, while "Signed by" refers to the domain
that has applied a digital signature (DKIM) to the message, ensuring its integrity (i.e., [Link]).
6. [Link] is address that the recipient sees, i.e., blackhat@[Link] (visible sender) This is often
spoofed in phishing attacks to mislead recipients.
Email Authentication Standards
17

 SPF (Sender Policy Framework):

Validates the sender's domain.

 DKIM (Domain Keys Identified Mail):

Sender signs messages with their cryptographic key, ensuring message integrity.

 DMARC (Domain-based Message Authentication, Reporting &

Conformance):
Combines SPF and DKIM to prevent spoofing and decides if the email should
go in inbox or spam folder or discarded.

They form a strong defense against spoofing but require proper setup by the
domain owner.
SPF (Sender Policy Framework)
18

SPF verifies that the sending server’s IP is

authorized to send emails for the domain in the
“MailFrom" address (true sender).

 SPF Setup by domain owner in DNS:

The sending domain owner (i.e., [Link]) sets
up an SPF record in domain’s DNS, listing IP
addresses authorized to send emails for the domain.

 SPF Check at receiver’s mail server:

Receiving server fetches SPF record for sending domain and checks if sending server's IP is authorized.
• If IP is in SPF record: Pass (email is valid). Proceed to other checks (DKIM/ DMARC)
• If IP is not in SPF record: Fail (Potential spoofing, receiver can decide to flag as spam or reject).
• If no SPF record exists, the receiving server can't verify the sender, which may increase the spam score, but
the email may still be processed depending on spam filtering policies.
SPF (Sender Policy Framework)
19

Understanding SPF Record:

• "v=spf1" is the version of the SPF record.
• "ip4:[Link]" indicates that only this IP address
is authorized to send emails for that domain.
• "–all" means that any IP address not explicitly
listed in the SPF record is not allowed to send
emails on behalf of the domain (a hard fail).

Note: A domain's SPF record can list multiple

authorized IP addresses, allowing different servers
to send emails on behalf of the domain.
DKIM (Domain Keys Identified Mail)
20

DKIM is used to verify email integrity.

 DKIM Signature: Sending server includes a DKIM

signature using its private key when sending the email.

 DKIM Verification: Receiving server fetches sending

server’s public key from DNS to verify the signature.
• If signature is true: Email is authenticated.
• If verification fails: The email may have been modified
or improperly signed, indicating potential spoofing.
• No DKIM: Email may still be delivered, but is
considered less trustworthy.

In our case, DKIM check passes because Gmail applied its

valid DKIM signature for [Link]
DMARC (Domain-based Message Authentication, Reporting & Conformance)
21
 DMARC Alignment:
DMARC ensures that the domain in the “HeaderFrom" (i.e., [Link]) aligns with the domain
used in SPF (MailFrom, i.e., [Link]) and DKIM (the signing domain, i.e., [Link]). If it aligns with
either SPF or DKIM, DMARC passes. If neither aligns, DMARC fails.

 DMARC Policy Enforcement:

a. DMARC Record present: Receiving server fetches the DMARC policy defined in [Link]'s
DNS and applies the specified action:
 None: Deliver email to the recipient.
 Quarantine: Mark the email as spam or suspicious.
 Reject: Block the email and prevent its delivery.

b. No DMARC Record: The receiving server will

skip DMARC evaluation because it doesn't have a
DMARC policy to apply. (This is our case)
Why it bypassed auth checks and landed in inbox?
22

 SPF/DKIM Checks: Since SPF and DKIM checks pass, Gmail considers the email
legitimate.

 No DMARC Record for [Link]. Hence DMARC evaluation was skipped.

 DMARC is still a relatively new standard, and many domains have not yet
implemented it. Gmail avoids rejecting emails with no DMARC record to reduce
false positives (where legitimate emails from domains without DMARC would be
rejected) and ensure compatibility with legacy infrastructure.

 Reputation-Based Filtering: Gmail uses machine learning and reputation checks

(sender reputation, previous interactions with the domain, and known spam
characteristics) to filter emails.
 Since message content appears legitimate, doesn’t include typical spam
characteristics (e.g., malicious links or phishing keywords) and recipient has
received previous legitimate emails sent via Gmail, no additional heuristics were
triggered.
Why it bypassed auth checks and landed in inbox?
23

As the last resort, if Gmail finds discrepancies between the

"HeaderFrom" and "MailFrom" addresses, it often
displays the MailFrom address next to the sender's name
in the email interface. This is meant to alert the user to
potential inconsistencies, helping them identify spoofing.
How to Prevent This?
24

1. Strengthen Email Authentication:

 Domains must publish strict SPF, DKIM and DMARC records.

2. Enable Gmail Advanced Security:

 Users can enable Enhanced Phishing and Spoofing Protection in
Gmail settings. This flags suspicious emails with mismatched
“HeaderFrom" and "MailFrom" addresses, helping prevent
spoofing attempts.

3. Monitor Headers for Mismatches:

 Check email headers to confirm if the “HeaderFrom," "Reply-To,"
and "Return-Path" fields align. Mismatches can signal spoofing.