Securing email- a particular case
Message # 1
Date: Thu, 15 Jun 2006
From: Sarad AV
To: practicalsecurity at hbarel.com
Subject: [PracticalSecurity] Securing email- a particular case
Hello,
I am on a monitored local network connected to the internet. I would like to encrypt all outgoing mails from my computer to the email service providers mail server. If the recepient of the mail doesnot have a key or is ignorant about crypto, i don't mind my mail being decrypted at the mail server and then being send to the recepient as plain text.
Similarly, if I am the recepient of the mail and even if the sender doesnot have a key or is ignorant of crytpo, I would like the mail server to encrypt the message and send it to me so that I can decrypt it locally on my computer.
The only adversery, I am really concerned about is on my monitored lan.
Are there any email service providers which does this for me, free or paid?
I see that hushmail's free service provides secure email service but it still sends the email in plain text if
-the recepient doesnot have a hushmail account.
-If the message is send from a non-hush account, I get to receive the message in plaintext.
which can be both sniffed on the local network.
What are my options to beat the local monitored network? I am assuimg that all my friends are ignorant of crypto and that I can't go about asking everyone to use PGP or hushmail.
Thankyou,
Sarad A.V
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Message # 2
Date: Fri, 16 Jun 2006
From: mikeiscool
To: "Sarad AV"
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
On 6/16/06, Sarad AV
Hello,Seems like you just need a a webmail account that uses SSL throughout the entire connection; not just the login phase. Does hushmail do this?
I am on a monitored local network connected to the
internet. I would like to encrypt all outgoing mails
from my computer to the email service providers mail
server. If the recepient of the mail doesnot have a
key or is ignorant about crypto, i don't mind my mail
being decrypted at the mail server and then being send
to the recepient as plain text.
Similarly, if I am the recepient of the mail and
even if the sender doesnot have a key or is ignorant
(snip)
I'm pretty sure the html interface that comes with exchange does.
-- mic
Message # 3
Date: Fri, 16 Jun 2006
To: Sarad AV
From: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
Hello Sarad,
At 15/06/06 18:41, Sarad AV wrote:
Hello,You have at least two options I see:
I am on a monitored local network connected to the
internet. I would like to encrypt all outgoing mails
from my computer to the email service providers mail
server. If the recepient of the mail doesnot have a
key or is ignorant about crypto, i don't mind my mail
being decrypted at the mail server and then being send
to the recepient as plain text.
Similarly, if I am the recepient of the mail and
even if the sender doesnot have a key or is ignorant
(snip)
1. To conduct all your traffic with your mail server over a VPN of some sort, or tunnel it over SSH. This may be a problem if you are not the owner of the server - not all service providers support this.
2. Do all your mail over POP3-TLS for receiving and over SMTP-TLS for sending. This will protect all the traffic, including, most importantly, the password that are sent. Of course, it will not protect the mail back and from the mail server, but this is out of your threat model, as you say.
TLS/SSL for POP3 and SMTP is not provided by all service providers, but by many! Such support usually appears on their website (make sure you distinguish this from SSL/TLS from browsing).
Of course, your e-mail client needs to support this too, but all major ones (Outlook, Eudora, The Bat!, Thunderbird, etc.) do.
Hagai.
Message # 4
Date: Fri, 16 Jun 2006
From: Ian G
To: Sarad AV
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
Sarad AV wrote:
Hello,The ISP might offer a TLS mail capability - but it is unreliably hard to set up, mostly because it follows the brain dead "must be totally secure" mode that it inherited from some cult or other (that is, you either get everything or nothing, so you get nothing.)
I am on a monitored local network connected to the
internet. I would like to encrypt all outgoing mails
from my computer to the email service providers mail
server. If the recepient of the mail doesnot have a
key or is ignorant about crypto, i don't mind my mail
being decrypted at the mail server and then being send
to the recepient as plain text.
Similarly, if I am the recepient of the mail and
even if the sender doesnot have a key or is ignorant
(snip)
The only adversery, I am really concerned about isI'll tell you what I do, FWIW: I set up an SSH tunnel to an outside server, and connect my local mail to talk to that. The tunnel passes the connections out to the outside world, and they pop up on the outside server. From there on it is open and clear.
on my monitored lan.
A couple of caveats:
1. This is only useful if you know how to use SSH and like to muck around with that sort of thing.
2. It requires your mail ISP to take / send mail to the outside server. This can be a nuisance, for example, my mail ISP won't take tunnelling to itself, only other machines.
3. SSH connections (all connections, really) drop out and cause problems, so I have had to layer a script over the top that adds reliability to the tunnel (guffaw!).
4. I only ever got it working for send-out mode, haven't tried with receive mode.
Are there any email service providers which does thisPlenty of paid ones will offer the TLS services.
for me, free or paid?
I see that hushmail's free service provides secureIf the recipient is PGP capable, you should also be able to have hushmail send it on in PGP form.
email service but it still sends the email in plain
text if
-the recepient doesnot have a hushmail account.
-If the message is send from a non-hush account, I
get to receive the message in plaintext.
What are my options to beat the local monitoredA very practical problem - that is the reality, you cannot solve this problem easily.
network? I am assuimg that all my friends are ignorant
of crypto and that I can't go about asking everyone to
use PGP or hushmail.
iang
Message # 5
Date: Fri, 16 Jun 2006
From: "Roy M. Silvernail"
To: michaelslists at gmail.com
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
mikeiscool wrote:
On 6/16/06, Sarad AVwrote:
The only adversery, I am really concerned about is
on my monitored lan.
Seems like you just need a a webmail account that uses SSL throughoutUsing https://gmail.google.com/gmail will keep a Gmail session entirely under SSL. That might fit the requirement.
the entire connection; not just the login phase. Does hushmail do
this?
I'm pretty sure the html interface that comes with exchange does.
--
Roy M. Silvernail is roy at rant-central.com, and you're not "It's just this little chromium switch, here." - TFT CRM114->procmail->/dev/null->bliss
http://www.rant-central.com
Message # 6
Date: Fri, 16 Jun 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
Hi Hagai,
I'm taking it as a challenge to convince you of our theories on opportunistic cryptography. It is good for forming thoughts in one rant or another :)
Hagai Bar-El wrote:
Hi,OK, so I just tried to set that up -- and it may have worked. I timed it, it took 8 minutes of poking around in thunderbird to find the right boxes, turn them on, then send some test messages to make sure I hadn't broken anything.
At 16/06/06 12:28, Ian G wrote:
The ISP might offer a TLS mail capability - butYou are right in that the setup is complex due to the "all or nothing
it is unreliably hard to set up, mostly because
it follows the brain dead "must be totally secure"
mode that it inherited from some cult or other
(that is, you either get everything or nothing,
so you get nothing.)
approach"! However, Sarad should not care, because the complexity was
borne by the service provider so he can put the "SSL/TLS POP3/SMTP!"
slogan on his website. The service provider had to get certificates that
are recognized, install them, and have this working. All the user has to
do is switch on the feature in the mail client, and it works either
right out of the box, or very soon after.
So here are the problems observed, in my usual "treat myself as a dumb user" mode:
1. I didn't know it worked, so I've lost years :) (It was probably at least 2 years ago that I tried it and it failed and had to be turned off.)
2. Why wasn't it enabled by default? Why did I have to spend 8 minutes?
3. Does it work? Is it doing anything? I can't tell. I have no way of knowing if the system is turned ON or OFF. There isn't a clue available, so I now have to scan the network and see if the traffic going out is encrypted or not.
4. Can I rely on it? Not really - because it could turn itself off for any number of reasons (re-install, loss of account, reset according to some other button).
5. Can I honestly suggest that this will be useful for people? Yes, but I can't say it is worth paying any money for, it's way too brittle.
Consider the original poster's threat model - if I as evil sysadmin wanted to scan the mail, I'd just wait until coffee break time and turn off the buttons in the account interface.
Obviously some will say that is all grumbling.
But we compare and contrast this to Skype and SSH.
With those systems, there is only one mode. They are well designed -- they meet my "one mode" criteria -- because they know that the small barriers above will result in probably only 5-10% of the population using the system.
If the e-mail client knows the signer of the certificate that theA fall back to "SSH-type of trust" at this point would raise my trust in the system by an order of magnitude - possibly two :)
service provider has installed, it runs well immediately after you
switch the feature on. If not, you either get a warning message
(Outlook) or get a fallback to the SSH-type of trust in which you need
to mark the certificate as okay as a one-time act, from which point it
is cached by the client and you are never warned again (Eudora). I am
not sure how Thunderbird treats it, but I assume it is at least as
convenient.
I had only one case of an ISP who installed his certificate in a wayAh, ok. Systems that have only one mode work through that too. See grumbles about how hard it is to firewall Skype off ;)
that required further efforts, and I simply did not work with them and
used the 30-day money-back...
One last thing that Sarad does need to check out is the outgoing port.
If he's using a highly restricted network, the relevant ports (e.g.
POP3-TLS, that is, port 995) may be closed for outgoing connections.
iang
Message # 7
Date: Fri, 16 Jun 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Securing email- a particular case
Cc: practicalsecurity at hbarel.com
Hi,
At 16/06/06 12:28, Ian G wrote:
The ISP might offer a TLS mail capability - butYou are right in that the setup is complex due to the "all or nothing approach"! However, Sarad should not care, because the complexity was borne by the service provider so he can put the "SSL/TLS POP3/SMTP!" slogan on his website. The service provider had to get certificates that are recognized, install them, and have this working. All the user has to do is switch on the feature in the mail client, and it works either right out of the box, or very soon after.
it is unreliably hard to set up, mostly because
it follows the brain dead "must be totally secure"
mode that it inherited from some cult or other
(that is, you either get everything or nothing,
so you get nothing.)
If the e-mail client knows the signer of the certificate that the service provider has installed, it runs well immediately after you switch the feature on. If not, you either get a warning message (Outlook) or get a fallback to the SSH-type of trust in which you need to mark the certificate as okay as a one-time act, from which point it is cached by the client and you are never warned again (Eudora). I am not sure how Thunderbird treats it, but I assume it is at least as convenient.
I had only one case of an ISP who installed his certificate in a way that required further efforts, and I simply did not work with them and used the 30-day money-back...
One last thing that Sarad does need to check out is the outgoing port. If he's using a highly restricted network, the relevant ports (e.g. POP3-TLS, that is, port 995) may be closed for outgoing connections.
Hagai.
Message # 8
Date: Fri, 16 Jun 2006
From: Sarad AV
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
Hi,
--- "Roy M. Silvernail"
Using https://gmail.google.com/gmail will keep aThankyou Roy, that solves my problem. The entire gmail session does stay under ssl. Since I also use Orkut wherein I use the gmail password, I tried login using https://www.orkut.com/
Gmail session entirely
under SSL. That might fit the requirement.
and it does work. However once I login everything is send or received in plaintext but thats okay as long as my gmail password is safe.
--- "mikeiscool"
Seems like you just need a a webmail account that uses >SSL throughoutNot sure about hushmail, have to check again.
the entire connection; not just the login phase. Does
hushmail do
this?
--- "Hagai Bar-El"
TLS/SSL for POP3 and SMTP is not provided by allGmail does the trick. Thankyou.
service providers,
but by many! Such support usually appears on their
website (make sure
you distinguish this from SSL/TLS from browsing).
Of course, your e-mail client needs to support this
too, but all
major ones (Outlook, Eudora, The Bat!, Thunderbird,
etc.) do.
One last thing that Sarad does need to check out ishttps works(i think port 443 outgoing). It shouldn't be difficult to get the admin to allow it since closing it is questionable.
the outgoing
port.
If he's using a highly restricted network, the
relevant ports (e.g.
POP3-TLS, that is, port 995) may be closed for
outgoing connections.
Thankyou,
Sarad.
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Message # 9
Date: Sat, 17 Jun 2006
From: "James A. Donald"
To: michaelslists at gmail.com
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
--
mikeiscool wrote:
Seems like you just need a a webmail account that uses > SSL throughout the entire connection; not just the > login phase. Does hushmail do this?Hushmail encrypts everything, even if the other party does not.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
bzJ514dVjY7PtxRR8RxsVFxMGs8h66IDCRkcZrjT
4gJtC4IyPJT8mSNDAzepEfBjQd/xrIqRKxQrU+wJv
Message # 10
Date: Fri, 16 Jun 2006
From: Sarad AV
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Securing email- a particular case
Hello Hagai,
If your e-mails are passed in the clear (whenOrkut allows a gmail user to access the Orkut community(its a social community network). gmail inbox is inaccesible from Orkut. Whatever appears in plaintext is the Orkut community's information. The Orkut SSL login is done using the gmail username and password.
logging through Orkut)
then I am not sure I can see the blessing in keeping
the password
safe. It is better than a clear password, but I
consider this as a
marginal benefit.
However, more generally speaking, I wonder what yourJust need to beat the sniffer on the LAN.
threat model is
if you agree to use Gmail... :) Gmail, BTW, allows,
IIRC, logging in
using SSL over POP3. However again, I consider using
Gmail as a
security compromise for itself.
Thankyou,
Sarad.
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Message # 11
Date: Sat, 17 Jun 2006
From: "James A. Donald"
To: practicalsecurity at hbarel.com, public-usable-authentication at w3.org
Subject: [PracticalSecurity] Why SPF and DK are not being used
--
Why SPF and DK are not being used:
Obviously, domains have no incentive to use SPF and/or DK unless email recipients filter on SPF and DK
But users do not.
Largely because they cannot. There are no filter tools that make good use of SPF and DK information. There are filter tools, but they are research demonstrations, rather than actually useful in reducing the spam in my inbox.
What the filter should do, is as part of Bayesian filtering, observe that some messages get marked as spam, and others as ham, and conclude that if some mail that provably arrives from certain domains is ham, all mail that provably arrives from those domains is probably ham, generating a list of known good domains which it then uses to guess which emails are ham. It should also observe what domains usually provide evidence that email came from the domain it appeared to come from, and conclude that email without such evidence, purportedly coming from a domain that usually provides such evidence, is probably forged, therefore probably spam. SPF and DK information needs to be integrated with all other available information for filtering mail.
The widespread deployment of such filters would give mail server administrators reason to support SPF and DK.
They would DK their outgoing mail in order to get their domain on the known good list. At present they have no such incentive, and so are not supporting SPF or DK.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
CAbCqOSgym8Up02XNnb1alzFW4VBYsBpa/7xjkfS
4pjb+C/KVowMqXdI49IgPIpZ4kB3ulWsslp3qz+jm
Message # 12
Date: Sat, 17 Jun 2006
To: Sarad AV
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Securing email- a particular case
Cc: practicalsecurity at hbarel.com
Hi,
At 16/06/06 18:54, Sarad AV wrote:
--- "Roy M. Silvernail"If your e-mails are passed in the clear (when logging through Orkut) then I am not sure I can see the blessing in keeping the password safe. It is better than a clear password, but I consider this as a marginal benefit.wrote:
Using https://gmail.google.com/gmail will keep aThankyou Roy, that solves my problem. The entire gmail
Gmail session entirely
under SSL. That might fit the requirement.
session does stay under ssl. Since I also use Orkut
wherein I use the gmail password, I tried login using
https://www.orkut.com/
and it does work. However once I login everything is
send or received in plaintext but thats okay as long
as my gmail password is safe.
However, more generally speaking, I wonder what your threat model is if you agree to use Gmail... :) Gmail, BTW, allows, IIRC, logging in using SSL over POP3. However again, I consider using Gmail as a security compromise for itself.
Port 443 (SSL for HTTPS) is commonly open. You still need to check about POP3 and SMTP over TLS, which have different port numbers. If the admin is your friend then there is probably no problem.One last thing that Sarad does need to check out ishttps works(i think port 443 outgoing). It shouldn't
the outgoing
port.
If he's using a highly restricted network, the
relevant ports (e.g.
POP3-TLS, that is, port 995) may be closed for
outgoing connections.
be difficult to get the admin to allow it since
closing it is questionable.
Hagai.
Message # 13
Date: Sat, 17 Jun 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Securing email- a particular case
Cc: practicalsecurity at hbarel.com
Hi,
At 16/06/06 14:43, Ian G wrote:
I'm taking it as a challenge to convince you ofI am not sure I need to be convinced. I already agree with most of what you claim; usually.
our theories on opportunistic cryptography. It
is good for forming thoughts in one rant or another :)
Enabling Thunderbird for a new account already takes a few minutes.You are right in that the setup is complex due to the "all or nothingOK, so I just tried to set that up -- and it may
approach"! However, Sarad should not care, because the complexity was
borne by the service provider so he can put the "SSL/TLS POP3/SMTP!"
slogan on his website. The service provider had to get certificates that
are recognized, install them, and have this working. All the user has to
do is switch on the feature in the mail client, and it works either
right out of the box, or very soon after.
have worked. I timed it, it took 8 minutes of
poking around in thunderbird to find the right
boxes, turn them on, then send some test messages
to make sure I hadn't broken anything.
If you did all this TLS-enabling stuff back then, when setting the account, the marginal effort for TLS would be close to nothing (especially since all the testing would have to be done anyway).
So here are the problems observed, in my usualOkay, we all agree security needs some more user education...
"treat myself as a dumb user" mode:
1. I didn't know it worked, so I've lost years :)
(It was probably at least 2 years ago that I tried
it and it failed and had to be turned off.)
2. Why wasn't it enabled by default? Why didBecause, as you pointed out, setting this up on the server side is a semi-nightmare. So, most providers don't, and only a few ones do it to get a competitive edge on others, at least when selling to privacy-savvy people or to businesses.
I have to spend 8 minutes?
3. Does it work? Is it doing anything? I can'tThis is an implementation issue that has nothing to do with the method. I can tell you that in Eudora Pro the mail checking progress bars appear with a padlock icon next to them to indicate that a security association has been made.
tell. I have no way of knowing if the system is
turned ON or OFF. There isn't a clue available,
so I now have to scan the network and see if the
traffic going out is encrypted or not.
4. Can I rely on it? Not really - because itThis relates to why it is not on by default, but the this point is somewhat weakened when you have a visible indication for when it's working. I agree that having this security feature completely transparent (visibly), especially given it's optional and may fail, is a product design mistake.
could turn itself off for any number of reasons
(re-install, loss of account, reset according to
some other button).
5. Can I honestly suggest that this will beI do not agree with this. I happen to see this feature as solving many threat models I've seen, even of businesses, for mail that is not confidential (where I would use PGP). Note, for example, that it gives complete protection for intra-domain correspondence, which is for itself something people go and install a full-blown VPN for. In many other cases, such as in the case of the original poster, most of the threat comes from the local proximity, so if you protect the channel between you and the server, and the server is somewhere far, you already make your sniffers have to either travel or reach your correspondent's system. It also solves traffic-analysis threats that are in many cases of an even bigger concern, and are not mitigated by PGP or alike.
useful for people? Yes, but I can't say it is
worth paying any money for, it's way too brittle.
Consider the original poster's threat model - if
I as evil sysadmin wanted to scan the mail, I'd
just wait until coffee break time and turn off the
buttons in the account interface.
Regarding what you wrote about the sys-admin scenario - First of all, you stick to the bad design of a client not having visible indication for security - this seems as a Thunderbird illness that is likely to be fixed eventually. Second, it could be solved if you blocked the plain POP3 port on the server. If you do this and for some reason security is disabled, nothing will work and no password will be sent in the clear. However, more generally speaking, if the sys-admin, or anyone, could gain physical access to the machine, then it's a game over, regardless of the type of encryption used.
But we compare and contrast this to Skype and SSH.I agree. I appreciate POP3/SMTP-TLS because it's a "this or nothing" in terms of security that is not requiring anything from the correspondent. If I were to design the system now, an SSH model makes more sense, sure.
With those systems, there is only one mode. They
are well designed -- they meet my "one mode" criteria
-- because they know that the small barriers above
will result in probably only 5-10% of the population
using the system.
Actually, it shouldn't raise your trust because it "falls-back" to this mode only if the CA is not recognized. If you want to really raise your trust in this system you should remove all CA root public keys it recognizes out of the box, so it does not make its own decisions for you.If the e-mail client knows the signer of the certificate that theA fall back to "SSH-type of trust" at this point
service provider has installed, it runs well immediately after you
switch the feature on. If not, you either get a warning message
(Outlook) or get a fallback to the SSH-type of trust in which you need
to mark the certificate as okay as a one-time act, from which point it
is cached by the client and you are never warned again (Eudora). I am
not sure how Thunderbird treats it, but I assume it is at least as
convenient.
would raise my trust in the system by an order of
magnitude - possibly two :)
I agree that systems with only secure more bypass this problem...One last thing that Sarad does need to check out is the outgoing port.Ah, ok. Systems that have only one mode work
If he's using a highly restricted network, the relevant ports (e.g.
POP3-TLS, that is, port 995) may be closed for outgoing connections.
through that too. See grumbles about how hard
it is to firewall Skype off ;)
The problem with blocking Skype is not that it's always secure but that it doesn't follow the typical client-server port model but is actually built with firewall traversal in mind... If Skype used certain constant port/s for outgoing and incoming connections and did not allow redirection of traffic through arbitrary ports (such as 80), it could be blocked, while also retaining the same level of security.
Hagai.