Possible Duplicate:
How commonly are SSL/TLS or S/MIME used by e-mail providers?
Say, Alice uses gmail and Bob uses hotmail. Alice wants to send an email to Bob.
Alice goes to gmail website with https and sends her email. Bob will also use https to receive the email.
Gmail will then forward the email to hotmail. During this phase, is the email encrypted? Is the encrypted/unencrypted transmission a common practice among any formal email service providers?
Hotmail's SMTP servers don't use TLS security in transport... the behind-the-scenes SMTP activity that makes the message appear in the different ISP. You can validate this by looking at the SMTP headers. In Gmail, you need to click "view original" to see these headers.
Gmail, Yahoo, and many other providers encrypt messages in transport with TLS security. For some reason Hotmail doesn't.
Some email providers use TLS encryption opportunistically (when both sender and receiver appear to support it; this is described in RFC 3207). Note that such opportunistic detection cannot provide absolute security: the messages which sender and receiver exchange, and which state whether STARTTLS is supported or not, are unprotected. An attacker doing a man in the middle attack can intercept these messages and force sender and receiver not to use TLS. To enable protection against such attacks, the SMTP servers should not only use TLS, but also refuse to talk to the other server unless TLS can be used.
In practice, opportunistic encryption will give some protection against passive eavesdroppers: somewhat fabled big-eared people who tap on network links and listen but never interfere. An important point is that while TLS protects data while in transit, it does nothing for data at rest: the involved servers (the SMTP servers through which the email goes, and the IMAPS or HTTPS-Webmail servers which host the "Inbox" folder of the recipient and the "Sent Messages" folder of the sender) see the data unencrypted, and write it on hard disks. The email contents are vulnerable at these points.
If I were a spy (employed by a State-funded agency, or, as is more often the case nowadays, hired by your competitors), I would not go to the technical troubles of locating communication cables and plugging in; I would bribe one or two interns who work at your ISP, and make them purloin old backup tapes or disks (with the widespread usage of RAID, whole disks can be stolen without even stopping the service, thus discreetly). Not amount of STARTTLS will protect you against that.
As @Lucas says, if you are serious about email security, you need end-to-end protection: S/MIME or OpenPGP (e.g. the GnuPG implementation of the latter).
That would depend how they configure their mailservers. Normally the connection between the mailservers can be encrypted as well using TLS/SSL. Considering Gmail and Hotmail is being run by MS and Google, normally this should be enabled. (unforunately only Gmail does this, and they don't force it if the other end wants to talk plain)
If you are uncertain, you can always use GPG/PGP
EDIT
Possible other answer on here: What steps do Gmail, Yahoo! Mail, and Hotmail take to prevent eavesdropping on email?
You may also be interested in this answer
To answer your boiled-down question: How insecure is email? Practically speaking email is subject to attack by DNS spoofing, WIFI interception, and untrusted network administrators just to name a few.
To mitigate this you need to consider the different aspects that need security. It's likely most companies will fall short in security in at least one of the following areas, so anything you send could be in clear text and visible by someone other than your intended recipient.
Under each facet of security I listed relevant products grouped by how they are technically implemented. Ask yourself these questions based on the content you're sending over email:
Message Sender Verification
Does the recipient need proof that it was you who actually sent the message?
- SenderID/SPF Records (weak verification)
- Domain Keys / DKIM (strength depends on implementation)
- DMARC (Strong validation of the display from user... hybrid of SenderID and DomainKeys)
- PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
- Portal-based products (Voltage, Proofpoint, Zixmail)
- Microsoft RMS server + Outlook
Message Transport
Do I need to prevent unauthorized reading or modification of the email sender's MTA and my MTA?
- Enforced TLS, with certificate validation. Non-validated certs are subject to MITM attacks.
- Zix-based TLS is a private TLS network that doesn't require manual configuration
- PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
- Portal-based products (Voltage, Proofpoint, Zixmail)
- Microsoft RMS server + Outlook
Reading the message
Must I ensure that only the intended recipient is able to read the message content?
- PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
- Portal-based products (Voltage, Proofpoint, Zixmail)
- Microsoft RMS server
Must the client endpoint be secure? (applies if above 3 products aren't used)
- The target network administrator is delivering email using a secure transport (Encrypted MAPI, POP3 over TLS, etc)
- The target device is secure. This applies to workstations, and mobile devices.
- Microsoft UAG adds features to OWA where the endpoint is audited and will delete left-over attachments in
%temp%and restrict or deny access to features as policy dictates- An alternative to UAG is to block attachments from reaching the client (as Henri first mentioned)
gmail.smtp.com use two packages SASL and TLS. When you hit gmail.smtp.com on 587 port it will ask user/pass which you will supply by SASL package and encryption of user/pass is attained by TCP TLS package .. you can use tcl script with this packages for sending a mail.
If you are worried about the security of your email, the only way to have some reasonable confidence is to manage the encryption yourself, using something like PGP/GPG. Some points to note
When using a web client, https only encrypts your communicaiton to the mail service you are using. It provides no guarantee regarding the level of encryption which occurs during the message transport process which occurs between the servers
Some SMTP servers do support TLS etc if asked to use it. However, there is nothing in the SMTP protocol specification which requires them to do so. Many SMTP servers don't provide it.
You have no guarantee regarding the mail servers a message will be passed through. Many people think that when you send a message from server a to server b that the message is always passed as a direct connect between those two servers. This is not necessarily true. The SMTP protocol was designed at a time when networks and sesrvers were far less reliable than they are now and when many places did'nt have direct connections to the core network. To enable reliable mail delivery, the protocol supports mail relaying. In simplistic terms, the sending mail server can say "Hey, I've got a message for gmail, but I can't seem to raise him and I have to go and upgrade my kernel, can someone pass this message on for me when he returns? I would do it, but I have to go an upgrade my kernel and won't be around for a while". Another, possibly previously unknown server may respond saying "Hey sure, I am an MX host for your recipient domain, I can relay the message for you".
While all of this means that email is usually fairly robust, in the sense that mail sent to a legitimate address will usually get delivered successfully or bounced back and rarely just vanishes, it does create some weaknesses in the protocol which expose the system to a number of exploits, such as DNS spoofing. Even if you ignore the transport aspect of email, there is also the issue that messages are routinely saved on servers unencrypted, such as in mail spool directoires, making them readily accessible to anyone whith sufficient access rights on the server. Even forgetting that, how many of the people you have sent mail to actually store or archive that mail in an encrypted secure manner? If I sent you a message with sensitive data in it, do you encrypt it before storing it in you mail archive? No? So what happens to my sensitive mail message when you computer is infected with a virus or malware? What control do I have over this sensitive information once I send it to you?
Email infrastructure was designed at a time when security was not a high priority. The huge growth and the desire to keep everything working and the need to maintain backwards compatibility means that many of the enhancements which have been introduced, such as encryption of communicaiton between servers etc is optional and therefore cannot e guaranteed and although there have been many improvements, at the end of the day, you have to consider email as an inherently insecure communicaiton channel. Unless the sender and recipient take additional action to increase the security of email communicaitons, you should consider the message as being insecure, even if you believe the companies maintaining the servers involved are reputable and apply good practice.
We should also keep things in perspective. How much of the mail you send has any information in it which is really sensitive? Of what real value is this information to someone else? How easily could someone get this information and is the cost of doing so less than the value obtained? Security should rarely be considered in terms of is it secure or insecure. The question should be is it secure enough for the purpose I am using it for. Is email secure enough for my Christmas greeting I send to my grandmother? Almost certainly. Is it secure enough for my bank to send my account access code or PIN? Definitely not. Are there ways to increase security of messages? Yes, but they all come with a convenience cost. For example, PGP/GPG and encryption of your message. They provide additional good security, but decrease the convenience of communicaitong by email. Now you have to create and manage encryption keys and your recipient needs to setup their client to use your public key to decrypt your message before they can read it. If the content is sensitive and valuable enough, this increased inconvenience may be worthwhile.A lot of the time, it isn't.
