1 / 23

Securing Email

Learn about the protocols used for retrieving and sending email, such as POP, IMAP, and SMTP, and the importance of securing email communications through encryption and authentication methods.

cooperk
Download Presentation

Securing Email

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Securing Email Bruce Maggs

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

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

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

  5. Experimenting with a POP3 Server telnet pop.example.com 110 openssl s_client -connect pop.example.com:995 -quiet

  6. 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) • 1896.697170952 is a time stamp • shared secret is the password "tanstaaf“ • 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.

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

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

  9. More IMAP Authentication Mechanisms (RFC 1731) Kerberos, GSSAPI, S/Key (like APOP) 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 (ticket and an authenticator for the principal "imap.hostname@realm") S: + or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: A001 OK Kerberos V4 authentication successful

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

  11. DNS MX Record

  12. 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> S: 250 Ok C: RCPT TO:<theboss@example.com> S: 250 Ok 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}

  13. 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> C: EHLO client.example.org

  14. SMTP AUTH Extension 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 ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 Authentication successful

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

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

  17. Proving your SMTP Relay is Legit • Register reverse DNS name • DKIM – relay signs headers with its private key, receiver can verify that relay is in the same domain (e.g., cs.duke.edu) as sender • SPF – list of which servers are permitted to originate email for which domains, accessed via DNS

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

  19. 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 authenticty, often at key-signing parties • Supported in Thunderbird, Pine, with plug-in in Outlook.

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

  21. Retrieve Certificate • Chrome downloads and stores certificate.

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

  23. My First Signed Message

More Related