The Case For Secure

Transcription

1 The Case For Secure By Erik Kangas, PhD, President, Lux Scientiae, Incorporated Contents Section 1: Introduction Section 2: How Works Section 3: Security Threats to Your Communications Section 4: Symmetric and Asymmetric Encryption in a Nutshell Section 5: Securing Your With SSL Section 6: Asymmetric Encryption and (PGP and S/MIME) Section 7: Conclusions Section 1: Introduction It may not be surprising for you to learn that is not a secure medium of communication; however, it may surprise you to learn just how inherently insecure it really is - how messages you thought deleted could be sitting on servers half way around the world years after being sent, how people can read and modify your messages in transit, and how the very username and password that you use to login to your servers can be stolen and used by hackers! This non-technical article is designed to educate you about how really works, what the real security issues are, what the solutions are, and how you can mitigate your exposure to these security risks. Security and information integrity is increasingly important. More and more business is done strictly over . While reading this article, imagine how these problems could affect your business or personal life... they can. Section 2: How Works This section describes the general mechanisms and paths taken by an message on its route from sender to recipient. This should give you an overview of the different protocols (languages) involved, the different types of servers involved, and the distributed non-instantaneous nature of . The examples herein are representative of most common solutions, but by no means are exhaustive. Sending an Message If you imagine that the sending of an message is analogous to the sending of a letter, then computers are "post

2 offices", and the "Simple Mail Transport Protocol" (SMTP) is the "procedure" by which a post office receives a letter or sends it off to another post office closer to the ultimate recipient. SMTP is used by any program that sends an message, to deliver that message to a "post office" for relaying to its destination. For most senders, there are really only 2 significant ways to send - via a web-based interface or via an " client" program, such as Microsoft Outlook or Eudora, running on their personal computer. In the second case, where you are using a program on your personal computer (or cell phone or PDA) to send , you have to specify a "post office" for these programs to connect to such that they can send messages. This "post office" is known as your "SMTP server". Your personal computer talks directly to the SMTP server using the computer protocol (language) known as SMTP. In the case of WebMail, your personal computer communicates with a WebMail web server using a web connection (speaking the "language" HTTP - "HyperText Transfer Protocol"). The WebMail server itself then contacts your SMTP server, passing it your message for the first step in the delivery process. Delivery of from your SMTP Server to your recipient's SMTP Server: When an SMTP Server receives an message addressed to someone whose box is not located in that SMTP Server, it must "relay" that message to another SMTP server closer to the recipient. This is very much analogous to the postal service. When you drop off a letter and they notice that the address is for someone in a different location, the postal service ships off the letter to another post office in or near its destination. This process is known as " relaying". How does your SMTP Server know where to relay the message to? If the recipient's address is "bob.net", then the recipient's domain name is "luxsci.net". Part of the "DNS settings" for the recipient's domain (these are the "mail exchange" or MX records for the domain; see also Understanding Domain Name Service (DNS) - includes an ordered list of SMTP Servers that expect to receive for this recipient. The highest priority SMTP Server listed is the recipient's actual SMTP Server; the others are "backup SMTP Servers". These backup servers merely queue for later delivery to the recipient's actual SMTP Server. There are many scenarios that govern the path an message may take from the sender's to the recipient's SMTP Server. Some of these include: 1. The sender's server can contact recipient's server and send the message directly (black line in the figure). 2. The sender's server cannot contact the recipient's actual SMTP server for some reason (maybe the recipient's server is busy, down, not accessible on the Internet, or maybe there is some other problem with the Internet between the servers). In this case, the sender's server tries to contact and deliver the message to the recipient's first backup server. 3. The sender's server might not be able to contact the recipient's actual SMTP server or its first backup server or some reason. In this case, the sender's server tries to contact and deliver the message the recipient's second backup server. 4. The sender's server may be busy or may not be able to connect to the Internet or any of the recipient's servers for some reason. In this case, it will queue the message and try to send it later. It will keep retrying periodically for several days until it succeeds in sending or gives up.

3 Any message delivered to any of the backup servers goes through the same process of trying to contact the recipient's actual SMTP Server, or a higher priority backup server. Backup servers may also queue for later sending. (Note that a recipient may have zero or more backup servers, not necessarily two as in this example). Once the message arrives in the recipient's SMTP Server and is delivered to the recipient's box, the recipient may pick up the message and read it whenever s/he chooses (discussed below). What should be clear from this discussion so far is that: All servers communicate with each other using SMTP You never know how long it may take for an message to get from sender to recipient as it depends on lots of things like: how busy the servers are, how much traffic there is on the Internet, what machines are down for maintenance, etc. Your messages may sit in queues on any number of servers for any amount of time. Some of these servers may belong to third parties (i.e. may not be under the purview of either the sender or the recipient). Retrieving From an SMTP Server When you receive an message it sits in a file in your SMTP Server. If you wish to view this message you must access this file somehow. Any computer wishing to access your file must speak one of the languages the SMTP Server does. With some exceptions, there are really only 2 languages that computers understand (for retrieval, as opposed to sending, for which they use SMTP), one is called the "Internet Message Access Protocol" (IMAP) and one is called the "Post Office Protocol" (POP). (We will not discuss the details of these here, but you may be interested in Understanding Services - for information about them.) As a recipient, you can generally retrieve your by either using a web-based interface known as "WebMail", or via an " client" program, such as Microsoft Outlook or Eudora, running on your personal computer. The client programs will talk directly to your server and speak IMAP or POP. With WebMail, your computer will talk to a WebMail server using a web connection (talking HTTP); the WebMail server will, in turn, talk to your server using POP or IMAP. The Lack of Security in is inherently insecure. In the following sections, we will see just how insecure it is. At this stage, it is important to point out the gross lack of security in the delivery pathway just discussed: WebMail: If the connection to your WebMail server is "insecure" (i.e. the address is and NOT then all information including your username and password is not encrypted as it passes between the WebMail server and your computer. SMTP: SMTP does not encrypt messages. All communications between SMTP servers send your messages in plain text for any eavesdropper to see. Additionally, if your server requests that you send your username and password to "login" to the SMTP server in order to relay messages to other servers, then these are also sent in plain text, subject to eavesdropping. POP and IMAP: These protocols require that you send your username and password to login; these credentials are not encrypted. So, your messages and credentials can be read by any eavesdropper listening to the flow of

4 information between your personal computer and your service provider's computer. BACKUPS: messages are stored on SMTP servers in plain, unencrypted text. Backups of the data on these servers may be made at any time and administrators can read any of the data on these machines. The messages you send may be saved unexpectedly and indefinitely and may be read by persons unknown as a result. These are just a few of the security problems inherent in . In the next section, we will talk about communications security problems in general so we can see what else can go wrong. Later on, we will see how these problems can be largely mitigated. Section 3: Security Threats to Your Communications This section describes many of the common security problems involved in communications and in particular. Eavesdropping: The Internet is a big place with a lot of people on it. It is very easy for someone with access to computers or networks through which your information is traveling to capture this information and read it. Just like someone in the next room listening in on your phone conversation, people using computers "near by" the path your takes through the Internet can potentially read and save your messages! Identity Theft: If someone can obtain the username and password that you use to access your servers, they can read your and send false messages as you. Very often, these credentials can be obtained by eavesdropping on SMTP, POP, IMAP, or WebMail connections, by reading messages in which you include this information, or through other means. Message Modification: Anyone who has system administrator permission (even if they are not supposed to) on any of the SMTP Servers that your message visits, can not only read your message, but they can delete or change the message before it continues on to its destination. Your recipient has no way to be tell if the message that you send has been tampered with or not! And, if the message was merely deleted, they wouldn't even know. False Messages: It is very easy to construct messages that appear to be from someone other than who they are actually from. Many viruses use this facility to propagate themselves. In general, there is no way to be sure that the apparent sender of a message actually sent the message - it could just as easily be fabricated. Message Replay: Just as a message can be modified, messages can be saved, modified, and re-sent later! This could result in you getting multiple messages and thus taking actions that were not requested. Unprotected backups: As messages are stored in plain text on all SMTP Servers, any backups of these servers' disks may also contain plain text copies of your messages. As backups can be kept for years and can be read by anyone with access to them, you messages could still be laying around in insecure places even after you think that all copies have been "deleted". Repudiation: Because messages can be forged, there is no way for you to prove that someone sent you a particular message. This means that even if someone DID send you a message, they can successfully deny it. This has implications with regards to using for contracts, business communications, electronic commerce, etc. Section 4: Symmetric and Asymmetric Encryption in a Nutshell In order to understand how we can mitigate the security problems described in Sections 2 and 3, a basic knowledge of the two main types of encryption will be very useful. This section presents these concepts in a simple, concise form that anyone should be able to understand.

5 Symmetric Key Encryption In symmetric key encryption, you and your friend share a "secret" key. Using this key, you can encrypt a message into "cyphertext". Cyphertext looks like a random sequence of characters and is completely meaningless to anyone unless they also have the secret key, in which case they can decrypt the cyphertext back into the original message and read it. Using symmetric key encryption, eavesdropping and unwanted backups of your messages no longer are a problem (unless the eavesdropper knows what your secret key is). It also becomes harder for someone to modify your messages in transit in any kind of a meaningful way. The problem with symmetric key encryption is precisely the fact that you and your friend must share the same secret key. Unless you meet in person, how do you communicate this key in a way that is secure? What if you want to send a secure message to someone on the other side of the world? How do you get them the secret key quickly in a way that eavesdroppers can't detect? Message Digests / Authentication Codes A "Message Digest" or "Message Authentication Code" is really a very simple concept. You take your message and pass it through an algorithm that spits out a relatively short sequence of characters (maybe 64 or 128 or so of them). This sequence of character is a "fingerprint" for the message. Any minute change in the message would produce a significantly different "fingerprint". There is no way to obtain the original message from its fingerprint and it is almost impossible to find two messages that yield the same fingerprint (just like trying to find 2 people who are not twins that have the same actual fingerprints). Message Digests are quick ways to check to see if a message has been altered. If you have a digest of the original message and compare it with a digest of the message you just received and they match, then you know that the message has been unaltered. Asymmetric Key Encryption In asymmetric key encryption, also known as "public key" encryption, each person has TWO keys. Any cyphertext created using one of the keys can ONLY be decrypted using the other key. So, for example, say you have keys "K1" and "K2". If you encrypt your message with K1, then ONLY K2 can be used to decrypt it. Similarly, if you encrypt using K2, ONLY K1 can be used to decrypt it. This is distinctly different from symmetric encryption where you only have one key that performs both functions on the same message. In asymmetric key encryption, the two keys that each person possesses are commonly named the "private" and "public"

6 keys because the "public" one is published or given out freely to anyone who wants a copy and the "private" one is kept secret. The security of asymmetric key encryption depends on the fact that no one except you can ever access your private key. Asymmetric key encryption allows you to do many clever things: Send an Encrypted Message: To send a secure message to someone, all you have to do is encrypt it with their public key! In this way, only the intended recipient, who has the respective private key, should ever be able to decrypt and read the message. This solves the problem of eavesdropping and the problem of communicating secret keys that is inherent in symmetric encryption. Prove You Sent A Message: To prove to someone that you sent a message, you can encrypt the message (or just a piece of it) with your private key. Then, anyone can decrypt it with your public key and read the contents. The fact that your public key decrypts the message proves that you sent it -- you cannot deny this fact. Sign a Message: A message signature proves that you sent the message AND allows the recipient to determine if the message was altered in transit. This is done by encrypting a digest of the message using your private key. The recipient can decrypt this and compare it to a digest the message actually received. If they match, then the message is unaltered and was sent by you. Encrypted, Signed Messages: The most secure form of communication is to first add a signature to the message and then to encrypt the message plus signature with the recipient's public key. This combines all of the benefits of all of the techniques: security against eavesdropping and unexpected storage, proof of sender, and proof on message integrity. Section 5: Securing Your With SSL By far the easiest thing you can do to help make your more secure is to use an provider that allows you to use the "Secure Socket Layer" (SSL) when connecting to their WebMail, POP, IMAP, and SMTP servers. SSL is a combination of asymmetric and symmetric key encryption mechanisms. If you connect to a server using SSL, the following things happen (roughly): 1. The server uses its private key to prove to you that it is in fact the server that you are trying to connect to. This allows you to trust that you are connecting to the right server and not some "middleman" trying to intercept your communications. 2. You send the server your public key. 3. The server generates a "secret key" and sends it to you encrypted using your public key. 4. You and the server then communicate using symmetric key encryption using this shared secret key. (Symmetric key encryption is faster than asymmetric key encryption). The benefits of SSL are twofold: 1. you can determine if you are connecting to the right server, and 2. you and the server can communicate securely. If you get any warning messages when connecting to a server using SSL, you should think twice about ignoring them. While your provider may just have a small technical problem that is causing the warning, these warnings can also indicate that your communications are being intercepted. These warnings usually indicate one of the following: 1. The server's SSL "certificate" (i.e. public/private key pair) has expired. 2. Some of the information in the certificate doesn't match the information you expect -- i.e. the certificate was issued for a different server name than the one you are trying to connect to. (You could be inadvertently connecting to the wrong server.) 3. The certificate was issued by an untrusted agency. SSL certificates are (generally) issued by third party agencies such as Thawte.com or Verisign. These 3rd party companies do a background check on the company requesting the certificate and only issue it if they have a right to the certificate. The certificate includes the name of the company, the name of the issuing company, and the name of the server to which it is issued. When you connect to an SSL server you can verify this embedded information and the fact that it was issued by a third party company that you trust. If all this checks out, then you can have a high degree of confidence that the server you are connecting to is in fact the intended server. Using SSL for WebMail, POP, IMAP, and SMTP ensures that all of your communications between your personal computer and your service providers computers will be encrypted. Your message contents, username, and password will be hidden from eavesdroppers -- but only hidden from eavesdroppers between you and your service provider! Using these SSL services does not protect your messages at all once they leave your SMTP Server and head to their destinations. So, it doesn't really protect your message contents too much, but it does completely protect your username and password from detection, and this is very important as it helps mitigate identity theft, the sending of false messages, etc.

7 Additionally, using SSL is easy. It usually only involves a simple change in the configuration of your client. It is transparent to your recipients - you can use SSL for these services even if your recipients do not. These measures protect you and your password. Because it is so easy and because the security you receive is much better than no security, we strongly encourage the use of SSL for communications whenever possible. Section 6: Asymmetric Key Encryption and (PGP and S/MIME) While SSL protects your password and your message contents to some extent, it does not solve any of the other problems we have discussed: repudiation, encryption, unwanted backups, message modification, etc. This is because SSL only protects the message path between you and your SMTP Server and stops there. Even with SSL, the messages are stored on your SMTP Server in plain text. The ultimate solution is to use asymmetric key encryption to provide message signatures and/or encryption. This completely solves the issues of: Eavesdropping (everything is always encrypted) Message modification (message digests are used) Message replay (you can include a timestamp in the signature) Repudiation (signatures allow proof of who sent the message) Unprotected backups (everything is always encrypted) Asymmetric key encryption should be used in combination with SSL so that your username and password are also protected. Why? These credentials are not part of the message and thus would not be encrypted along with the message unless you use SSL on secure the whole connection to the server. Fortunately (or unfortunately), there are two widely used forms of asymmetric key encryption for S/MIME and PGP. Both allow you to add signatures and/or encryption to your messages. PGP can be obtained from PGP.com and is compatible with most modern clients. S/MIME is built into many clients like Microsoft Outlook, but you must obtain an S/MIME certificate from a third-party company such as Thawte.com. Interoperability Problems PGP and S/MIME have interoperability problems that come in when sending or receiving encrypted or signed messages. The first problem is that PGP and S/MIME are completely incompatible! If you are using PGP and your friend is using S/MIME, you will not be able to send each other secure messages. That said, PGP has been an Internet standard (OpenPGP - RFC 2440) since 1997 and PGP-encrypted accounts for well over 90% of the current encrypted traffic on the Internet. So, using PGP will make you compatible with the majority. However, what really counts is the minority that you actually need to communicate with and their needs. Therefore you may find a need for the use of S/MIME if your correspondents like using its 3rd party issued certificates for communications rather than PGP's trust model. It is useful to know that some clients, such as Microsoft Outlook, can be configured to use BOTH PGP and S/MIME so that you can correspond securely using whatever method is necessary at the moment. The other interoperability issue involves "key exchange". If you want to send your friend an encrypted message, you first need his/her public key; if your friend wants to prove that you signed a message or that the message that you sent him/her was unaltered, s/he first needs your public key. So there is the necessity of trading public keys before secure communication can ensue. There are various ways of doing this (including ) and PGP offers "key servers" from which your correspondents' keys can be downloaded to make the process easier. However, not everyone has their PGP keys listed on a key server, let alone the same key server, and not everyone uses PGP, so the key exchange issue is still an impediment to sending secure messages -- especially if you have to send them quickly. Section 7: Conclusions is, in general, Completely Insecure! The security issues include: Eavesdropping Identity Theft Message Modification False Messages

8 Message Replay Unprotected backups Repudiation (Sender denies that s/he sent it) SSL: It is simple and easy to use SSL to secure the communications between your computers and your service provider's computers. This works no matter who your recipients are. Using SSL provides the benefits: Trust that you are contacting your service provider's computers and not someone else's Encryption to protect the username and password that you use to login to these servers. This mitigates identity theft and other issues. Protection from eavesdropping during this leg of the message's path to its recipients. PGP and S/MIME: These additions to your clients allow you to use the features of asymmetric key encryption to protect the contents of your messages throughout their entire path of transit from you to your recipient. They provide: Encryption to protect against eavesdropping and unwanted backups Message Digests to allow the recipient to see if the message has been altered in transit Signatures to prove that the apparent sender is in fact the one who sent the message I highly recommend the use of SSL for communications, at a minimum. Unfortunately, PGP and S/MIME are not being used as extensively as they should be. In my experience, more and more companies are using SSL to encrypt communications with their servers, but few are using PGP or S/MIME for encryption. I see the impediment being that the effort needed to setup, to enforce usage, and to train employees is seen as much larger (or costlier) than the benefit of use. Clearly, the cost savings gained by using secure messaging is in having less information leakage or modification which is very difficult to quantify, especially as most companies assume that they don't (or won't) have significant problems in this arena anyway. These assumptions will be changing. Unlike computer breakins and other security problems, problems with security are very hard to detect. You cannot tell if someone is reading your or modifying messages subtly until it is too late. You cannot quantify the cost of and information security problems until it is too late - imagine all of the things people write in their messages... and think twice. Brought to you by LuxScientiae, Incorporated Secure and Web Services