Pontus Ullgren wrote:
> Hello Wouter,
> I've been thinking alot about a plugin such as this.
> Using gnupg to verify/decrypt and sign/encrypt messages.
> The problem always comes down to the fact that the webserver user (apache?)
> must be able to read the privatekey file. Either directly or by using
> somekind of suid binary. Any way in the end (even if we trust all other
> users with access to put up webpages on the webserver) if the webserver is
> compromised the cracker can easly read and copy the privatekeys.
> I don't know if a passphrase is enough to protect the privatekeys from
> beeing used by a third party (anyone?).
> Many moons from now Wouter Teepe spoked these words:
> > Hi All,
> > I've written a new plugin to squirrelmail!
> > It is a handler of incoming multipart/signed s/mime messages.
> > It shows some extra information when a signed message arrives, such as
> > whether the message and the signer could be succesfully verified.
To look at it prom a positive side: for verification, you don't need the
private keys, so there is no obstacle for writing a plugin that can do
gnuPG/pgp verification. Actually, it will probably look a lot like the
s/mime plugin, with some openssl commands replaced by gnuPG commands,
and some other (minor) differences.
If you're familiar with gnuPG/pgp, (eg. use it), maybe just send me a
gnuPG/pgp signed message with some comments you see fit on the subject,
and I'll download gnuPG and play around. Extending to gnuPG/pgp
verification shouldn't be too hard, I think.
For the other side (signing) there have been some threads on this
subject long time ago (I found 2 or three small treads in the archives),
all being negative on this subject. I am (not yet) pessimistic on the
However, and I currenly agree to that, said a lot is that passphrases
are not enough to protect the keys. It would need very good passphrases,
because otherwise an advanced dictionary would do the trick of stealing
(at least of some of your users, which is way too much) private keys.
The problem (I think) boils down to this: signing gives very high
security, but sending signed messages via webmail means low security
access to a high security tool.
Formulated in this way, the solution is as easy as it can be: make the
acces to the webmail high security. That means: you only gain privillege
of signing your emails, when you can show the website a certificate that
you are who you claim to be. (Thus a lot tighter than an
And, given the need to show a certificate to the webmail server, why
don't use this certificate to sign the messages? Then there is no need
at all to store private keys at the serverside, except maybe for during
sessions. So the serverside still sees the keys, but only for very short
times. You would need a very dedicated trojan to collect private keys
that are used in this way, I think.
For s/mime, the trick could be integrated to loggin in to SM, because
https allows logging in using certificates that are *very* similar to
the certificates used for signing s/mime messages. This would require
some hooking into the webserver (eg Apache).
However, "just" uploading the private key on the compose page could also
do the trick. Of course: you certainly want https as a transport
mechanism for this, but that can be done, right?
This approach certainly needs some research and second thoughts (anybody
It has two major drawbacks:
1. Configuration gets more complicated, because SM needs to cooperate
with special SSL functions of the webserver. And probably every
webserver works a bit different...
2. To sign a message when you are from home, you need to have your
private key with you.
Question maybe is whether the second drawback is really a drawback or a
direct consequense of the idea of private keys. When the police ask me
to identify myself, I have to have my ID with me, don't I? Is there a
real difference? (again: anyone out there?)