[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Funnily enough I'm working on two project related to this at this very moment......
Email encryption is very complex in terms of acronyms and such, but conceptually it is quite simple once you see past the acronyms.
First we have "signing" or encryption by a personal key. Which proves the email is written by someone, hasn't been altered en-route, and optionally encrypts it.
PGP can be implemented using GNUPG (free software!), you don't have to use proprietary PGP software (although this is probably a good option if you must use the most popular (and probably least secure) email client. Trust is a distributed - keysigning model (you can use GNUPG to implement other trust models if you like, as most of them are a logical subset of a random sprawling network of trust ;-).
SMIME uses a hierarchical model, where you buy trust from a level above. ~ Often certificates carry some sort of insurance, so if you lose money based on trusting one of these certificates the issuer may reimburse your loss (hmm, I'll believe it when it happens).
The main complication is many Microsoft email clients don't correctly handle PGP-Mime messages, so most people using PGP type encryption do "inline" encryption. Lack of this "inline" option is a good reason not to use Evolution (or Outlook family email clients - if you need another reason).
SMTP Auth being the most common, where to inject email you use a username and password (or other authentication credentials). Allows you to inject email from anywhere rather than just from the ISPs own network.
Obviously as soon as "username and password" appeared people wanted to protect this part of the transaction to avoid spammers stealing the username and password as much as to prevent eavesdropping on email.
Similarly getting email from the email server back to the client needs protection.
POP3 is most common, IMAP is also common way of getting email. Both use username and password (or other credentials - less commonly).
Then we have email to email server transactions - generally here the email is sent in the clear (except for any PGP-Mime or SMime encryption). But there are options to encrypt.
By tunnelling the connection in an encrpyted tunnel (using SSL) we get "POP3 over SSL" (POP3S) and "IMAP over SSL" (IMAPS) and even "SMTP over SSL" (I can never remember if this is SSMTP or SMTPS and I'm not sure they are used consistently by everyone else anyway) for submission of emails.
This can be done easily with STUNNEL if your email/pop3/imap server of choice doesn't support it. It needs at least a server side certificate for the clients to check. This certificate doesn't need to be "signed" (i.e. you can make your own) as the worst that will happen is a box will appear saying "does this certificate look right to you"? And someone will be there to mindlessly click "yes" without thinking <doh doh doh>.
To get between SMTP servers with encryption we need some sort of trust model because there is no end user present to make the security decision for us if the trust model falls down. Also we need backward compatibility with clients that don't do such encryption. The only method I've aware of in widespread(?) use is SMTP-TLS (TLS - Transport layer security - buzz word for encryption within the session rather than the whole session). The trust model is through certificates similar to those used for websites, or SMIME, and the trust model is hierachical AFAIK (I don't do this yet - I think Theo does if he is around).
In SMTP-TLS the servers basically say "EHLO" and the reply includes a "250" message saying 'I can do TLS' (okay I forgot the actual string) amongst the other features offered. They then undergo a conversation to sort out how to encrypt email between them and if both sides are happy to do it. The servers should then remember if the far end can do this so it gets suspicious if next time there is no TLS available (i.e. possible man in the middle attack in progress!! Or more likely new clueless email admin appointed).
Email submission can be done using SMTP-TLS. This is potentially quite neat as it can avoid the need for usernames and passwords - having the certificate (and unlocking it if necessary) is sufficent to sign, encrypt, and authorise yourself to send with your email server, before sending it over an encrypted tunnel. This is great for corporates where you can stick the certificate in before issuing the laptop to the wandering road warrior, but ISPs have avoided it because certificate management is scarey to end users.
Similarly where I said "username and password" you can usually chose a variety of password schemes, some of which encrypt the password in transit, some of which just prove that the client knows his own password without sending any meaningful information about it over the connection.
SSH is a different way of doing encrypted tunnels and you can use SSH to encrypt POP3 or IMAP or SMTP outbound if you have shell access to the remote server. Usually SSH just encrypts a terminal session, but it is the swiss army knife of encryption, and probably the single reason that GNU/Linux is so lacking in other VPN technologies (because with a simple script you can make SSH do it).
I've long had a plan to do a fully encrypted email service for road warrior style laptop users, providing "SMTP Auth over SSL" for email submission, "POP3 or IMAP) over SSL" for collecting, and Webmail over HTTPS for wehn your not on your own laptop. Possibly using TLS for server to server traffic where supported. The idea being one username and password gets you your email encrypted as well as can be done.
Of course these days more and more ISPs are offering these anyway - and it can all be done with "free software", I'm looking to use Postfix-tls/dovecot/apache to do this.
-----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCZ+CoGFXfHI9FVgYRAtu9AKCI+JaQsaI4BEPy7e1UNQReOyvwUgCfQuqn RBK9h1HP4QAYpEiHhyB18Ck= =GmQL -----END PGP SIGNATURE-----
-- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html