E-mail security

Question 1

MHS

Answer 1

Message handling system: used worldwide.

MUA (Message User Agent): SW used by user to send mail.

MSA (Message Submission Agent): SW module with task of injecting the mail into the transport system.

MTA (Message Transfer Agent): the mail transport system is composed of MTAs arranged in a chain. The mail is given to the next MTA until it reaches destination.

Upon reaching destination, the email will be stored in the MS (Message Store).

Receiver will read the mail using MUA when they want. After replying, the reverse MSA will be different than the sending MSA, MTA chain will be different.

Question 2

Email client-server mode

Answer 2

User has a program that has configured to have mail server or outgoing mail server. It uses SMTP to send mail, the user can close the program and the mail will be submitted, but it does not mean it will be received.

When someone sends a message, it will be injected in the MTA chain and finally be stored in the Post Office (MS, incoming mail server).

When a user wants to read mail, it asks the MS for incoming messages, the user can choose to leave a copy on the server or delete them. For security it’s better to delete, but Post Offices could have illegal copies.

Question 3

Webmail

Answer 3

MUA is replaced by a web-browser. A virtual MUA is placed inside the web-server, that is automatically configured. An HTTP engine is placed in front of the MUA.

Not good for privacy.

Question 4

Mail protocols, ports, formats

Answer 4

• SMTP (Simple Mail Transfer Protocol)
  
  • 25/TCP (MTA)
  • 587/TCP (MSA)
• POP (Post Office Protocol)
  
  • 110/TCP
• IMAP (Internet Message Access Protocol)
  
  • 143/TCP
• Formats:
  
  • RFC-822: Message format (pure text body)
  • MIME: Multimedia extension of RFC-822

Question 5

RFC-822 Messages

Answer 5

Provides pure test mail with only US-ASCII characters on 7 bits (8th used for parity).

Lines must be terminated by (system independentness)

Messages composed of:

• Header:
  
  • keywords at the begginning of the line
  • Continuation lines start with a space
• Body
  
  • Separated from the header by an empty line
  • Contains message
    *

Question 6

RFC-822 header

Answer 6

Written in english.

From: logical sender, some applications allow changing it to an arbitrary value.

Sender: operational sender, usually is the same as From

Date is the time declared by the MUA, easy to forge

Received: contains list of MTAs traversed.

CC: carbon copies.

BCC: blind carbon copies

Return-Receipt-to: when the sender would like to receive an ack.

Question 7

Issues in securing e-mail

Answer 7

• E-mail is connectionless, TLS won’t solve the problem
• Untrusted MTA’s
• Security of MS, where messages are stored.
• Mailing-list encryption:
  
  • public key of destination is needed
  • A lot of mails as recipient makes it hard to send encrypted mails.
• Compatibility with already installed SW
• Solution developed:
  
  • lnternet: PGP, PEM, MOSS, S/MIME
  • OSI: X.400
  • Only survivors are PGP and S/MIME.

Question 8

Mail spamming

Answer 8

• UBE or UCE (Unsolicited Bulk/Commercial E-mail)
• Used to sent unwanted messages: unauthorized advertisement, attacks (malware, phishing, …)
• Nearly 50% of all e-mail.
• Good mail is ham, not spam.

Question 9

Spamming strategies

Answer 9

• Spammer hides real sender, but uses a valid one, so the recipient believes they can trust it.
• Spammer sends spam via special MTA named Open Mail Relay
  
  • not well configured, such that they accept and forward email from anybody.
• Spammers also use zombies or botnets witi a variable phantom IP address (unassgigned)
• Content obfuscation:
  
  • Deliberate Mistakes (Vi@gra)
  • Image rather than text (not detectable)
  • Bayesian poisoning: insert text from a book at the end of the mail, so that the systems cannot detect different frequency patterns
  • Inside an error message: spammers send fake error messages in the hope that they are not checked from antispamming software.

Question 10

(Open) mail relay

Answer 10

Usually, where there is a domain, there’s also a domain relay.

Configured to accept outgoing mail only if they come from the same domain (e.g. polito.it). Accepts incoming mail only if final destination is the same domain (e.g. polito.it). This is the configuration of a not-open relay.

If the systems is misconfigured or restrictions are not applied, an external user can ask the relay to send email to the outside, the user might be a spammer. For this reason, the relay must distinguish from real from fake users.

Question 11

Anti-spam for MSA

Answer 11

Restrict use of MSA to authorized users, which must be authenticated.

To authenticate users it is possible to use:

• IP address of the MUA:
  
  • problem with mobile nodes, IP spoofing and malware installed in valid node
• Value of the field From
  
  • ca be easily tricked with a fake mail
• SMTP authentication
  
  • The most secure

Strategies:

• Reject or accept mail from an MTA after checking a blacklist or whitelist. Check DNSBL (DNS-based blacklist) which works like this:
  
  • a request from MTA is received, the address is checked using nslookup -q=DOMAIN.dnsbl.antispam.net
  • if NXDOMAIN == “no such domain” then it is not a spammer
  • else the query returns an address: 127.0.0.X (X is a code providing the reason for the blacklisting) and a TXT record with more info.
• Instead of looking at the MTA, that is changed frequently by attackers, another strategy consists in looking up addresses contained in the text of the mail. If a message contains a URI (for phishing), then a look up is performed on DNSBL (URI reputation data). Some honeypots are placed just for capturing phising URIs.

Question 12

DNSBL lists

Answer 12

There is a number of free/commercial/anonymous listS.

Lists are managed by people that are not easy to be contacted, thus URIs inserted are not easy to be removed. Configuring the MTA correctly is strongly suggested.

Activate/use the abuse@domain address as required by an RFC.

Question 13

Anti-sapm for incoming MTA

Answer 13

• Greylisting: since spammers are sending millions of messages, they have scarce time; they would like to send the message as soon as possible.
  
  • when someone is contacted by an MTA a temporary error is given, if the MTA comes back in some time them it will be accepted. A spammer would usually skip those. This will delay also ham. Server will need to keep a history of contacts.
• Nolisting: if greylisting is not possible.
  
  • If more than one mail exchanger is defined for target domain is defined, typically spammers contact the mail exchanges that has got the highest prioroity.
  • If we list at least 3 mail exchangers: first and last don’t answer. Then spammer will only try either the first or the last.
  • Problem: this will delay ham.

Question 14

DKIM

Answer 14

DomainKeys Identified Mail: strategy in which the sender uses a signature to guarantee:

• the identity of the sender
• partial integrity of the message
• Done through a digital signature, created by the MSA or outgoing MTA.
• Signature covers some headers and part of the body and it is verifying through a public key (tipycally insterted by DNS)
• Every mail sent from the mail relay of Polito mail server contains a signature where the Polito MTA says “This was sent by me and I have authenticated the user”.
• Thanks to it we can discard messages with a fake sender and hence support anti-spam and anti-phishing.

Question 15

SPF

Answer 15

Sender Policy Framework: techniques that consists in declareing which are the outgoin MTA via specific DNS records.

Performing an nslookup on polito.it returns ‘v=spf1 ptr ~all’, which means that any node inside Polito that has a valid reverse address (for which a PTR record exists) is a valid sender of electronic mail, all means that everything should be accepted.

Performing an nslookup on google, gives us the address where to find the exact list of nodes that are outgoing mail servers for google. A mail coming from a google user could be rejected if it not coming from one of those servers.

Question 16

ESMTP

Answer 16

Extended SMTP: protocol and communication channel. ESMTP client must identify themselves to communicating parites with EHLO hostname.

If the receiving party speaks ESMTP must declare the extensions it supports one per line and its response to EHLO.

Extensions are needed to authenticate the client before accepting messages from it. Useful against spamming because after the EHLO command, the server sends the authentication mechanism supported and the client chooses one and the authentication protocol is executed. If the authentication fails, the communication channel is closed.

Question 17

ESMTP AUTH examples

Answer 17

Question 18

ESMPT AUTH challenge-response methods

Answer 18

There are other methods than LOGIN and PLAIN (both sending cleartext passwords).

CRAM-MD5 and DIGEST-MD5 are symmetric challenge response methods.

CRAM-MD5

• Challenge = base64(nonce)
• Response = base64(usr SPACE HMAC-MD5(pwd, nonce)_{lowercase hex})

DIGEST-MD5

• Similar to HTTP/1.1 digest authentication
• Declared obsolete in 2011, replaced with SCRAM

Question 19

Analysis of CRAM-MD5

Answer 19

Pros:

• Allows client authentication
• Resistant to replay (challenge = random number + timestamp + FullyQualifiedDomainName)
• Resistant to sniffing (non-invertible hash)

Cons:

• No server authentication (but if used over TLS that could provide server authn)
• Cleartext storage of password, unless the intermediate steps of HMAC are stored.
• Dictionary attack is possible
• Possible MITM attack after authentication. Problem of any authentication performed only at the opening of the channel, and where there is no integrity for each message.

Question 20

SMTP Protection with TLS

Answer 20

STARTTLS = option for EHLO and command

If negotiation is successful, the protocol status is reset, it starts again from EHLO and the supported extensions can differ.

If the negotiation produces a security level below the threshold:

• The client sends immediately QUIT and closes the connection
• The server respons to each command with code 554 (refused due to low sercurity), since in SMTP the connection must always be terminated by the client.

Question 21

Security services for e-mail

Answer 21

When 2 MTAs are communicating, it is not important to have a TLS channel, because email is cleartext anyway. Email is hop-by-hop service, email messages must be protected.

• Integrity (without direct communication)
• Authentication (identify the sender)
• Non-repudiation (sender cannot deny having sent the mail)
• Confidentiality (optional): messages are not readable both in transit and when stored in the mailbox.

Question 22

Main ideas of email security

Answer 22

• No modification to the standard MTA:
  
  • result of signing operation or message encryption must be encoded to avoid problems when passing through gateways.
• No modification to the present UA
• With modification to the present UA: improving the UI
• Symmetric Algorithms: encryption of messages, with message key.
• Asymmetric algorithms: to encrypt and exchange symmetric keys, and for digital signatures.
• Use of public key certificates for non repudiation.

If all of the above is well-done, message security is only based on the UA of the recipient, not on the security of MTA (untrusted).

Question 23

Types of secure messages

Answer 23

• Clear-signed: in-clear message (anybody can read it) + digital signature (as attachment or inside the message)
  
  • verifiable only from owners of secure MUAs
  • Risky if the text-part is not well-encoded, the most significant bit of each byte could be cleared for parity by any MTA, this could cause a signature mismatch even with a correct message.
• Signed: message + digital signature encoded togheter (e.g. base64)
  
  • only secure MUAs can verify signature
• Encrypted/enveloped: encrypted message + encrypted keys encoded
  
  • only who owns secure MUAs and has the keys can decrypt the message
• Signed and enveloped

Question 24

Steps for secure message creation

Answer 24

• Transform message into canonical form (System independent)
• MIC (Message Integrity Code): integrity and authentication
  
  • Typically message + E(priv. Key, hash(message))
• Encryption: confidentiality
  
  • Typically: E(MessageKey, message) + E(Pub Key Receiver, MessageKey)
• Encoding: to avoid modification by the MTA
  
  • Typically base64, uuencode, binhex

Question 25

Secure electronic mail formats

Answer 25

* IETF created: 1. **PEM**: protected text messages 2. **MOSS**: protected **MIME-based** messages 3. **S/MIME** * People who didn't trust CA created **PGP**, then **MIME-PGP** * Dept. of U.S. Def. + European Commision used **X.400**, nowdays they use S/MIME

Question 26

PGP

Answer 26

Pretty-Good-Privacy: * **authentication, integrity** and **confidentiality** system for eletronic mail or private files. * Similar in organization to **PEM**, but **less structured**. * Uses concept of **trusted friends and trust-propagation algebra**. * Available in any system. * OpenPGP is the continuation of the "free" project. Certification: * Each user that trusts another user, signs their public key. * Trust is propagated transatively with some approx: * completely, partially, untrusted, unknown * To make a partial trust, at least 3 other partial trusted trusted are needed. Distribution: * Public keys are stored individually by each user. * Keys are distributed by the onwer (PGP parties) or by a key-server (where the key and all attached signatures are put). * If among the signatures there is someone trusted that says the key is trusted, then the system trusts it. * Also possbile to distribute via X.500 and DNS.

Question 27

MIME

Answer 27

Multipurpose Internet Mail Extensions A way of encode e-mail when it contains various kinds of artifacts. it solves these problems: * Makes it possible to use different data encodings, it is also possible not to use USA alphabets, long lines (more than 56 chars), and binary data * Multipart format means that a message can contain different parts, and each part can have a different type. * MIME is also a recursive format which means that any multipart object can contain multipart objects. The last 2 features are used in security to perform digital signatures and encryption. Digital signatures and encryption require that pieces of data of interest are not modified while transmitted (things that could happen when MTA transmits), an appropriate encoding can avoid this.

Question 28

Secure multimedia electronic mail

Answer 28

MOSS and S/MIME provide digital signatures and encryption capabilities with X.509 certificates to protect MIME messages. Signing: a trailig part is added in the last position, by computing the encoding of the digital signature over all previous parts inside the message. Encryption: message is considered as a single object and thanks to the recursive property of MIME an encrypted object is created. The encrypted object can be a signed message, so it is possible to have the original MIME object signed and encrypted.

Question 29

MOSS standard

Answer 29

RFC-1847 is a MIME extension for message security to apply a digitial signature. Requires to add a Content-Type field to the message that was multipart/signed with the specification of the **protocol** (digital signature applied) used, and **micalg** (used to compute mic code). Also the boundary (string separating two parts of MIME) must be included. When applied, there are N parts, the N - 1 parts are those to be protected, while the last one contains the digital signature.

Question 30

S/MIME standard

Answer 30

Starting from the MOSS standard, S/MIME was defined and for some time it was a competitor. S/MIME v1 was used by **RSA**, while v2 was published as a series of RFC; v3 and v4 have been created together with the internet community, these versions are described **not** in **informational RFC**s like v1 and v2, but as **proposed standards** (**endorsed** by the internet community). Architecture: a fromat to represent the protected body od the message is needed: PKCS-7, CMS, PKCS-10 (certificate request), X.509

Question 31

S/MIME algorithms v4.0

Answer 31

Question 32

S/MIME new MIME Type

Answer 32

S/MIME creates new parts in MIME multiparts messages. Those parts have specific MIME types, examples of MIME types are: * application/pkcs7-mime, this is used when: * part contains encrypted message (envelopedData) * part contains signed message (signedData) addressed only to S/MIME users, since it is encoded in base64 * part contains a public key (a certificate, in a degenerate signedData body) * standard extension = .p7m * base64 encoded to avoid manipulation during transport * Multipart/signed: * signed messages addressed also to users that do not support S/MIME * message is in-clear * Last MIME part is the signature and it is base64 encoded * standard extension for the signature: .p7s * Application/pkcs10: * used to send a certification request to a CA * base64 encoded

Question 33

S/MIME examples

Answer 33

Encrypted: B64(P7\_enveloped(msg)) Signed (only S/MIME users): B64(P7\_signed(msg)) Singed (for any user): MIME(msg) + B64(P7\_signed\_detached(msg)) Signed and encrypted: * B64(P7\_enveloped(P7\_signed(msg))) * B64(P7\_signed(P7\_enveloped(msg))) * preferred option since it is more resistant to DoS attacks: it is possible to heck integrity before decrypting the whole message. msg notation === RFC-822 body of the message

Question 34

S/MIME naming

Answer 34

* Email is used in S/MIME TO select the certificate and to verify the sender address. (value in the from field must be the same found in the certificate) * S/MIME v2 used the fields EMAIL= or E= in the DN (distinguished name) of the X.509 certificate), but it was possible also to use subjectAltName field with the rfc822 encoding. In v3, subjectAltName must be used with encoding rfc822, so the DN will not contain the email address, but subjectAltName will.

Question 35

Protecting Pull operation from the Post Office

Answer 35

Pull operation corresponds to checking if there's any mail at the post office. Properties needed: * **Authentication of the user**: mail server mus tbe sure to dliver meail only to the user whom they belong. * **Server authentication**: client must be sure that it is not receiving fake mails * **Confidentiality/integrity of mail messages:** * on the server: this protection must be addressed by the receiver * while in transit If a message requires protection, the sender is responsible of applying S/MIME, this way the server is protected both on the servers (post office and intermediate MTAs) and in transit.

Question 36

POP

Answer 36

Post office protocol: text-based protocol. POP2: it didn't support password-based authentication, not used. POP3: not used, it provided in-clear password-based authentication. APOP: user authentication only through challenge * APOP command replaces set of commands USER + PASS * challenge is in the hello line contained inside the angle brackets * Syntax: *APOP user response-to-challenge* * response = md5(challenge + pwd), then encoded in hexadecimal K-POP: mutual authentication by means of tickets, but requires Kerberos.

Question 37

IMAP

Answer 37

Internet Mail Access Protocol The default user authn is via username and password sent in clear. It however supports OTP, Kerberos or GSS-API.

Question 38

Using TLS with IMAP, POP3, and ACAP

Answer 38

To address the problem of in-clear password-based authentication, and the problem of server authentication, RFC-2595 documents the use of TLS with POP3 and IMAP. ## Footnote Prescribes that the first communication channel is opened, then the security characteristics are negotiated by means of a dedicated command (similarly to what happens to HTTP and SSL/TLS). **STARTTLS** for IMPA and ACAMP. **STLS** for POP3 Client and server must allow configuration that reject username and password if sent in clear. In this way the client can compare the identity in the certificate with the identity of the server.

Question 39

Using seperate ports for SSL/TLS for mail protocols.

Answer 39

The alternative to turn a normal channel into a secure one through a specific command (e.g. STARTTLS, STLS), is to use different ports for the secure version fo the protocol. Example: possible to have a secure http channel by connecting to port 80 and then running STARTTLS, or it is possible to activate TLS on TCP port 443 and then run http on top of it. The use of **different ports is discouraged by IETF** for the following reasons: * Involves different URLs (http/s) * Involve an incorrect secure/insecure model (e.g. is 40-bit SSL secure? * "use TLS if available" is not easy to implement. * Doubles the number of necessary ports. The advantages of using different ports are: * Simple to filter traffic on packet-filter firewalls * TLS with client-authentication allows not to expose the applications to attacks: minimizes attack surface. * this would be difficult to implement if TLS is activated after, because at that point the attacker would be already connected to the application server