Securing Email Bruce Maggs

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

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

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.

POP3 Dialog S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: USER mrose S: +OK User accepted C: PASS tanstaaf S: +OK Pass accepted C: STAT S: +OK 2 320 C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 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>

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

Autenticated Post Office Protocol (APOP, RFC 1460) S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK mrose's maildrop has 2 messages (320 octets) in this example, session is not encrypted 1896.697170952 is a time stamp shared secret is the password “tanstaaf” (server stores password rather than just hash) Client applies MD5 algorithm to the string <1896.697170952@dbc.mtview.ca.us>tanstaaf 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.

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.

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 3857529045] UIDs valid S: a002 OK [READ-WRITE] SELECT completed C: a003 fetch 12 full

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 imap.hostname@realm 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

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., bmm@cs.duke.edu

DNS MX Record

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 FROM:<bob@example.org> S: 250 Ok C: RCPT TO:<alice@example.com> C: RCPT TO:<theboss@example.com> C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: From: "Bob Example" <bob@example.org> C: To: "Alice Example" <alice@example.com> C: Cc: theboss@example.com C: Date: Tue, 15 January 2008 16:02:43 -0500 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 12345 C: QUIT S: 221 Bye {The server closes the connection}

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

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: 235 2.7.0 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.)

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

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.)

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 email for which domains, accessed via DNS

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

PGP Developed by Phil Zimmerman OpenPGP standard described in RFC 4880 Public key bound to user name or email 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.

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

Retrieve Certificate Chrome downloads and stores certificate.

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

My First Signed Message