Você está na página 1de 24

The Case For Email Security

Section 1: Introduction to Email Security


You may already know that email is insecure; however, it may surprise you to learn just how insecure it really is. For example, did you know that messages which you thought were deleted years ago may be sitting on servers half-way around the world? Or that your messages can be read and modified in transit, even before they reach their destination? Or even that the username and password that you use to login to your email servers can be stolen and used by hackers? This article is designed to teach you about how email really works, what the real security issues are, what solutions exist, and how you can avoid security risks. Information Security and integrity are becoming more important as we use email for personal communication and business. While you are reading this article imagine how security problems can affect your business or personal life. if they have not already.

Section 2: How Email Works


This section describes the general mechanisms and paths taken by an email 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 nature of email networks. The examples I present are representative of many common email solutions, but are by no means exhaustive. Sending an Email Message Sending an email message is like sending a letter. When you send a letter you drop it off at your local post office. Your local post office looks at the address and figures out which regional post office the letter should go to. Then the regional post office looks at the address and figures out which local post office is closest to your recipient. Finally, the recipients local post office delivers your letter to its recipient. Computers are like post offices, and the Simple Mail Transport Protocol (SMTP) is the procedure which an email post office uses to figure out where to send the letter next. Any program that sends an email message uses SMTP to deliver that message to the next post office for relaying to its final destination.

Most people send mail in two ways with a web-based interface like Yahoo! or Gmail, or with an email client program like Outlook or Thunderbird.

When you send a message with an email program on your personal computer (or your cell phone or personal digital assistant), you have to specify a server so that your email program knows where to send the message. This server is like your local post office. Your email program talks directly to the server using the computer protocol (language) known as SMTP. This is like dropping off a letter at the local post office. When you use Webmail your personal computer uses an internet connection to communicate with a web server. The language that the internet connection uses is HTTP HyperText Transfer Protocol. When you send your message with Webmail the web server contacts its SMTP server and sends your message to it. Delivery of email from your SMTP Server to your recipients SMTP Server: When an SMTP Server receives an email message, it first checks if it has an Inbox for the message recipient. If it does not it must relay that email message to another SMTP server closer to the recipient. This is analogous to how your local post office forwards your letter to a regional post office. This process is known as SMTP relaying. How does your SMTP Server know where to relay the message to? If the recipients email address is bob@luxsci.net, then the recipients domain name is luxsci.net. Part of the DNS settings for the recipients 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 email for this recipient. The highest priority SMTP Server listed is the recipients actual SMTP Server; the others are backup SMTP Servers. These backup servers merely queue email for later delivery to the recipients actual SMTP Server.

There are many scenarios that govern the path an email message may take from the senders to the recipients SMTP Server. Some of these include: 1. 2. The senders server successfully contacts the recipients server and sends the email message directly (black line in the figure). The senders server can not contact the recipients actual SMTP server (maybe the recipients server is busy, down, or has some other connection problem). In this case the senders server tries to contact and deliver the message to the recipients first backup server. The senders server can not contact the recipients actual SMTP server or its first backup server. In this case the senders server tries to contact and deliver the message the recipients second backup server. The senders server can not contact any of the recipients servers. 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. 4.

Any message delivered to the backup servers goes through the same process of trying to contact the recipients actual SMTP Server, or a higher priority backup server. Backup servers may also queue email for later sending. (Note that a recipient may have zero or more backup servers, not necessarily two as in this example). Once the email message arrives at the recipients SMTP Server and is delivered to the recipients email box, the recipient may pick up the message and read it whenever s/he chooses (discussed below). Each server that receives your message adds its Received stamp to the message. This stamp identifies what server received the message, at what time, and from what other server. This information allows the recipient to see a messages entire journey. What should be clear from this discussion so far is that:

Most email servers communicate with each other using SMTP You never know how long it will take an email message to get from sender to recipient because you 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). sending your messages, even in the case of your email being spoofed by a spammer. Retrieving Email From an SMTP Server When you receive an email message it sits in a file in your SMTP Server. If you wish to view this email message you must access this file. 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 email computers understand (for email retrieval, as opposed to email 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 Email Servicesfor information about them.) dont know how busy the servers are, how much traffic there is on the Internet, what machines are down for maintenance, etc.

Your recipients can determine the Internet address and name of the computer from which you are

As a recipient, you can generally retrieve your email by either using a web-based interface known as Webmail, or via an email client program, such as Microsoft Outlook or Eudora, running on your personal computer. The email client programs will talk directly to your email server and speak IMAP or POP. With Webmail, your computer will talk to a Webmail server using a web connection (speaking HTTP); the Webmail server will, in turn, talk to your email server using POP or IMAP. The Lack of Security in Email

Email 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 insecurity in the email delivery pathway just discussed:

Webmail: If the connection to your Webmail server is insecure (i.e. the address is http:// and NOT
https://), 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 (unless the servers in question supportopportunistic TLS

encryption). Communications between SMTP servers may send your messages in plain text for any eavesdropper to see. Additionally, if your email 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. Finally, messages sent via SMTP include information about which computer they were sent from and what email program was used. This information, available to all recipients, may be a privacy concern.

POP and IMAP: The POP and IMAP 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 information between your personal computer and your email service providers computer.

BACKUPS: Email 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 email messages you send may be saved unexpectedly and indefinitely and may be read by unknown persons as a result. These are just a few of the security problems inherent in email. 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 solved.

Section 3: Security Threats to Your Email Communications


This section describes many of the common security problems involved in communications and email in particular. Eavesdropping: The Internet is a big place with a lot of people on it. It is very easy for someone who has access to the 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 the path your email takes through the Internet can potentially read and copy your messages! Identity Theft: If someone can obtain the username and password that you use to access your email servers, they can read your email and send false email messages as you. Very often, these credentials can be obtained by eavesdropping on SMTP, POP, IMAP, or Webmail connections, by reading email messages in which you include this information, or through other means. Invasion of Privacy: If you are very concerned about your privacy, then you should consider the possibility of unprotected backups, listed below. You may also be concerned about letting your recipients know the IP address of your computer. This information may be used to tell in what city you are located or even to find out what your address is in some cases! This is not an issue with Webmail, POP, or IMAP, but is an issue ith the transport of email, securely or insecurely, from any email client over SMTP. Message Modification: Anyone who has system administrator permission 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 tell if the email message that you sent has been altered! If the message was merely deleted they wouldnt even know it had been sent. False Messages: It is very easy to construct messages that appear to be sent by someone else. Many viruses take advantage of this situation to propagate themselves. In general, there is no way to be sure that the apparent sender of a message is the true sender the senders name could have been easily fabricated.

Message Replay: Just as a message can be modified, messages can be saved, modified, and re-sent later! You could receive a valid original message, but then receive subsequent faked messages that appear to be valid. Unprotected Backups: Messages are stored in plain text on all SMTP Servers. Thus, backups of these servers disks contain plain text copies of your messages. As backups can be kept for years and can be read by anyone with access to them, your messages could still be exposed in insecure places even after you think that all copies have been deleted. Repudiation: Because normal email 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 email 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, straightforward form.

Symmetric Encryption In symmetric 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 cant 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 two complete strangers who have the same fingerprint). 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 Encryption In asymmetric 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. 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 key 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 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 only on whether you can keep your private key secret. 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! Only the intended recipient who has the matching private key will be able to decrypt and read the message. This solves the problem of eavesdropping and the problem of sending secret keys that is inherent in symmetric key 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 only you could have sent it.

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 using your private key to encrypt a digest of a message at the time of sending. The recipient can decrypt this digest and compare it to a digest of the received message. 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 recipients 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 Email With SSL or TLS


The easiest thing you can do to make your email more secure is to use an email provider that supports Secure Socket Layer (SSL) for their Webmail, POP, IMAP, and SMTP servers. TLS is a type of SSL that can be initiated during a mail session; unlike TLS, SSL must be initiated before sending the email (seeSSL versus TLS Whats the difference?). 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 lets you know that you are not connecting to a middleman that is trying to intercept your communications. You send the server your public key. The server generates a secret key and sends it to you encrypted using your public key. You and the server then communicate using symmetric key encryption using this shared secret key. (Symmetric key encryption is faster than asymmetric key encryption).

2. 3. 4.

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. 2. The servers SSL certificate (i.e. public/private key pair) has expired. Some of the information in the certificate doesnt 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.) The certificate was issued by an untrusted agency.

3.

SSL certificates are (generally) issued by third party agencies such as Thawte.com or VeriSign. These 3rd party companies do a background check on companies that request certificates, and only issue certificates if the companies have a right to them. 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 the certificate is valid then you can have a high degree of confidence that the server you are connecting to is the server you want to reach. By using SSL for Webmail, POP, IMAP, and SMTP (see SMTP TLS) you ensure that communications between your personal computer and your email 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! SSL services do not protect your messages once they leave your SMTP Server and head to their destinations. So, it doesnt really protect your message contents, but it does completely protect your username and password from detection. This is very important because it prevents identity theft, forged messages, etc. SSL is very easy to use. It usually only involves clicking a few checkboxes in the configuration of your email 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 email communications whenever possible.

Section 6: Privacy with Anonymous SMTP


In Sections 2 and 3 we wrote that when you send email via any email client (but not Webmail), your computers Internet address is included in the message for all recipients to see. Depending your Internet Service Providers privacy standards and what kind of connection and service you have, this information may be used to determine what region or the country you are in, what city you are in, or even what your address is! This could be a serious issue for people very concerned about their privacy. Additionally, other information such as what email program you are using is also visible to the recipient. Anonymous SMTP services, or re-mailers, provide a good way of keeping all of the functionality of SMTP that you require, while giving you back your privacy. These services typically receive your message via

(Authenticated) SMTP (ideally they would also support SMTP over SSL, as described above) and then scrub the message, removing all information about your computers address, your email program, and any other nonstandard information. These services then re-email your scrubbed message to the intended recipients. The end result is that the recipients get the message just as they would have without the Anonymous service, except that they can only track the message back to your Anonymous SMTP server. They know who you are, based on your email address and your message content, but they have no way of knowingwhere you are or what email programs you are using. Most anonymous SMTP services log all information that they scrub out of messages and track all activity. So, while your recipients do not know where you are, your email service provider does. This prevents this type of service from providing any real benefit to people who send unsolicited or forged email their service provider can quickly respond to complaints or abuse, identify the sender, and terminate the account and/or bring legal measures to bear. What it does provide is a level of privacy in sending of email that is functionally equivalent to the level of privacy you get from sending through a Webmail interface (unless the Webmail in question makes it a point to add your computers address into the outgoing message most do not). LuxSci offers Anonymous SMTP services to all clients who have SMTP Relaying services. This service is compatible with LuxScis SMTP over SSL services as well and only requires changing the port you use to connect to LuxScis SMTP servers.

Section 7: Asymmetric Key Encryption and Email (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. Fortunately (or unfortunately), there are two widely used forms of asymmetric key encryption for email: 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 standard email clients. S/MIME is built into many email 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 solve many problems, but they also create another: interoperability. One interoperability issue 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 email accounts for well over 90% of the current encrypted email traffic on the Internet. So, using PGP will make you compatible with the majority. However, the majority doesnt matter when youre trying to contact the minority that use S/MIME. It is useful to know that some email 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. Additionally, most major email programs have support for S/MIME built in (and not PGP) so it is much easier and cheaper to get started with S/MIME. 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 begin. There are various ways to trade keys (including email). 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 8: Compatible Security with Escrow Encryption


Escrow encryption uses a trusted encryption middleman to give you the same security offered by asymmetric key encryption, but with universal compatibility. Here is how it works: 1. 2. 3. 4. 5. The sender connects to the middlemans web mail portal on a secure SSL connection The middleman validates the sender. The sender creates a message. The message sender makes a secret question and answer for the recipient. Only the recipient knows the answer to the question. The middleman encrypts the message and stores it on his server. middlemans web mail portal, and a unique message password that is part of the encryption key. The middleman then forgets this password so that he cannot decrypt the message until he gets the password back from the recipient. 7. 8. The recipient connects to the middlemans portal over a secure SSL connection and logs in with the message password . The middleman asks the recipient the secret question. If she answers correctly the middleman decrypts the message and presents it to the recipient.

6. The middleman sends a plain text message to the recipient that contains only a secure link to the

The encryption middleman handles all the encryption dirty work; it doesnt matter if the sender uses PGP and the recipient uses S/MIME. In fact, it doesnt matter if either uses encryption at all! All that the sender and recipient need is a secure internet connection. The middleman takes care of everything else. How does it solve the security problems we mentioned earlier?

Eavesdropping: No one can eavesdrop on the message because the sender and recipient connect to
the middleman on a secure SSL connection.

Identity Theft: No one can steal the senders login information or the secret question/answer because
both the sender and the recipient use SSL connections. She only knows that he used the middleman. server.

Invasion of Privacy: The recipient knows nothing about the senders computer, email client, or location. Message Modification: No one can modify the message because it never leaves the middlemans False Messages: The message is only accessed on the middlemans server, so no one can pretend to
send it.

Message Replay: No one can modify the message because it never leaves the middlemans server. Unprotected Backups: The message is encrypted when it is stored, so it is secure even in backups. Repudiation: The recipient knows that the sender really did send the message because he was
validated by the middleman.

In addition the middleman can keep a log of who accesses the message and at what times. Thus the sender can audit the message to see who has viewed it. Notice that the message is secure and anonymous; The message is encrypted and stored on the middlemans servers, so it is not subject to the security of intermediate relaying servers. Only the middleman can encrypt and decrypt the message, and only authorized recipients can access the message. The recipient knows nothing about the senders computer, only that he used the middleman. As long as the middleman is trustworthy, the message is completely secure, completely anonymous, and completely compatible. LuxScis SecureLine service provides complete, compatible security through escrow encryption.

Section 9: Conclusions
Email is, in general, Completely Insecure! The security issues include:

Eavesdropping Identity Theft Invasion of Privacy Message Modification False Messages 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 email service providers computers. This works no matter who your recipients are. SSL improves security in these ways:

It establishes that you are contacting your service providers computers and not someone elses It encrypts the username and password that you use to login to these servers. This mitigates identity
theft and other issues.

It protects your message from eavesdroppers between your computer and your SMTP server.
Anonymity: If you have access to an Anonymous SMTP server, you have an easy way to increase your Internet privacy. Anonymous SMTP provides:

IP address privacy so that message recipients cannot determine your computers Internet address (and
thus your location).

Email client privacy so that the recipients of your email messages cannot determine what type of email
client you are using. messages.

A means to strip out any other non-standard email header data that may be lurking in your outbound

PGP and S/MIME: PGP and S/MIME keys use asymmetric key encryption to protect the contents of your messages throughout their complete journeys. They provide:

Protection against eavesdropping and unwanted backups Message Digests to detect whether messages have been altered in transit

Signatures to prove sender authenticity


I highly recommend the use of SSL for email communications. 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 email 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 dont (or wont) have significant problems in this arena anyway. These assumptions will be changing. Escrow encryption avoids the impediments of PGP and S/MIME encryption while providing complete security, anonymity, and other features. There is no learning curve for escrow encryption because it can be easily integrated into an existing web mail system. Anyone who is concerned about security but doesnt know how to set it up can use escrow encryption as easily as they use web mail. In addition, it can communicate securely with anyone who has an internet connection. Unlike computer break-ins and other security problems, problems with email security are very hard to detect. You cannot tell if someone is reading your email or modifying messages subtly until it is too late. You cannot quantify the cost of email and information security problems until it is too late imagine all of the things people write in their messages. and think twice.

http://luxsci.com/blog/the-case-for-email-security.html#comment-507

Bagian 1: Pengantar Keamanan Email


Anda mungkin sudah tahu bahwa email tidak aman, namun mungkin akan mengejutkan Anda untuk belajar betapa tidak aman sebenarnya. Sebagai contoh, apakah Anda tahu bahwa pesan yang Anda pikir telah dihapus tahun yang lalu mungkin akan duduk pada server setengah jalan di seluruh dunia?Atau bahwa pesan Anda dapat dibaca dan dimodifikasi dalam perjalanan, bahkan sebelum mereka mencapai tujuan mereka? Atau bahkan bahwa username dan password yang Anda gunakan untuk login ke server email Anda dapat dicuri dan digunakan oleh hacker? Artikel ini dirancang untuk mengajarkan Anda tentang bagaimana email benar-benar bekerja, apa isu-isu keamanan nyata, apa ada solusi, dan bagaimana Anda dapat menghindari risiko keamanan. Keamanan Informasi dan integritas menjadi lebih penting karena kita menggunakan email untuk komunikasi pribadi dan bisnis. Ketika Anda membaca artikel ini membayangkan bagaimana masalah keamanan dapat mempengaruhi bisnis Anda atau kehidupan pribadi .... jika mereka belum sudah.

Bagian 2: Bagaimana Bekerja Email

Bagian ini menjelaskan mekanisme umum dan jalur yang diambil oleh pesan email pada rute dari pengirim ke penerima. Ini akan memberikan Anda gambaran tentang protokol yang berbeda (bahasa) yang terlibat, berbagai jenis server yang terlibat, dan sifat didistribusikan jaringan email. Contoh saya ini adalah perwakilan dari banyak solusi email yang umum, namun tidak berarti lengkap. Mengirim Pesan Email Mengirim pesan email adalah seperti mengirimkan surat. Ketika Anda mengirim surat Anda drop off di kantor pos setempat. Kantor pos lokal Anda melihat pada alamat dan angka mana kantor pos daerah surat itu harus pergi ke. Kemudian kantor pos regional melihat pada alamat dan angka mana kantor pos setempat paling dekat dengan penerima. Akhirnya, kantor pos setempat memberikan penerima surat Anda ke penerima. Komputer adalah seperti "kantor pos", dan "Mail Transport Protocol Sederhana" (SMTP ) adalah "prosedur" yang merupakan "kantor pos email" menggunakan untuk mencari tahu di mana untuk mengirim surat berikutnya. Setiap program yang mengirimkan pesan email menggunakan SMTP untuk menyampaikan pesan itu ke "kantor pos" berikutnya untuk menyampaikan ke tujuan akhir.

Kebanyakan orang mengirim surat dalam dua cara - dengan antarmuka berbasis web seperti Yahoo! atau Gmail, atau dengan sebuah program "email client" seperti Outlook atau Thunderbird . Bila Anda mengirim pesan dengan program email pada komputer pribadi Anda (atau ponsel Anda atau personal digital assistant), Anda harus menentukan server sehingga program email Anda tahu di mana untuk mengirim pesan. Server ini adalah seperti kantor pos setempat. Anda program email langsung berbicara ke server menggunakan protokol komputer (bahasa) yang dikenal sebagai SMTP. Ini seperti menjatuhkan dari surat di kantor pos setempat. Bila Anda menggunakan Webmail komputer pribadi Anda menggunakan koneksi internet untuk berkomunikasi dengan server web. "Bahasa" yang menggunakan koneksi internet adalah HTTP - "HyperText Transfer Protocol". Bila Anda mengirim pesan kontak Anda dengan Webmail server web server SMTP dan mengirim pesan Anda untuk itu. Pengiriman email dari Server ke Server SMTP SMTP penerima Anda: Ketika Server SMTP menerima pesan email, pertama kali memeriksa apakah ia memiliki Inbox untuk penerima pesan. Jika tidak harus "relay" yang pesan email ke server SMTP lebih dekat dengan penerima. Hal ini analog dengan bagaimana surat kantor pos setempat ke depan Anda ke kantor pos daerah. Proses ini dikenal sebagai "SMTP relaying". Bagaimana SMTP Server Anda tahu di mana untuk relay pesan ke? Jika alamat email penerima adalah "bob@luxsci.net", maka nama domain penerima adalah "luxsci.net". Bagian dari "pengaturan DNS" untuk domain penerima (ini adalah "surat tukar" atau MX record untuk domain tersebut; lihat juga Memahami Domain Name

Service (DNS) ) mencakup daftar memerintahkan Server SMTP yang mengharapkan untuk menerima email untuk ini penerima. Prioritas tertinggi Server SMTP SMTP Server yang tercantum adalah aktual penerima, yang lain adalah "Server SMTP cadangan". Server cadangan ini hanya antrian email untuk pengiriman nanti ke Server SMTP aktual penerima.

Ada banyak skenario yang mengatur jalur pesan email dapat mengambil dari pengirim ke Server SMTP penerima. Beberapa di antaranya adalah: 1. 2. Pengirim Server berhasil kontak server penerima dan mengirim pesan email langsung (garis hitam dalam gambar). Server pengirim tidak dapat menghubungi SMTP aktual penerima server (mungkin server penerima sibuk, bawah, atau memiliki beberapa masalah koneksi lainnya). Dalam hal ini server pengirim mencoba untuk menghubungi dan menyampaikan pesan ke server cadangan pertama penerima. Server pengirim tidak dapat menghubungi SMTP aktual penerima server atau server cadangan pertama. Dalam hal ini server pengirim mencoba untuk menghubungi dan menyampaikan pesan server cadangan kedua penerima. Server pengirim tidak dapat menghubungi salah satu server penerima. Dalam hal ini akan antrian pesan dan mencoba untuk mengirimkannya nanti. Ini akan terus mencoba kembali secara berkala selama beberapa hari sampai berhasil mengirim atau menyerah.

3.

4.

Setiap pesan yang disampaikan ke server cadangan berjalan melalui proses yang sama mencoba untuk menghubungi SMTP aktual penerima Server, atau server cadangan prioritas lebih tinggi. Backup server juga dapat antrian email untuk kemudian mengirim. (Perhatikan bahwa penerima dapat memiliki nol atau lebih server cadangan, belum tentu dua seperti pada contoh ini). Setelah pesan email tiba di server SMTP penerima dan dikirim ke kotak email penerima, penerima dapat mengambil pesan dan membacanya setiap kali s / ia memilih (dibahas di bawah). Setiap server yang menerima pesan Anda menambahkan nya "Diterima" stempel untuk pesan. Cap ini mengidentifikasi apa server menerima pesan, pada waktu apa, dan dari apa server lain. Informasi ini memungkinkan penerima untuk melihat seluruh perjalanan pesan itu. Apa yang harus jelas dari diskusi ini sejauh ini adalah bahwa:

Kebanyakan server email saling berkomunikasi menggunakan SMTP Anda tidak pernah tahu berapa lama akan mengambil pesan email untuk mendapatkan dari pengirim ke
penerima karena Anda tidak tahu bagaimana sibuk server, berapa banyak lalu lintas ada di Internet, apa mesin menurun untuk pemeliharaan, dll

Pesan Anda mungkin duduk di antrian pada sejumlah server untuk setiap jumlah waktu.Beberapa
server mungkin milik pihak ketiga (yaitu tidak mungkin berada di bawah lingkup baik pengirim atau penerima). pesan Anda, bahkan dalam kasus email Anda yang palsu oleh spammer. Mengambil Email Dari Server SMTP Ketika Anda menerima pesan email itu duduk dalam sebuah file di Server SMTP. Jika Anda ingin melihat pesan email yang Anda harus mengakses file ini. Setiap komputer yang ingin mengakses file Anda harus berbicara salah satu bahasa Server SMTP tidak. Dengan beberapa pengecualian, sebenarnya hanya ada 2 bahasa yang dipahami komputer email (untuk pengambilan email, sebagai lawan ke email pengirim, dimana mereka menggunakan SMTP), salah satu disebut "Internet Message Access Protocol" (IMAP) dan satu disebut "Post Office Protocol" ( POP ). (Kita tidak akan membahas rincian ini di sini, tetapi Anda mungkin tertarik dalam Memahami Layanan Email untuk informasi tentang mereka.)

Penerima Anda dapat menentukan alamat internet dan nama komputer dari tempat Anda mengirim

Sebagai penerima, biasanya Anda dapat mengambil email Anda dengan baik menggunakan antarmuka berbasis web yang dikenal sebagai "Webmail", atau melalui program "klien email", seperti Microsoft Outlook atau Eudora, berjalan pada komputer pribadi Anda. Program-program klien email akan berbicara langsung ke server email Anda dan berbicara IMAP atau POP. Dengan Webmail, komputer Anda akan berbicara ke server Webmail menggunakan koneksi web (HTTP berbicara); Webmail server akan, pada gilirannya, berbicara dengan server email Anda menggunakan POP atau IMAP. Kurangnya Keamanan di Email Email tidak aman. Pada bagian berikut, kita akan melihat betapa tidak aman itu. Pada tahap ini, penting untuk menunjukkan rasa tidak aman dalam jalur pengiriman email yang baru saja dibahas:

Webmail: Jika sambungan ke server Webmail Anda adalah "tidak aman" (yaitu alamat adalah http://
dan https:// TIDAK), maka semua informasi termasuk username dan password tidak dienkripsi saat melewati antara server Webmail dan Anda komputer.

SMTP: SMTP tidak mengenkripsi pesan (kecuali server dalam mendukung pertanyaanenkripsi TLS

oportunistik ). Komunikasi antara server SMTP dapat mengirim pesan Anda dalam teks biasa untuk setiap penguping untuk melihat. Selain itu, jika permintaan email server yang Anda kirim username dan password untuk "login" ke server SMTP untuk menyampaikan pesan ke server lain, maka ini juga dikirim dalam teks biasa, sesuai dengan menguping. Akhirnya, pesan yang dikirim melalui SMTP mencakup informasi tentang mana komputer mereka dan apa yang dikirim dari program email yang digunakan. Informasi ini, tersedia untuk semua penerima, mungkin menjadi perhatian privasi.

POP dan IMAP: The POP dan IMAP protokol mengharuskan Anda mengirim username dan password
untuk login, mandat ini tidak dienkripsi. Jadi, pesan dan kredensial dapat dibaca oleh setiap penguping mendengarkan aliran informasi antara komputer pribadi Anda dan komputer email penyedia layanan.

Backup: Pesan email disimpan di server SMTP di dataran, tidak terenkripsi teks. Backup data pada

server ini dapat dilakukan di setiap waktu dan administrator dapat membaca data pada mesin ini. Pesan email yang Anda kirim dapat disimpan secara tak terduga dan tanpa batas waktu dan dapat dibaca oleh orang tak dikenal sebagai hasilnya. Ini adalah hanya beberapa dari masalah keamanan yang melekat dalam email. Pada bagian berikutnya, kita akan berbicara tentang masalah komunikasi keamanan secara umum sehingga kita dapat melihat apa lagi yang bisa salah. Kemudian, kita akan melihat bagaimana masalah ini dapat dipecahkan.

Bagian 3: Keamanan Ancaman untuk Komunikasi Email Anda


Bagian ini menjelaskan banyak masalah keamanan umum yang terlibat dalam komunikasi dan email pada khususnya. Menguping: Internet adalah tempat yang besar dengan banyak orang di atasnya.Hal ini sangat mudah bagi seseorang yang memiliki akses ke komputer atau jaringan melalui mana informasi Anda bepergian untuk menangkap informasi ini dan membacanya. Sama seperti seseorang di kamar sebelah menguping pembicaraan telepon Anda, orang yang menggunakan komputer "dekat" jalan mengambil email Anda melalui Internet berpotensi dapat membaca dan menyalin pesan Anda! Pencurian Identitas: Jika seseorang bisa mendapatkan username dan password yang Anda gunakan untuk mengakses server email Anda, mereka dapat membaca email Anda dan mengirim pesan email palsu seperti Anda. Sangat sering, mandat ini dapat diperoleh dengan menguping SMTP, POP, IMAP, atau koneksi Webmail, dengan membaca pesan email di mana Anda memasukkan informasi ini, atau melalui cara lain. Invasi Privasi: Jika Anda sangat peduli tentang privasi Anda, maka Anda harus mempertimbangkan kemungkinan "backup dilindungi", tercantum di bawah ini. Anda juga mungkin khawatir membiarkan penerima Anda mengetahui alamat IP dari komputer Anda. Informasi ini dapat digunakan untuk mengatakan dalam apa kota Anda berada atau bahkan untuk mencari tahu apa alamat Anda dalam beberapa kasus! Ini bukan masalah dengan Webmail, POP , atau IMAP , tetapi merupakan masalah engan pengangkutan email, aman atau insecurely, dari klien email melalui SMTP . Modifikasi Pesan: Siapapun yang memiliki izin sistem administrator pada salah satu Server SMTP yang dilihat pesan Anda, tidak bisa hanya membaca pesan Anda, tetapi mereka dapat menghapus atau mengubah pesan sebelum terus ke tujuannya. Penerima tidak memiliki cara untuk mengetahui apakah pesan email yang Anda kirimkan telah diubah! Jika pesan itu hanyalah dihapus mereka tidak akan tahu itu telah dikirim. Pesan Palsu: Sangat mudah untuk membangun pesan yang tampaknya dikirim oleh orang lain. Banyak virus memanfaatkan situasi ini untuk menyebarkan diri. Secara umum, tidak ada cara untuk memastikan bahwa pengirim pesan jelas adalah pengirim benar - nama pengirim bisa saja dengan mudah dibuat. Replay Pesan: Sama seperti pesan dapat dimodifikasi, pesan dapat disimpan, dimodifikasi, dan dikirimkan kembali nanti! Anda bisa menerima pesan asli yang sah, tetapi kemudian menerima pesan palsu berikutnya yang tampaknya valid. Backup tidak dilindungi: Pesan disimpan dalam teks biasa pada semua SMTP Server. Jadi, backup disk server ini 'berisi salinan teks biasa dari pesan Anda. Seperti backup dapat disimpan selama bertahun-tahun dan dapat dibaca oleh siapapun yang memiliki akses kepada mereka, pesan Anda masih bisa terkena di tempat-tempat yang tidak aman bahkan setelah Anda berpikir bahwa semua salinan telah "dihapus". Repudiation: Karena pesan email normal dapat ditempa, tidak ada cara bagi Anda untuk membuktikan bahwa seseorang mengirimkan pesan tertentu. Ini berarti bahwa bahkan jika seseorang DID mengirimkan pesan, mereka berhasil dapat menyangkalnya. Hal ini memiliki implikasi berkaitan dengan menggunakan email untuk kontrak, komunikasi bisnis, perdagangan elektronik, dll

Bagian 4: Enkripsi simetris dan asimetris dalam pendeknya


Dalam rangka untuk memahami bagaimana kita dapat mengurangi masalah keamanan yang dijelaskan dalam Bagian 2 dan 3, pengetahuan dasar dari dua jenis utama dari enkripsi akan sangat berguna.Bagian ini menyajikan konsep-konsep ini dalam bentuk sederhana, lugas.

Symmetric Encryption Pada enkripsi simetris, Anda dan teman Anda berbagi "rahasia" kunci. Menggunakan kunci ini, Anda dapat mengenkripsi pesan ke "cyphertext". Cyphertext tampak seperti urutan acak karakter dan benar-benar berarti kepada siapa pun kecuali mereka juga memiliki kunci rahasia, dalam hal ini mereka dapat mendekripsi kembali cyphertext ke pesan asli dan membacanya. Menggunakan enkripsi kunci simetris, menguping dan backup yang tidak diinginkan dari pesan Anda tidak lagi merupakan masalah (kecuali penguping mengetahui apa kunci rahasia anda). Hal ini juga menjadi lebih sulit bagi seseorang untuk memodifikasi pesan Anda dalam perjalanan dalam setiap jenis cara yang berarti. Masalah dengan enkripsi kunci simetris justru kenyataan bahwa Anda dan teman Anda harus berbagi kunci rahasia yang sama. Kecuali Anda bertemu langsung, bagaimana Anda berkomunikasi kunci ini dalam cara yang aman? Bagaimana jika Anda ingin mengirim pesan aman kepada seseorang di sisi lain dunia? Bagaimana Anda mendapatkan mereka kunci rahasia cepat dengan cara yang penyadap tidak dapat mendeteksi? Pesan Digests Kode / Otentikasi Sebuah "Message Digest" atau "Pesan Kode Otentikasi" benar-benar sebuah konsep yang sangat sederhana. Anda mengambil pesan Anda dan menyebarkannya melalui suatu algoritma yang meludah keluar urutan relatif singkat karakter (mungkin 64 atau 128 atau lebih dari mereka). Ini urutan karakter adalah "sidik jari" pesan. Setiap perubahan menit dalam pesan akan menghasilkan "sidik jari" sangat berbeda. Tidak ada cara untuk mendapatkan pesan asli dari sidik jari dan hampir mustahil untuk menemukan dua pesan yang menghasilkan sidik jari yang sama (seperti mencoba untuk menemukan dua orang asing yang memiliki sidik jari yang sama).

Pesan Digests adalah cara cepat untuk memeriksa untuk melihat apakah pesan telah diubah. Jika Anda memiliki intisari dari pesan asli dan membandingkannya dengan digest dari pesan yang Anda baru saja menerima dan mereka cocok, maka Anda tahu bahwa pesan telah berubah. Enkripsi asimetris Dalam enkripsi asimetris, juga dikenal sebagai "public key" enkripsi, setiap orang memiliki DUA tombol.Setiap cyphertext dibuat menggunakan salah satu kunci dapat didekripsi HANYA menggunakan tombol lain. Sebagai contoh, katakanlah Anda memiliki kunci-kunci "K1" dan "K2". Jika Anda menyandikan pesan Anda dengan K1, K2 HANYA kemudian dapat digunakan untuk mendekripsi itu. Demikian pula, jika Anda mengenkripsi menggunakan K2, K1 HANYA dapat digunakan untuk mendekripsi itu. Hal ini jelas berbeda dari enkripsi kunci simetris di mana Anda hanya memiliki satu kunci yang melakukan kedua fungsi pada pesan yang sama. Dalam enkripsi kunci asimetris, dua kunci yang dimiliki setiap orang biasanya bernama "pribadi" dan "publik" kunci karena "publik" satu ini diterbitkan atau diberikan secara bebas kepada siapa saja yang ingin salinan dan "pribadi" satu disimpan rahasia. Keamanan enkripsi kunci asimetris hanya bergantung pada apakah Anda dapat menyimpan rahasia kunci pribadi Anda. Enkripsi kunci asimetris memungkinkan Anda untuk melakukan hal-hal pintar banyak:

Kirim Pesan Terenkripsi: Untuk mengirim pesan aman untuk seseorang, yang harus Anda lakukan

adalah mengenkripsi dengan kunci publik mereka! Hanya penerima yang dimaksud yang memiliki kunci pribadi yang sesuai akan dapat mendekripsi dan membaca pesan tersebut. Ini memecahkan masalah menguping dan masalah pengiriman kunci rahasia yang melekat pada enkripsi kunci simetris.

Buktikan Anda Terkirim Pesan: Untuk membuktikan kepada seseorang yang Anda kirimkan pesan,
Anda dapat mengenkripsi pesan (atau hanya sepotong itu) dengan kunci pribadi Anda. Kemudian, siapapun dapat mendekripsi dengan kunci publik anda dan membaca isinya. Fakta bahwa kunci publik Anda mendekripsi pesan membuktikan bahwa hanya Anda bisa mengirimkannya.

Pesan Masuk: Sebuah tanda tangan pesan membuktikan bahwa Anda mengirim pesan DAN

memungkinkan penerima untuk menentukan apakah pesan telah diubah dalam perjalanan.Hal ini dilakukan dengan menggunakan kunci pribadi Anda untuk mengenkripsi mencerna pesan pada saat pengiriman. Penerima dapat mendekripsi ini mencerna dan membandingkannya dengan intisari dari pesan yang diterima. Jika mereka cocok, maka pesan tidak berubah dan dikirim oleh Anda.

Dienkripsi, Pesan Tertanda: Bentuk paling aman dari komunikasi adalah untuk pertama

menambahkan Signature pada pesan dan kemudian untuk mengenkripsi pesan ditambah tanda tangan dengan kunci publik penerima. Ini menggabungkan semua manfaat dari semua teknik: keamanan menghadapi eavesdropping dan penyimpanan tak terduga, bukti pengirim, dan bukti pada integritas pesan.

Bagian 5: Mengamankan Email Anda Dengan SSL atau TLS


Hal termudah yang dapat Anda lakukan untuk membuat email anda lebih aman adalah dengan menggunakan penyedia layanan email yang mendukung " Secure Socket Layer "(SSL) untuk Webmail mereka, POP, IMAP, dan SMTP server. TLS adalah jenis SSL yang dapat dimulai selama sesi mail; tidak seperti TLS, SSL harus dimulai sebelum mengirim email (lihat SSL vs TLS - Apa bedanya? ). SSL adalah kombinasi asimetris dan simetris mekanisme enkripsi kunci. Jika Anda terhubung ke server menggunakan SSL, hal-hal berikut terjadi (kira-kira): 1. Server menggunakan kunci pribadi untuk membuktikan kepada Anda bahwa itu sebenarnya server yang Anda mencoba untuk menyambung ke. Hal ini memungkinkan Anda tahu bahwa Anda tidak terhubung ke sebuah "perantara" yang mencoba untuk mencegat komunikasi Anda. Anda mengirim server kunci publik Anda. Server menghasilkan sebuah "kunci rahasia" dan mengirimkannya ke Anda dienkripsi menggunakan kunci publik Anda.

2. 3.

4.

Anda dan server kemudian berkomunikasi menggunakan enkripsi kunci simetris menggunakan kunci rahasia bersama. (Enkripsi kunci simetris lebih cepat dari enkripsi kunci asimetrik).

Manfaat dari SSL dua: 1. Anda dapat menentukan apakah Anda terhubung ke server yang tepat, dan 2.Anda dan server dapat berkomunikasi dengan aman. Jika Anda mendapatkan pesan peringatan saat menghubungkan ke server menggunakan SSL , Anda harus berpikir dua kali untuk mengabaikan mereka. Sementara penyedia Anda hanya mungkin memiliki masalah teknis kecil yang menyebabkan peringatan, peringatan ini juga dapat menunjukkan bahwa komunikasi Anda sedang disadap. Peringatan ini biasanya menunjukkan salah satu dari berikut: 1. 2. SSL server "sertifikat" (yaitu pasangan kunci publik / privat) telah kedaluwarsa. Beberapa informasi dalam sertifikat tidak cocok dengan informasi yang Anda harapkan - yaitu sertifikat dikeluarkan untuk nama server yang berbeda dari yang Anda mencoba untuk menyambung ke. (Anda bisa secara tidak sengaja terhubung ke server yang salah.) Sertifikat dikeluarkan oleh lembaga yang tidak dipercaya.

3.

Sertifikat SSL adalah (umumnya) yang dikeluarkan oleh lembaga pihak ketiga seperti Thawte.com atau VeriSign. Perusahaan-perusahaan pihak ke-3 melakukan pemeriksaan latar belakang pada perusahaan yang meminta sertifikat, dan hanya sertifikat masalah jika perusahaan memiliki hak untuk mereka.Sertifikat mencakup nama perusahaan, nama perusahaan yang menerbitkan, dan nama server untuk yang dikeluarkan. Bila Anda terhubung ke server SSL Anda dapat memverifikasi informasi ini tertanam dan fakta bahwa itu dikeluarkan oleh sebuah perusahaan pihak ketiga yang Anda percaya. Jika sertifikat tersebut valid, maka Anda dapat memiliki tingkat kepercayaan yang tinggi bahwa server Anda tersambung ke adalah server yang ingin Anda jangkau. Dengan menggunakan SSL untuk Webmail, POP, IMAP, dan SMTP (lihat SMTP TLS ) Anda memastikan bahwa komunikasi antara komputer pribadi Anda dan komputer email penyedia layanan Anda akan dienkripsi. Pesan Anda isi, username, dan password akan tersembunyi dari penyadap - tetapi hanya tersembunyi dari penyadap antara Anda dan penyedia layanan Anda! Layanan SSL tidak melindungi pesan Anda setelah mereka meninggalkan SMTP Server dan kepala Anda ke tujuan mereka. Jadi, tidak benar-benar melindungi isi pesan Anda, tetapi tidak sepenuhnya melindungi username dan password dari deteksi. Hal ini sangat penting karena mencegah pencurian identitas, pesan ditempa, dll SSL adalah sangat mudah digunakan. Ini biasanya hanya melibatkan mengklik kotak centang beberapa dalam konfigurasi email client Anda. Hal ini transparan kepada penerima Anda - Anda dapat menggunakan SSL untuk layanan ini bahkan jika Anda penerima tidak. Langkah-langkah ini melindungi Anda dan password Anda. Karena sangat mudah dan karena keamanan yang Anda terima jauh lebih baik daripada tidak ada keamanan, kami sangat mendorong penggunaan SSL untuk komunikasi email bila memungkinkan.

Bagian 6: Privasi dengan SMTP Anonim


Dalam Bagian 2 dan 3 kita menulis bahwa ketika Anda mengirim email melalui klien email (tapi tidak Webmail), alamat Internet komputer Anda termasuk dalam pesan untuk semua penerima untuk melihat.Tergantung standar privasi Internet Service Provider dan apa jenis koneksi dan layanan yang Anda miliki, informasi ini dapat digunakan untuk menentukan apa daerah atau negara tempat Anda berada, apa kota tempat Anda berada, atau bahkan apa alamat Anda! Ini bisa menjadi masalah serius bagi orang yang sangat peduli tentang privasi mereka. Selain itu, informasi lain seperti apa program email yang Anda gunakan juga terlihat ke penerima. Anonim SMTP layanan, atau re-mailer, menyediakan cara yang baik untuk menjaga semua fungsi SMTP yang Anda butuhkan, sementara memberikan Anda kembali privasi Anda. Layanan ini biasanya menerima pesan Anda melalui (Authenticated) SMTP (idealnya mereka juga akan mendukung SMTP atas SSL, seperti dijelaskan di atas) dan kemudian "menggosok" pesan, menghapus semua informasi tentang alamat komputer Anda, program email Anda, dan setiap non- standar informasi. Layanan ini kemudian kembali pesan email menggosok Anda ke penerima.

Hasil akhirnya adalah bahwa penerima mendapatkan pesan seperti mereka akan tanpa layanan "Anonim", kecuali bahwa mereka hanya dapat melacak pesan kembali ke server SMTP Anonim Anda.Mereka tahu siapa Anda, berdasarkan pada alamat email Anda dan isi pesan Anda, tetapi mereka tidak memiliki cara untuk mengetahui mana Anda berada atau apa program email yang Anda gunakan. Kebanyakan layanan SMTP anonim log semua informasi yang mereka menggosok pesan dan melacak semua aktivitas. Jadi, sementara penerima tidak tahu di mana Anda berada, penyedia layanan email Anda tidak. Hal ini untuk mencegah jenis layanan dari memberikan manfaat nyata bagi orang yang mengirim email yang tidak diminta atau dipalsukan - penyedia layanan mereka dapat dengan cepat menanggapi keluhan atau penyalahgunaan, mengidentifikasi pengirim, dan mengakhiri account dan / atau membawa tindakan hukum untuk menanggung. Apa itu tidak memberikan adalah tingkat privasi dalam mengirimkan email yang secara fungsional setara dengan tingkat privasi yang Anda dapatkan dari pengiriman melalui antarmuka Webmail (kecuali Webmail tersebut membuat satu titik untuk menambahkan alamat komputer Anda ke dalam pesan keluar - paling tidak). LuxSci menawarkan layanan SMTP Anonim kepada semua klien yang memiliki layanan SMTP relaying.Layanan ini kompatibel dengan SMTP LuxSci atas layanan SSL sebagai baik dan hanya membutuhkan perubahan port yang Anda gunakan untuk menghubungkan ke server SMTP LuxSci itu.

Bagian 7: Enkripsi kunci asimetrik dan Email (PGP dan S / MIME)


Sementara SSL melindungi password Anda dan isi pesan Anda sampai batas tertentu, itu tidak memecahkan salah satu masalah lain yang telah kita bahas: penolakan, enkripsi, backup yang tidak diinginkan, modifikasi pesan, dll Hal ini karena SSL hanya melindungi jalan pesan antara Anda dan SMTP Server dan berhenti di sana. Bahkan dengan SSL, pesan yang disimpan pada server SMTP Anda dalam teks biasa. Solusi utamanya adalah untuk menggunakan enkripsi kunci asimetris untuk memberikan tanda tangan pesan dan / atau enkripsi. Ini benar-benar memecahkan masalah:

Menguping (semuanya selalu dienkripsi) Pesan modifikasi (pesan mencerna digunakan) Pesan ulangan (Anda dapat menyertakan timestamp di signature) Repudiation (tanda tangan memungkinkan bukti yang mengirim pesan) Unprotected backup (semuanya selalu dienkripsi)
Enkripsi kunci asimetrik harus digunakan dalam kombinasi dengan SSL, sehingga username dan password yang juga dilindungi. Mengapa? Mandat ini bukan bagian dari pesan dan dengan demikian tidak akan dienkripsi bersama dengan pesan. Untungnya (atau sayangnya), ada dua bentuk banyak digunakan enkripsi kunci asimetris untuk email: S / MIME dan PGP. Keduanya memungkinkan Anda untuk menambahkan tanda tangan dan / atau enkripsi untuk pesan Anda. PGP dapat diperoleh dari PGP.com dan kompatibel dengan klien email standar. S / MIME dibangun ke klien email yang banyak seperti Microsoft Outlook, tapi Anda harus memperoleh sertifikat S / MIME dari perusahaan pihak ketiga seperti Thawte.com . Interoperabilitas Masalah PGP dan S / MIME memecahkan banyak masalah, tetapi mereka juga membuat lain: interoperabilitas.Salah satu isu interoperabilitas adalah bahwa PGP dan S / MIME yang benar-benar cocok! Jika Anda menggunakan PGP dan teman Anda menggunakan S / MIME, Anda tidak akan dapat saling mengirim pesan aman lainnya. Yang mengatakan, PGP telah menjadi standar Internet (OpenPGP - RFC 2440) sejak tahun 1997 dan PGPdienkripsi account email selama lebih dari 90% dari lalu lintas email terenkripsi saat ini di Internet.Jadi,

menggunakan PGP akan membuat Anda kompatibel dengan mayoritas. Namun, mayoritas tidak peduli ketika Anda mencoba untuk menghubungi minoritas yang menggunakan S / MIME. Hal ini berguna untuk mengetahui bahwa beberapa klien email, seperti Microsoft Outlook, dapat dikonfigurasi untuk menggunakan KEDUA PGP dan S / MIME sehingga Anda dapat sesuai dengan aman menggunakan metode apapun yang diperlukan saat ini. Selain itu, kebanyakan program email utama memiliki dukungan untuk S / MIME dibangun pada (dan tidak PGP) ... sehingga lebih mudah dan murah untuk memulai dengan S / MIME. Masalah interoperabilitas lain melibatkan "pertukaran kunci". Jika Anda ingin mengirim pesan teman Anda dienkripsi, Anda harus terlebih dahulu / nya kunci publik-nya, jika teman Anda ingin membuktikan bahwa Anda menandatangani pesan atau bahwa pesan yang Anda kirim dia / nya tidak berubah, s / ia pertama kebutuhan Anda kunci publik. Jadi ada keharusan perdagangan kunci publik sebelum komunikasi yang aman dapat dimulai. Ada berbagai cara untuk perdagangan kunci (termasuk email).PGP menawarkan "server kunci" dari mana kunci koresponden Anda 'dapat didownload untuk membuat proses lebih mudah. Namun, tidak semua orang memiliki kunci PGP mereka terdaftar pada server kunci, apalagi server kunci yang sama, dan tidak semua orang menggunakan PGP, sehingga masalah pertukaran kunci masih merupakan halangan untuk mengirim pesan aman - terutama jika Anda harus mengirim mereka dengan cepat.

Bagian 8: Keamanan Kompatibel dengan Enkripsi Escrow


Escrow enkripsi menggunakan perantara "enkripsi" dipercaya untuk memberikan keamanan yang sama ditawarkan oleh enkripsi kunci asimetrik, tapi dengan kompatibilitas universal. Berikut adalah cara kerjanya: 1. 2. 3. 4. 5. Pengirim menghubungkan ke portal mail perantara web pada koneksi SSL aman Perantara memvalidasi pengirim. Pengirim membuat pesan. Pengirim pesan membuat pertanyaan rahasia dan jawabannya bagi si penerima. Hanya penerima tahu jawaban untuk pertanyaan itu. Perantara mengenkripsi pesan dan menyimpannya di server-nya. perantara web, dan password pesan unik yang merupakan bagian dari kunci enkripsi.Perantara kemudian 'lupa' password ini sehingga ia tidak dapat mendekripsi pesan sampai dia mendapatkan password kembali dari penerima. 7. 8. Penerima terhubung ke portal perantara atas koneksi SSL aman dan log in dengan password pesan. Perantara meminta penerima pertanyaan rahasia. Jika dia menjawab dengan benar tengkulak decrypts pesan dan menyajikan kepada penerima.

6. Perantara mengirim pesan teks biasa ke penerima yang hanya berisi link yang aman ke portal mail

Perantara enkripsi menangani semua pekerjaan enkripsi kotor, itu tidak masalah jika pengirim dan penerima menggunakan PGP menggunakan S / MIME. Bahkan, tidak masalah jika salah menggunakan enkripsi sama sekali! Semua bahwa pengirim dan penerima butuhkan adalah koneksi internet yang aman. Perantara mengurus segala sesuatu yang lain. Bagaimana memecahkan masalah keamanan yang telah kita sebutkan sebelumnya?

Menguping: Tidak ada yang bisa menguping pada pesan karena pengirim dan penerima terhubung ke
tengkulak pada koneksi SSL aman.

Pencurian Identitas: Tidak seorangpun dapat mencuri informasi login pengirim atau pertanyaan
rahasia / jawabannya karena baik pengirim dan penerima menggunakan koneksi SSL. tahu bahwa dia menggunakan perantara. perantara itu.

Invasi Privasi: Penerima tahu apa-apa tentang komputer pengirim, klien email, atau lokasi.Dia hanya Modifikasi Pesan: Tidak seorangpun dapat mengubah pesan karena tidak pernah meninggalkan server Salah Pesan: Pesan ini hanya diakses pada server perantara, sehingga tidak ada yang bisa berpurapura untuk mengirimnya.

Replay Pesan: Tidak seorangpun dapat mengubah pesan karena tidak pernah meninggalkan server
perantara itu.

Backup tidak dilindungi: Pesan dienkripsi ketika disimpan, sehingga aman bahkan di backup. Repudiation: penerima mengetahui bahwa pengirim benar-benar mengirim pesan karena ia divalidasi
oleh tengkulak.

Selain itu perantara dapat menyimpan log dari yang mengakses pesan dan berapa kali. Sehingga pengirim dapat mengaudit pesan untuk melihat siapa yang telah dilihat itu. Perhatikan bahwa pesan tersebut aman dan anonim; pesan dienkripsi dan disimpan pada server perantara itu, sehingga tidak tunduk pada keamanan server menyampaikan menengah. Hanya perantara dapat mengenkripsi dan mendekripsi pesan tersebut, dan hanya penerima yang berwenang dapat mengakses pesan. Penerima tahu apa-apa tentang komputer pengirim, hanya bahwa dia menggunakan perantara. Selama sebagai perantara yang dapat dipercaya, pesan benar-benar aman, benar-benar anonim, dan sepenuhnya kompatibel. LuxSci yang SecureLine layanan menyediakan lengkap, keamanan yang kompatibel melalui enkripsi escrow.

Bagian 9: Kesimpulan
! Email, secara umum, Lengkap Insecure Isu-isu keamanan meliputi:

Menguping Pencurian Identitas Invasi Privasi Pesan Modifikasi Salah Pesan Pesan Replay Unprotected Backup Repudiation (Sender menyangkal bahwa s / ia mengirimnya)
SSL: Hal ini sederhana dan mudah untuk menggunakan SSL untuk mengamankan komunikasi antara komputer Anda dan komputer email penyedia layanan. Ini bekerja tidak peduli siapa penerima Anda. SSL meningkatkan keamanan dalam cara:

Ini memastikan bahwa Anda berada menghubungi penyedia layanan komputer Anda dan bukan orang
lain

Ini mengenkripsi username dan password yang Anda gunakan untuk login ke server ini. Ini meringankan
pencurian identitas dan isu-isu lainnya.

Ini melindungi Anda dari pesan penyadap antara komputer Anda dan server SMTP Anda.
Anonimitas: Jika Anda memiliki akses ke server SMTP Anonim, Anda memiliki cara mudah untuk meningkatkan privasi Internet Anda. SMTP anonim menyediakan:

Privasi alamat IP sehingga penerima pesan tidak dapat menentukan alamat Internet komputer Anda
(dan dengan demikian lokasi Anda). Anda gunakan.

Privasi klien email sehingga penerima pesan email Anda tidak bisa menentukan jenis klien email yang Sebuah cara untuk menghapus non-standar lainnya "email header" data yang mungkin bersembunyi di
pesan keluar Anda.

PGP dan S / MIME: PGP dan S / MIME menggunakan enkripsi kunci kunci asimetris untuk melindungi isi pesan Anda sepanjang perjalanan lengkap. Mereka menyediakan:

Perlindungan terhadap menguping dan backup yang tidak diinginkan

Pesan Digests untuk mendeteksi apakah pesan telah diubah dalam transit Tanda tangan untuk membuktikan keaslian pengirim
Saya sangat merekomendasikan penggunaan SSL untuk komunikasi email. Sayangnya, PGP dan S / MIME tidak digunakan sebagai ekstensif seperti yang seharusnya. Dalam pengalaman saya, semakin banyak perusahaan menggunakan SSL untuk mengenkripsi komunikasi dengan server email mereka, tetapi sedikit yang menggunakan PGP atau S / MIME untuk enkripsi. Saya melihat hambatan adalah bahwa upaya yang dibutuhkan untuk melakukan setup, untuk menegakkan penggunaan, dan untuk melatih karyawan dipandang sebagai jauh lebih besar (atau lebih mahal) daripada manfaat penggunaan. Jelas, penghematan biaya yang diperoleh dengan menggunakan pesan aman dalam memiliki kebocoran informasi yang kurang atau modifikasi yang sangat sulit untuk dihitung, terutama karena sebagian besar perusahaan menganggap bahwa mereka tidak (atau tidak akan) memiliki masalah yang signifikan di arena ini pula. Asumsi ini akan berubah. Enkripsi escrow menghindari hambatan dari PGP dan S / MIME enkripsi sambil memberikan keamanan yang lengkap, anonimitas, dan fitur lainnya. Tidak ada kurva belajar untuk enkripsi escrow karena dapat dengan mudah diintegrasikan ke dalam sistem web mail yang ada. Siapapun yang peduli tentang keamanan tetapi tidak tahu cara mengatur itu dapat menggunakan enkripsi escrow semudah mereka menggunakan web mail. Selain itu, dapat berkomunikasi dengan aman dengan siapa saja yang memiliki koneksi internet. Tidak seperti komputer break-in dan masalah keamanan lainnya, masalah dengan keamanan email sangat sulit untuk dideteksi. Anda tidak dapat mengetahui apakah seseorang membaca email Anda atau memodifikasi pesan halus sampai terlalu terlambat. Anda tidak dapat mengkuantifikasi biaya masalah keamanan email dan informasi sampai terlalu terlambat - bayangkan semua hal yang orang menulis dalam pesan mereka .... dan berpikir dua kali.

Introduction to Security Issues in Email - PGP, S/MIME and SSL


Although we now take the email for granted, it is important to realise that - in its most basic form, at least - it is not necessarily a very secure or private means of communication. In fact, email has often been likened to the use of the postcard in conventional postal systems: it is open to being read or tampered with during transmission, and it might not even actually come from the person who apparently sent it. For casual, social messages this might not be a great concern. However, there are many situations when you might want to guarantee the privacy or authenticity of an email. There are two main strategies for making your email secure and private:

Use email encryption software to encode your messages, which are then decoded by the recipient after delivery. Even if a message is viewed in transit by someone else, they will not be able to decipher it. Email encryption software can also be used to digitally sign a message to guarantee it really did originate from the apparent sender. Two of the most widely used email encryption systems is called PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions). Use a secure connection system between your own machine and the server this is rather like the use of a `scrambler' on a conventional phone system. This protects all forms of information - for example passwords - passing between a workstation and a remote server, not just email messages. It prevents against anyone 'snooping' on your connection's network traffic, although offers no protection on information once it passes beyond the secure connection. One of the most widely used forms of secure connection system is known as SSL.

Most popular security systems, including those mentioned above, are based on the concept of Public Key Encryption. This involves the use of a linked pair of digital "keys":

a public key, freely publicised by its owner, which is used to encrypt information being sent to that person or system. a private key, known only to its owner, used to decode incoming information encrypted with the corresponding public key.

http://www.oucs.ox.ac.uk/email/secure/

Pengantar Masalah Keamanan di Email - PGP, S / MIME dan SSL


Meskipun kita sekarang mengambil email untuk diberikan, penting untuk menyadari bahwa - dalam bentuk yang paling dasar, setidaknya - itu tidak selalu berarti sangat aman atau swasta komunikasi. Bahkan, email telah sering disamakan dengan penggunaan kartu pos dalam sistem pos konvensional: ini terbuka untuk membaca atau dirusak selama transmisi, dan bahkan mungkin tidak benar-benar datang dari orang yang tampaknya mengirimkannya. Untuk santai, pesan sosial ini mungkin tidak menjadi perhatian besar. Namun, ada banyak situasi ketika Anda mungkin ingin menjamin privasi atau keaslian dari email. Ada dua strategi utama untuk membuat email Anda aman dan swasta:

Gunakan perangkat lunak email enkripsi untuk menyandikan pesan Anda, yang kemudian diterjemahkan oleh penerima setelah melahirkan. Bahkan jika pesan dipandang dalam transit oleh orang lain, mereka tidak akan mampu memahaminya. Email perangkat lunak enkripsi juga dapat digunakan untuk digital sign pesan untuk menjamin itu benar-benar berasal dari pengirim yang jelas. Dua sistem email yang paling banyak digunakan enkripsi disebut PGP (Pretty Good Privacy) dan S / MIME (Secure Internet Extensions / Multipurpose Mail). Menggunakan sistem koneksi yang aman antara mesin anda sendiri dan server - ini agak seperti penggunaan pengacak `'pada sistem telepon konvensional. Ini melindungi segala bentuk informasi - untuk password misalnya - melewati antara workstation dan server jauh, bukan pesan hanya email. Ini mencegah terhadap 'mengintip' siapa pun pada lalu lintas koneksi jaringan Anda, meskipun tidak menawarkan perlindungan pada informasi setelah melewati luar sambungan aman. Salah satu bentuk yang paling banyak digunakan sistem sambungan aman dikenal sebagai SSL.

Sistem keamanan yang paling populer, termasuk yang disebutkan di atas, didasarkan pada konsep Enkripsi Kunci Publik. Ini melibatkan penggunaan sepasang terkait digital "kunci":

kunci publik, bebas dipublikasikan oleh pemiliknya, yang digunakan untuk mengenkripsi informasi yang dikirim ke orang atau sistem. kunci privat, yang hanya diketahui oleh pemiliknya, digunakan untuk decode informasi yang masuk dienkripsi dengan kunci publik yang sesuai.

Você também pode gostar