Slashdot Mirror
E-Mail Clients That Support X.509 Digital IDs?
"I have already checked a previous Ask Slashdot on this, as the title would suggest being close, but it seems to be more about sending anonymous e-mail through a secure POP/SMTP connection for an ISP which is a tad different and a tad more complicated than my needs.
In my particular case, I have this Digital ID that confirms that any mail a recipient gets is actually sent from me. The way it works, every time I send mail, it pops up a dialog and asks for my password. After confirmation, it encrypts the contents and attaches a security certificate that the recipient can view to confirm authenticity. In this way, even someone on my machine can't send mail as me. The certificate allows me to encrypt mail also, so only people that have my specific key can read it. It has several other useful features as well. (Here's a quick FAQ link)
I have to do this because, at work, I deal with about 100 developers that live in an unnamed former Soviet bloc country, and are QUITE security concious. The Verisign DigitalID allows them to be sure that the mail they are getting comes from me. It's quite cool, and I would LOVE to have this capability in Linux. Unfortunately, there seem to be no solutions to this problem, at least none that are obvious."
Awesome list, dude.. Did you pull those out of your hat as you keyed in the post?
Personally, I use e-mail and email interchangeably, depending on the "tone" of the sentence. If I was a man-eating space alien, I'd spell human "hu-man."
Gnus has this ability. I haven't actually tried it, but there is a smime module that explicitly lists X.509. Not sure what version it started coming with but the latest version has it.
Netscape Messenger.
-- Cerebus
project on SourceForge to do just this - make it easy to integrate S/MIME and other mail encryption capabilities to MUAs.
Feel free to lend a hand.
--
--
Mod up a post Rob doesn't like and you'll never mod again
Just a quick bit I put together; don't blame me if it doesn't work right for you. :)
/usr/local/ssl, and assumes that you've got Pine setup already.
.ssl directory in your home directory, and chmod it to something safe. "mkdir ~/.ssl; chmod go-rwx ~/.ssl" might be useful.
/usr/local/bin, and chmod ugo+x it. The source for smime-sign.sh is later in this post.
/usr/local/bin and chmod ugo+x it. The source for smime-sign+enc.sh is later in this post.
.ssl directory in your home directory before you can send encrypted email to them.
/bin/sh may really be bash rather than bourne shell in SuSE. Syntax in the scripts may have to be updated for use with a real bourne shell.
.ssl/private.cert -recip .ssl/public.cert > temp.plaintext"
;)
This only works for UNIX/Linux, it assumes that you have OpenSSL installed in
Do these things (and do 'em the way I did 'em) and you'll end up with a Pine that can send S/MIME signed messages, and S/MIME signed+encrypted messages. As for decoding messages, for the moment, export them to a file, strip off the mail headers, and manually decrypt them with openssl. More directions on that later in the post.
- Fire up Netscape or Internet Explorer. My Mozilla nightly from 01/09/2001 couldn't handle this.
- Go to www.thawte.com and sign up for their FreeMail service. You'll end up with a valid, signed by a known CA X.509 certificate.
- When the process of creating your certificate with Thawte asks what kind of certificate you want, choose "Netscape".
- You'll go through a song and dance with Thawte, eventually, you'll have the option to import your X.509 certificate into Netscape. Do it.
- Once the X.509 cert is imported into Netscape, bring up the Security Info window, click into the box to look at "Your Certs", and export your FreeMail cert to a file.
- Use OpenSSL to get the cert out of the pkcs12 format that Netscape saved it in. If you saved the X.509 cert as "netscape.p12" something like.. "/usr/local/ssl/bin/openssl pkcs12 -i netscape.p12 -out temp.certs" would be a good command to try.
- Break the temp.certs file into four parts
* Private Key [save as private.cert]
* Thawte FreeMail Key [save as thawte.cert]
* Thawte Root CA Key [don't save, just toss it]
* Public Key (the one with your email addy) [save as public.cert]
In temp.certs you should see the Private Key first, then the Thawte FreeMail Key, then Thawte Root CA, and finally your Public Key.
- chmod *.cert to something safe. -r-------- might be good.
- Make a
- Su up to root.
- Create a shell script named smime-sign.sh in
- Create a shell script named smime-sign+enc.sh in
- Log out of root.
- Fire up Pine, go into Setup, then Configure.
- Find the "sending-filters" option.
- Create a sending filter that reads "/usr/local/bin/smime-sign+enc.sh _TMPFILE_ _RECIPIENTS_"
- Create another sending filter that reads "/usr/local/bin/smime-sign.sh _TMPFILE_"
- And done!
- Note, you *must* put the public keys of anyone you want to send email to into files in the
- Note, these scripts have only been tested on SuSE Linux 6.4, and I have nasty idea that
- Note, you can only send encrypted email to one person at a time using the smime-sign+enc.sh script. If anyone wants to fix that, feel free.
- Decrypting mail that was sent to you encrypted would use a command something like this (if you exported the email to temp.crypt): "openssl smime -decrypt -in temp.crypt -inkey
- For notes on verifying mail that was sent to you, try www.kfu.com/~nsayer/encryption/openssl.html and look near the bottom of the page.
Scripts:
smime-sign.sh
#!/bin/sh
user=`whoami`
tmpfile="$1"
certdir="/home/$user/.ssl"
sslbin="/usr/local/ssl/bin"
$sslbin/openssl smime -sign -inkey $certdir/private.cert -signer $certdir/public.cert -certfile $certdir/thawte.cert -in $tmpfile > $tempfile.signed
mv $tmpfile.signed $tmpfile
exit 0
--
smime-sign+enc.sh
#!/bin/sh
tmpfile="$1"
if [ ! $# = 2 ]; then
rm $tmpfile
exit 1
fi
user=`whoami`
certdir="/home/$user/.ssl"
sslbin="/usr/local/ssl/bin"
error=0
recipients=`echo $* | sed "s,$tmpfile,,g"`
recipentcerts=`for r in $recipients; do
cd $certdir
grep -l $r *
if [ $? = 1 ]; then
return 1
fi
done`
if [ $? = 1 ]; then
rm $tmpfile
exit 1
fi
$sslbin/openssl smime -sign -inkey $certdir/private.cert -signer $certdir/public.cert -certfile $certdir/thawte.cert -in $tmpfile | $sslbin/openssl smime -encrypt $certdir/$recipientcerts > $tmpfile.signed
mv $tmpfile.signed $tempfile
exit 0
Please consider all code to be firmly under the GPL v2 license. (www.gnu.org/copyleft/gpl.html)
Notes: I only gave this brief testing - there may be a few bugs, particularly in the error handling.
That's all folks!
You can email glorian@eudoramail.com with questions, compliments, praise, etc, but I don't promise replies.
Not correct AFAIK--any link in the chain may be compromised, calling into question the validity of any key below it. This is one of the many problems with PKI (in the specific sense that term is often used, not in the general sense), and is why I prefer PGP, which has the same problem (as any public-key structure must), but handles it better.
Saying that a MUA should send mail to a remote SMTP server is assigning a job to a program not designed to handle the job.
...?
Well, If you're a singular entity in a singular domain. I'm not. I have accounts in multiple domains. Each domain resides in an entirely separate sphere of influence. For profession reasons my email should originate from the appropriate domain. For privacy reasons no-one needs my personal email address.
It would be nice to not have to log in to each domain for email, but use a central client. Besides, if a client can log into one SMTP server, why not two or three or
Surely I'm not the only one with this problem.
satire, n: 1) witty language used to convey insults or scorn; 2) a form of humor lost on most slashdot moderators.
Already available in KMail
Ummm... have you actually tried this? Its possible with much fiddling with filters to get KMail to reply through the appropriate domain, but you cannot arbitrarily send through a specific domain. Neither does it support "POP before relay"
and no, multiple accounts are not the feature he's looking for, so he's in pace and your'e shooting high.
It seems that any client that can already connect to one server could surely connect to more than one. That doesn't sound like a very high aim to me.
satire, n: 1) witty language used to convey insults or scorn; 2) a form of humor lost on most slashdot moderators.
E-Mail Clients That Support X.509 Digital IDs
How about a client that simply supports multiple accounts and SMTP servers first?
Of all the clients I've been able to test, some allow you to receive mail from multiple accounts, but none support sending through these accounts. Its always pick one, and only one, SMTP server. What's up with that?
satire, n: 1) witty language used to convey insults or scorn; 2) a form of humor lost on most slashdot moderators.
Just have one organization-signing key.
..... to $N$ levels deep. You need this transitivity, but not necessarily to all 8 levels. We can use the UID field on a key to put an advisory informing PGP to cut the levels of transitivity.
All members have their trust flagged to trust all keys signed by the organization-signing key for their organization. They also get their own key signed by the organization key.
By some configuration of how PGP calculates trust, you can put in transitiveness to make organizations trust other organizations. (For example, all are automatically marked to trust any keys signed by keys signed by the 'master organization'-signing key.
True, PGP is not intended for this. One problem is that the key trust is transitive. I trust you who trusts someone elses key who trusts
(So, an organization's master key can be flagged to not spread trust too far. You can also have cross-organizational trusting, and finally, one key may be a member of more than one trust heirarchy. (For cross-organizational groups.)
see http://www.winecentric.com/
Works great.
I faced similar problem myslef and
find out that seems to be 2 words - PGP
users and X.509 users. Both have some
mechanism within but no way to communicate
securely with another world.
So, here is idea: somebody could establish
service, which will forward email messages,
signed with PGP re-signing it with X.509 and
vice versa.
Suppose PGP user A@a.com wants to send encrypted message to X.509 user B@b.com. In his address book
B is listed as B@forwarding.com and forwarding.com
public key as B public key. So he just send message, which is received at forwarding.com,
decrypted and re-encrypted with X.509 key of B.com
and forwarded to him.
The disadvantage of such scheme is that both parties should trust this forwarding service.
If you can convert the format to PKCS#12, you could use S/MIME mail in NS Communicator
'yields false when preceded by its quotation' yields false when preceded by its quotation.
It sounds like your goal is really to be able to send mail "from" any of your various accounts. That is, your recipients should see the mail as "coming from" user1@domain1.com or user2@domain2.com. Am I right?
Really, which SMTP server you use doesn't matter much here, unless you're dealing with savvy people who dig into the SMTP headers. There are several e-mail clients (I use pine) that support multiple profiles. I've got a profile (pine calls it a "role" setup for each of my e-mail addresses. When I compose a new message, I get to choose what role I will use. Pine is fairly intelligent: It recognizes when someone sends mail to a particular address and replys by default come from that address/role (I can always change it, of course)
So what SMTP server do I use? After all, most smtp servers are picky about who they will allow to use their services. Easy: I have to run an MTA for fetchmail to hand my POP'ed email to, so I use the same MTA (sendmail in my case) for sending. Yes, sendmail for one person could be considered overkill and there are simpler, lighter-weight MTA's out there. Find one you like.
In short, worry less about which SMTP server you're using and look for something that lets you define multiple sending addresses.Good luck!
--
>what's wrong with calling your coworker
;-)
12-hour timezone difference, for starters
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Amongst GUI clients:
Mulberry (from Cyrusoft: http://www.cyrusoft.com) has Win, Mac, Solaris, Linux clients. It's commercial but worth it.
Has preset identities, which can group an outbound mail "account" and a variety of headers, sigs, and signing/encryption keys. Can configure outbound mail in response to mail in a specific mail "folder" to default to a specific one of these identities.
Automated filter rules are in alpha and need some work, but are almost there.
S/MIME support is planned but not there.
PGP support is in there.
Supports IMAP (full online, offline, or disconnected: offline filing, mailbox creation, etc. work properly), POP and local mailboxes.
I just downloaded Mozilla 0.7 a few hours ago and setup my email with it. I haven't used the feature yet, but it claims to allow multiple outgoing SMTP servers.
--
MailOne
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
Hello, I had the same problem, because my company (a security consulting one) is almost based on Windows specialists and every single person on the company has a personal ID (Check http://www.thawte.com if you want one personal for FREE). I looked everywhere to see if I could find any console tools to do this (i really love console on linux). But at the moment I looked for, I just found that Netscape Navigator (4.7x in my case) worked with these IDs. And worked pretty well, on my personal experience. But now, looks like that the new PINE (console program) support it too. Take a look and choose the best one that fits for you (But for God's sake, just don't use the MS Outlook! :)).
gcc -o sig sig.c sig.c:4: #error NO SIG FOUND make: *** [sig] error 1
$HOME/bin/smime_verify:
clear
openssl smime -verify -CAfile my-bundle.crt 2>&1 >/dev/null
$HOME/.muttrc:
macro compose S |smime_sign
$HOME/bin/smime_sign would be something like:
Tovris has a product which would let you send X.509 messages from any mail client that supports SSL. Platform independant.
The product is called the Mithril Secure Server and it acts as a proxy which sits in front of a mail server performing X.509 encryption/decryption on incomming and outgoing mail. A lot of ISPs are installing this in order to upsell managed security.
SSL authentication for IMAP/POP/SMTP is required to maintain security from the proxy box to the desktop. This is a very elegant solution which is packaged as a network appliance. Pretty much plug and play for any standards based email servers.
Check it out: http://www.tovaris.com.
Email sales@tovaris.com for more information on pricing, etc.
Yeah, but if they've got system-level control (ie BackOrifice or root), then even biometrics won't help, as you can override the reporting functions....
With X.509 it is allways crucial to have the root keys installed. And the Verisign ones are in the programs mentioned above. This minimizes the effort for the uninitiated.
It should not be so difficult to includet the PSE from Mozilla in s/w like Balsa, if they offer a generic way to manipulate the network connection before it is made.
But I allways had the impression that most coders in the free software arena prefer PGP, thus never took the time to write the code to support S/MIME and SSL.
The neccesary backend libraries are there (here for instance), but the integration and the GUI needed to make it happen in end-user software where never done. The good thing about the mozilla PSE is the fact that it has some concept of doing the GUI itself, only the integration has still to be done. If I only had more hours to the day B-)
Beside being more supported for email (ie: usable with more user agents on more platforms) I think that PGP should not have been a bad move for this particular case. Since there seems to be a limited number of identified recipients you can always generate your key, send the public key to the recipient by email and check the finger print by telephone.
S/MIME is more suitable to do secure email with the world since it does not require you to check the public keys (certificates) you receive with their owners. That's right but it does not really solve the problem, it only moves it somewhere else: instead of asking yourself I'm I sure that the key belong to whom it claims you'll have to ask can I trust the certification authority.
Look at the certification authorities in Netscape or Mozilla, there are dozens of them. Well I think I can trust Verisign, Thawte (ok it's the same) but can I trust the other ones? Can I be sure that they properly check the identity before issuing certificates? Sincerly I cannot tell.
In my opinion the biggest advantage of x509 over PGP is the possibility to use your personnal certificate not only to sign or crypt email but also to authenticate yourself on access controled web sites with the same key.
Check out Bruce Schneier's Crypto-Gram of a few months back for examples of how faith in biometrics is misplaced faith, at best.
PGP has a much simpler format and a default trust model which is much more secure. Unfortunately, the default PGP trust model generally requires a user to manually set up a trust relationship with every other individual. As a result the average person finds S/MIME much easier to use and that's what companies deploy. PGP seems to be relegated to techno-geeks, the paranoid, and people who really need strong security and got good advice.
Because PGP is not what the people he is communicating with have. It would appear that they want some of the features that Verisign provides as a part of this service (in particular the level 2 serivce looks interesting) I could easily see how using this to sign and PGP to encrypt would be a very usefull combo. In particular if it made your PHB fell better if someone was offering him money if it did not work.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Hate to say it, but that's not true. If you've got something like Back Orifice (or a keystroke sniffer, or even a shoulder surfer) on your machine, then the jig is up. You need to use something which incorporates biometrics in order to be really sure your communications are secure and identifiable. Heck, even a SecuurID is better than a plain password dialog.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
And get your terminology right: It attaches a digital signature( not a "security certificate") then it encrypts your message. only people that have my private ( not "specific" ) key can read it. Where did you get those term from anyway?
Bzzt! Sorry, no prize, but thanks for playing.
PKCS 7 does, indeed, attach a copy of the certificate to the message. It also attaches a copy of the MD5 hash of the body of the message, encrypted with the sender's private key. The receiver can then recompute the hash of the message he or she received and compare it to the value he or she obtains by decrypting the encrypted hash paylod with the sender's public key. They must match, or the message has been tampered with.
Finally - and here's why people use X.509 certs, - the MUA can resolve the certificate chain corresponding to the cert in the message. If each certificate in the chain was issued by its putative issuer, and if the root of the chain is trusted, then either the sender's key has been compromised, or the message is both authentic and valid.
PKCS 7 can, but is not required to, encrypt the message body itself. That is a somewhat more complicated process. In order to encrypt a message, it needs the public key of the known recipient. It then generates a cryptographically secure random number, and encrypts it with the receipient's public key. It then use that random number to conceal the contents of the message (using a standard symmetric algorithm). That body is then signed as per the unencrypted form, and the resulting envelope is sent.
It is left as an exercise to the reader to figure out why (a) the message is securely encrypted, (b) the resulting message is repudiable, (c) this all works without either party needing to know the other party's private key and (d) why the keys in each leaf (non-issuer) certificate can be, and are, thrown away after the cert is generated, so that the only copy left in existence is in the cert itself.
S/MIME is the way to do email with X509 certificates, and Netscape Communicator is one mail app which uses S/MIME.
You can manipulate S/MIME messages (encrypt, decrypt, sign, verify) using OpenSSL at the command line. I'd love to see mutt hacked to front-end OpenSSL smime the way it can with PGP.
There are those who would argue that X509 is evil, thanks to its strict hierarchical structure (where Verisign's root CA is the big daddy of everything), and that only PGP gives the power to the people -- but from a pragmatic point of view, X509 is everywhere thanks to SSL etc. and if you want to be able to do secure email with the world, S/MIME is the way to go. PGP is attempting to converge with the S/MIME standard in any case.
--
x.509 is typically used with a message format called S/MIME. Recent versions of Netscape Communicator have a facility for sending, receiving, encrypting, and decrypting S/MIME messages using x.509 certificates.
If you use a flexible mail program such as mutt, you can pipe your message through the openssl smime command. By canning openssl smime with the options -encrypt, -decrypt, -sign, and -verify, you can perform all the same operations you could with a client that supported S/MIME natively.