I just finished a paper dealing with TLS (ssl 3.1) relative to email security between client and server and opportunistic use between servers.
I enclose it in the body for review and comment. Please post any comment to me directly at [EMAIL PROTECTED], and not to the list. I enclose a list of relative links at the bottom of my paper. Thank you for your time. Ian Briggs ***************************************** Email security. SSL 3.1 / TLS 1.0 deployment. Ian Briggs Web, Internet, and E-Commerce Security Good infrastructure security relies on a layered approach, much like an onion. A good security policy must assume eventual failure of one or more security devices or policies, and therefore will create multiple security compartments. The final layer of security must be designed to protect specific assets, separate of any other layers, and limit the overall damage any one intrusion may cause. In this paper I will address several security policies that concern the secure transmission of email between client(s) and server(s) and transmission between one or more servers. Separate email security issues such as non-repudiation, digital signatures, encryption, intrusion detection, host-firewalls, server security and client security have been successfully addressed in depth by other publications. It is important to address all aspects in relationship to security concerning email as part of an all-encompassing security policy, as without a layered security policy both the host and the server are susceptible to core security breaches that would neutralize secure transmission of email as an effective policy. Lets assume a single client on a LAN has been compromised either through hacking, spy ware, or employee malfeasance. With modern networking tools such as ARP poisoning and various network sniffer tools publicly available, the single compromised machine may now have access to all unencrypted email traffic on its network segment, allowing relatively non-intrusive access to private communications between multiple parties for the indeterminate future. POP3 and IMAP protocols communicate both the body of the message and the authentication in clear text. An example traceroute shows 10 network hosts between my client and my mail server. Each of these hosts and the associated network segments may be operating in a promiscuous mode allowing covert interception of all email traffic. In addition to a visible host, network taps may allow interception of the traffic directly from the transport media without any discernable network interference. Interception of network traffic between a host computer and a primary mail server would not be detectable and would allow full access to my day to day email correspondences. Assuming the client machine is secure, and also assuming each hop between the client and the mail server is secure, we now encounter the problem of security between mail servers. SMTP transfers mail messages between servers in clear text. A traceroute between my mail server and the primary AOL mail server shows 15 hosts, each of these may be compromised or operating intentionally in a promiscuous manner. We encounter the same problems with network traffic interception that we encountered with transferring mail between the client and the mail server as we do between mail servers. A final security issue often overlooked concerns identity hijacking. Several major security intrusion tactics involve attacking DNS directly to allow redirect exploits. The SMTP protocol does not allow for identity verification via a server certificate through a naming authority, nor verification of name to IP mapping. Although host and server compromise is the primary focus of many security policies, the actual routes of transmission between the client machine and its mail server, and/or your mail server and another mail server are often ignored and easily exploited. Furthermore I feel I must at least note the increased amount of interest in pursing intelligence gathering, without civil rights considerations, against people both in the United States and abroad under the banner of increased US security. I believe the security solutions here better implement a secure form of email communication that inhibits non-intrusive (read clandestine) intelligent gathering. The primary form of large scale intelligence gathering, relative to email communications, would be the deployment of �sniffing posts� throughout major network exchange points (naps), microwave relay points, and deployment within the networks of major internet providers. Securing the transfer of email relative to client to server, and server to server, would significantly effect the large scale collection of intelligence and further secure the private exchange points between networks from promiscuous intelligence gathering. Anyone on your network can read SMTP, POP3, and IMAP traffic that crosses the network because all three communication protocols sends both its messages, and any appropriate authentication, in clear text. Unencrypted email is susceptible to interception at every point within a network. The significance of access to the username and password during the authentication can not be underestimated, as many networks use the same username and passwords for access to VPN, network resources, remote access, and payroll as they do for email. Secure Socket Layer (SSL), now being addressed specifically as Transport Layer Security (TLS)1.0, addresses security issues related to message interception during transportation between hosts. The deployment of TLS, client and server side, is the primary defense against compromised clients or promiscuous networks intercepting email in route from the client to the server, or from the mail server to another mail server. SSL, originally developed by Netscape, quickly hit version 2.0 and currently is version 3.x. The current version of SSL, SSL 3.0 has evolved into the Internet Engineering Task Force (IETF) Transport Layer Security (TLS) 1.0 protocol, sometimes referred to as SSL 3.1. TLS allows three specific advantages when addressing email security issues. First, the peers identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA DSS, Diffie-Hellman, ElGamal, etc.). This allows the safe exchange of encrypted information, coupled with an authorized naming certificate which can allows clients to verify that the IP address and name are the consistent with the DNS records, inhibiting �man in the middle� and DNS spoofing exploits. Second, the TLS negotiation exchange and transfer protects the content of email from interception while in route between two TLS enabled clients. Finally the contents of a message can not be modified en route between two TLS negotiated hosts. Violation of TLS can be detected by either party. Client and server side deployment of TLS is relatively easy. Nearly all major email clients such as Eudora, Outlook, Outlook Express and Netscape Mail, include the option to initiate a TLS connection for IMAP, SMTP and POP3 connections. The majority of mail servers such as; Exchange 5.5, Exchange 2000, IceWarp Email Server 2.0 and Postfix allow opportunistic TLS between servers. Once server side TLS is deployed, the amount of opportunistic TLS communication between mail servers quickly exceeds the average amount of TLS communication between mail clients and servers. Although the TLS is application protocol independent RFC3207 requires specific configuration relative to public SMTP servers. Public SMTP servers must allow normal SMTP connection upon the failure to negotiate a TLS connection, this allows the continued transfer of mail, keeping the security benefits of TLS or the failure to negotiate TLS, invisible to the actual process of successfully delivering email. Most major email programs such as Eudora, Outlook Express, and Netscape including options to initiate a SSL connection for both IMAP and SMTP and POP3. Corporate and personal security policies should mandatory use of SSL/TLS for all mail clients. This simple step initially secures the communication lines between client and mail server. In the rare case that the client software does not support SSL connections, the use of a SSH-2 client along with port forwarding to a remote server is suggested. There are several different ways to implement SSH-2 port forwarding, variations of implementation are relative to ease of use and overall deployment cost, and therefore will not be addressed in this paper directly. Email represents one of the most significant forms of communications in the Internet, yet the majority of email communication relies on aging protocols that were not designed to implement security concerns. At the same time, email communication systems can be extremely sensitive to interruptions of service and over obtrusive security measures. TLS addresses both of these concerns with a balance of strong secure encryption while appearing relatively transparent to the overall process. In order to maintain a "reasonable" level of internal and external security in today�s large network environment, security policies should require the implementation of TLS as the sole connection protocol for IMAP, SMTP and POP3 connections within the LAN environment and opportunistic use of TLS between SMTP servers. List of Popular Arp tools. http://neworder.box.sk/codebox.links.php?key=arptl Sniffers. http://neworder.box.sk/codebox.links.php?key=sniffb POP3 Request for Comment ftp://ftp.rfc-editor.org/in-notes/rfc1939.txt IMAP Request for Comment ftp://ftp.rfc-editor.org/in-notes/rfc1203.txt SMTP Request for Comment ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt Transport Layer Security Request for Comment ftp://ftp.isi.edu/in-notes/rfc2246.txt Eudora SSL/.TLS directions. http://www.eudora.com/techsupport/kb/2174hq.html SSL Configuration. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/exchange2000/maintain/security/secexsrv.asp TLS Confirguration. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/exchange2000/maintain/security/secexsrv.asp TLS Configuration. http://www.icewarp.com/Solutions/Corporate/Powerful_Features.asp StartTLS Configuration. http://www.homeport.org/~adam/starttls.html SMTP TLS RFC ftp://ftp.rfc-editor.org/in-notes/rfc3207.txt SSL/TLS Configuration. http://www.eudora.com/techsupport/kb/2307hq.html Client Configuration. http://www.cs.cf.ac.uk/System/intro/16/node12.html Client Configuration. http://oit.utk.edu/helpdesk/email/ssl.html
