1. Securing
Bruce Maggs

2. Separate Suites of Protocols
Protocols for retrieving
POP, IMAP, MAPI (Microsoft Exchange)
Protocols for sending
SMTP

3. Typical Delivery of Email
various
pop, imap, or mapi
smtp
TLS
(secure)
smtp
smtp.cs.duke.edu A
gmail.com MX
imap.gmail.com A

4. POP (Post Office Protocol)
Current version is POP3, RFC 1939.
Client connects to POP server on port 110
Originally, everything was sent in the clear.
Yes, everything, including user name, password, and your mail.
Now it’s common to connect instead to port 995 using SSL/TLS, same PKI as Web.

5. POP3 Dialog
S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready C: USER mrose S: +OK User accepted C: PASS tanstaaf S: +OK Pass accepted C: STAT S: +OK C: LIST S: +OK 2 messages (320 octets) S: S: S: . C: RETR 1 S: +OK 120 octets S: <the POP3 server sends message 1> C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) C: <close connection> S: <wait for next connection>

6. Experimenting with a POP3 Server
telnet mail.cs.duke.edu 110 openssl s_client -connect mail.cs.duke.edu:995 -quiet
openssl s_client creates a TLS session between client and server and supports text-based interaction – useful for debugging

7. Autenticated Post Office Protocol (APOP, RFC 1460)
S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK mrose's maildrop has 2 messages (320 octets)
in this example, session is not encrypted
is a time stamp
shared secret is the password “tanstaaf”
(server stores password rather than just hash)
Client applies MD5 algorithm to the string
which produces a digest value of c4c9334bac560ecc979e58001b3e22fb
Password not sent in the clear, digest can’t be reused
Other authentication methods include SASL and Kerberos.

8. IMAP (Internet Message Access Protocol)
Current version is IMAP4, RFC 3501.
Client connects to IMAP server on port 143.
Originally, user name, password, mail sent in the clear.
Now connect to port 993 using SSL/TLS.

9. IMAP Dialog
S: * OK IMAP4rev1 Service Ready C: a001 login mrc secret S: a001 OK LOGIN completed C: a002 select inbox S: * 18 EXISTS S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * 2 RECENT S: * OK [UNSEEN 17] Message 17 is the first unseen message S: * OK [UIDVALIDITY ] UIDs valid S: a002 OK [READ-WRITE] SELECT completed C: a003 fetch 12 full

10. More IMAP Authentication Mechanisms (RFC 1731)
Kerberos, S/Key (like APOP example), GSSAPI
(GSSAPI is a standardized API, typically wrapped around Kerberos)
Kerberos example:
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig== random 32-bit number
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
service ticket for the principal and authenticator for client
(encrypted checksum in authenticator contains 32-bit number)
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful

11. SMTP (Simple Mail Transfer Protocol)
Currently described in RFC 5321
Client connects to SMTP server on port 25
Originally everything was sent in the clear
Originally client could send mail without authenticating! *** SPAM *** ***FORGERY***
Port 465 used for SSL/TLS
Sender’s SMTP server relays mail to receiver’s SMTP server
DNS Mail Exchanger (MX) records used to resolve mail domain name to IP address of SMTP server of recipient, e.g.,

12. DNS MX Record

13. SMTP Dialog
S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.org S: 250 Hello relay.example.org, I am glad to meet you C: MAIL S: 250 Ok C: RCPT C: RCPT C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: From: "Bob Example" C: To: "Alice Example" C: Cc: C: Date: Tue, 15 January :02: C: Subject: Test message C: C: Hello Alice. C: This is a test message with 5 header fields and 4 lines in the message body. C: Your friend, C: Bob C: . S: 250 Ok: queued as C: QUIT S: 221 Bye {The server closes the connection}

14. STARTTLS
Instead of using separate ports for SSL/TLS connections, POP, IMAP, SMTP connections can be converted from plain text to encryped communications through the use of the STARTTLS command.
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.example.org ESMTP service ready
C: EHLO client.example.org
S: 250-mail.example.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
server supports STARTTLS

15. SMTP AUTH Extension Client must log in (authenticate) to send mail.
S: 220 smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ... TLS negotiation proceeds. Further commands protected by TLS layer ... S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= S: Authentication successful
Client must log in (authenticate) to send mail.
(In this example user name and password are BASE64 encoded but not encrypted in PLAIN string.)

16. Warning! Mail relayed between two SMTP servers might not be encrypted.
(Even if sender and recipient connect securely to their SMTP and IMAP servers.)

17. SORBS (SPAM and Open-Relay Blocking System)
Database of bad SMTP (blacklisted) relays accessed through DNS
Mail won’t be accepted from these relays
(Also SPAMHAUS Block List database.)

18. Ways to Prove your SMTP Relay is Legit
Register reverse DNS name (weak) or (stronger) register reverse name to match an MX record for senders’ domain
DKIM (DomainKeys Identified Mail) – relay signs headers with its private key, receiver can verify that sender is in the same domain (e.g., cs.duke.edu) as relay (no CAs, public keys distributed through DNS)
SPF (Sender Policy Framework) – whitelist of which servers are permitted to originate for which domains, accessed via DNS

19. Signing Your Email PGP (Pretty Good Privacy)
Certificate signed by certificate authority, e.g., Comodo.

20. PGP Developed by Phil Zimmerman OpenPGP standard described in RFC 4880
Public key bound to user name or address
No centralized certificate authority in original design
Public keys can be signed by other users attesting to their authenticity, often at key-signing parties
Supported in Thunderbird, Pine, with plug-in in Outlook.

21. Comodo
Verifies that you can receive at the address that you want a certificate for.

22. Retrieve Certificate
Chrome downloads and stores certificate.

23. Install in Thunderbird
(easier if downloaded to Firefox than Chrome)

24. My First Signed Message