Chapter 8 - Electronic Mail Security

#email #security

Class: CSCE-465-63860

Internet Mail Architecture

image.png339

E-mail Components

E-mail Protocols (SMTP)

image-1.png430

Mail Access Protocols

E-mail Formats

Header Fields Defined In MIME

MIME Content Types

Type Subtype Description
Text Plain Unformatted text: may be ASCII or ISO 8859.
Enriched Provides greater format flexibility.
Multipart Mixed The different parts are independent but are to be transmitted together. They should be presented to the receiver in the order that they appear in the mail message.
Parallel Differs from Mixed only in that no order is defined for delivering the parts to the receiver.
Alternative The different parts are alternative versions of the same information. They are ordered in increasing faithfulness to the original, and the recipient's mail system should display the "best" version to the user.
Digest Similar to Mixed, but the default type/subtype of each part is message/rfc822.
Message rfc822 The body is itself an encapsulated message that conforms to RFC 822.
Partial Used to allow fragmentation of large mail items, in a way that is transparent to the recipient.
External-body Contains a pointer to an object that exists elsewhere.
Image jpeg The image is in JPEG format, JFIF encoding.
gif The image is in GIF format.
Video mpeg MPEG format.
Audio Basic Single-channel 8-bit ISDN mu-law encoding at a sample rate of 8 kHz .
Application PostScript Adobe Postscript format.
octet-stream General binary data consisting of 8-bit bytes.

MIME Transfer Encodings

7bit The data are all represented by short lines of ASCII characters.
8bit The lines are short, but there may be non-ASCII characters (octets with the high-order bit set).
binary Not only may non-ASCII characters be present but the lines are not necessarily short enough for SMTP transport.
quoted-printable Encodes the data in such a way that if the data being encoded are mostly ASCII text, the encoded form of the data remains largely recognizable by humans.
base64 Encodes data by mapping 6-bit blocks of input to 8-bit blocks of output, all of which are printable ASCII characters.
x-token A named nonstandard encoding.

Email Threads and Mitigations

Threat Impact on Purported Sender Impact on Receiver Mitigation
Email sent by unauthorized MTA in enterprise (e.g. malware botnet) Loss of reputation. valid email from enterprise may be blocked as possible spam/phishing attack. UBE and/or email containing malicious links may be delivered into user inboxes Deployment of domain-based authentication techniques. Use of digital signatures over email.
Email message sent using spoofed or unregistered sending domain Loss of reputation. valid email from enterprise may be blocked as possible spam/phishing attack. UBE and/or email containing malicious links may be delivered into user inboxes Deployment of domain-based authentication techniques. Use of digital signatures over email.
Email message sent using forged sending address or email address (i.e. phishing, spear phishing) Loss of reputation, valid email from enterprise may be blocked as possible spam/phishing attack. UBE and/or email containing malicious links may be delivered. Users may inadvertently divulge sensitive information or PII. Deployment of domain-based authentication techniques. Use of digital signatures over email.
Email modified in transit Leak of sensitive information or PII. Leak of sensitive information, altered message may contain malicious information Use of TLS to encrypt email transfer between server. Use of end-to-end email encryption.
Disclosure of sensitive information (e.g. PII) via monitoring and capturing of email traffic Leak of sensitive information or PII. Leak of sensitive information, altered message may contain malicious information Use of TLS to encrypt email transfer between server. Use of end-to-end email encryption.
Unsolicited Bulk Email (i.e. spam) None, unless purported sender is spoofed. UBE and/or email containing malicious links may be delivered into user inboxes Techniques to address UBE.
DoS/DDoS attack against an enterprises* email servers Inability to send email. Inability to receive email. Multiple mail servers, use of cloud-based email providers.

S/MIME

Summary of S/MIME Services:

Function Typical Algorithm Typical Action
Digital signature RSA/SHA-256 A hash code of a message is created using SHA-256. This message digest is encrypted using SHA-256 with the sender's private key and included with the message.
Message encryption AES-128 with CBC A message is encrypted using AES-128 with CBC with a one-time session key generated by the sender. The session key is encrypted using RSA with the recipient's public key and included with the message.
Compression unspecified A message may be compressed for storage or transmission.
E-mail compatibility Radix-64 conversion Same as Base64 To provide transparency for e-mail applications, an encrypted message may be converted to an ASCII string using radix-64 conversion.

Authentication

Confidentiality

image-2.png301

S/MIME Message Content Types

S/MIME uses the following message content types, which are defined in RFC 5652, Cryptographic Message Syntax

Cryptographic Algorithms Used in S/MIME

Function Requirement
Create a message digest to be used in forming a digital signature. MUST support SHA-256
SHOULD support SHA-1
Receiver SHOULD support MD5 for backward compatibility
Use message digest to form a digital signature. MUST support RSA with SHA-256SHOULD support Signature
-DSA with SHA-256 Scheme with
-RSASSA-PSS with SHA-256 Appendix -
-RSA with SHA-1 Probabilistic
-DSA with SHA-1 Signature
-RSA with MD5 Scheme
Encrypt session key for transmission with a message. MUST support RSA encryption
SHOULD support Optimal Asymmetric
-RSAES-OAEP Encryption Padding
-Diffie-Hellman ephemeral-static mode
Encrypt message for transmission with a onetime session key. MUST support AES-128 with CBC SHOULD support
-AES-192 CBC and AES-256 CBC
-Triple DES CBC

S/MIME Flows

image-3.png439

Pretty Good Privacy (PGP)

PGP Key Rings

PGP Key Rings:
image-4.png514

PGP Trust Model Example

image-5.png511

Domain Name System (DNS)

Resource Record Types

Type Description
A A host address. This RR type maps the name of a system to its IPv4 address. Some systems (e.g., routers) have multiple addresses, and there is a separate RR for each.
AAAA Similar to A type, but for IPv6 addresses.
CNAME Canonical name. Specifies an alias name for a host and maps this to the canonical (true) name.
HINFO Host information. Designates the processor and operating system used by the host.
MINFO Mailbox or mail list information. Maps a mailbox or mail list name to a host name.
MX Mail exchange. Identifies the system(s) via which mail to the queried domain name should be relayed.
NS Authoritative name server for this domain.
PTR Domain name pointer. Points to another part of the domain name space.
SOA Start of a zone of authority (which part of naming hierarchy is implemented). Includes parameters related to this zone.
SRV For a given service provides name of server or servers in domain that provide that service.
TXT Arbitrary text. Provides a way to add text comments to the database.
WKS Well-known services. May list the application services available at this host.

image-6.png381

DNS Security Extensions

DNSSEC RR Types

DNSSEC Chain Example

; Parent zone (.com) 
example.com. IN DS          2371 13 2 E4F7B1C...

; Child zone (example.com) 
example.com. IN DNSKEY      257 3 13 mdsswU...
example.com. IN A           93.184.216.34
example.com. IN RRSIG       A 13 2 ...
example.com. IN NSEC        mail.example.com. ..

DNS-Based Authentication of Named Entities (DANE)

Sender Policy Framework (SPF)

image-7.png392

image-8.png394x250

Common SPF Mechanisms and Modifiers

(a) SPF Mechanisms

Tag Description
ip4 Specifies an IPv4 address or range of addresses that are authorized senders for a domain.
ip6 Specifies an IPv6 address or range of addresses that are authorized senders for a domain.
mx Asserts that the listed hosts for the Mail Exchange RRs are also valid senders for the domain.
include Lists another domain where the receiver should look for an SPF RR for further senders. This can be useful for large organizations with many domains or sub-domains that have a single set of shared senders. The include mechanism is recursive, in that the SPF check in the record found is tested in its entirety before proceeding. It is not simply a concatenation of the checks.
all Matches every IP address that has not otherwise been matched.

(b) SPF Mechanism Modifiers

Modifier Description
+ The given mechanism check must pass. This is the default mechanism and does not need to be explicitly listed.
- The given mechanism is not allowed to send email on behalf of the domain.
∼ The given mechanism is in transition and if an email is seen from the listed host/IP address, that it should be accepted but marked for closer inspection.
? The SPF RR explicitly states nothing about the mechanism. In this case, the default behavior is to accept the email. (This makes it equivalent to '+' unless some sort of discrete or aggregate message review is conducted).

SPF Example

Record value for nitrogensensor.eu:

v=spf1 ip4:162.55.97.110 include:spf.azehosting.net ip4:168.119.150.59 +a +mx +ip4:185.221.37.132 +ip4:94.130.48.100 ~al

DomainKeys Identified Mail (DKIM)

image-9.png420

DKIM Example

Record value for nitrogensensor.eu:

v=DKIM1; k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgK
CAQEAyXnBvr/H2hZWDPO50O434GKZzUlf5n9m+IA
VSefpotaRf/ObIZoxCgMvNvYLKFdE1UBL1mm8KJ0r6y
BaomVoyhS90iLjIP9bm4UPNe9yexMGYuXNO9mNGSk
hRfxVNy/POalHklHnV0719FNEUnj92IWTdbxoSMtfpN
Fm52H/I9PU7exPSxDEcggzsmdnCAcMGHf32ZCmL8R
qsgE0cVpjtJfQQfc+FPB7SDm3otVB4yzL2KyW5JdN8Ey9
wrn+sff/ZL05pmNH2tFpcTXo7czl/nxvtRGFbYH+Wkw2
9w+LV8I7OPNTWGecLsLnpRsZopUAam911i12Z1eSlkN
BMgN0awIDAQAB;

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

image-10.png326

DMARC Tag and Value Descriptions

Tag (Name) Description v=(Version) Version field that must be present as the first element. By default the value is always DMARC1. p=(Policy) Mandatory policy field. May take values none or quarantine or reject. This allows for a gradually tightening policy where the sender domain recommends no specific action on mail that fails DMARC checks ( p= none ), through treating failed mail as suspicious ( p= quarantine), to rejecting all failed mail ( p=reject ), preferably at the SMTP transaction stage. aspf= (SPF Policy) Values are r (default) for relaxed and s for strict SPF domain enforcement. Strict alignment requires an exact match between the From address domain and the (passing) SPF check must exactly match the MailFrom address (HELO address). Relaxed requires that only the From and MailFrom address domains be in alignment. For example, the MailFrom address domain smtp.example.org and the From address announce@example.org are in alignment, but not a strict match. adkim = (DKIM Policy) Optional. Values are r (default) for relaxed and s for strict DKIM domain enforcement. Strict alignment requires an exact match between the From domain in the message header and the DKIM domain presented in the d= DKIM tag. Relaxed requires only that the domain part is in alignment (as in aspf). fo= (Failure reporting options) Optional. Ignore if a ruf argument is not also present. Value 0 indicates the receiver should generate a DMARC failure report if all underlying mechanisms fail to produce an aligned pass result. Value 1 means generate a DMARC failure report if any underlying mechanism produces something other than an aligned pass result. Other possible values are d (generate a DKIM failure report if a signature failed evaluation), and s (generate an SPF failure report if the message failed SPF evaluation). These values are not exclusive and may be combined. ruf= Optional, but requires the fo argument to be present. Lists a series of URIs (currently just mailto:) that list where to send forensic feedback reports. This is for reports on message specific failures. rua= Optional list of URIs (like in ruf=, using the mailto: URI) listing where to send aggregate feedback back to the sender. These reports are sent based on the interval requested using the ri= option, with a default of 86400 seconds if not listed. ri= (Reporting interval) Optional with the default value of 86400 seconds. The value listed is the reporting interval desired by the sender. pct= (Percent) Optional with the default value of 100. Expresses the percentage of a sender's mail that should be subject to the given DMARC policy. This allows senders to ramp up their policy enforcement gradually and prevent having to commit to a rigorous policy before getting feedback on their existing policy. sp= (Receiver policy) Optional with a default value of none. Other values include the same range of values as the p= argument. This is the policy to be applied to mail from all identified subdomains of the given DMARC RR.

DMAR Example

Host/Name: dmarc.example.com
Type: TXT

Value: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Summary