Email security. SSL 3.1 / TLS 1.0 deployment.

[Normen Nomesco <dis-list () rebelbase com>]

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 ian () rebelbase com, 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