[dovecot] Some experiences
Heyas ...
I'm trying to use dovecot to set up a 'closed server' (actually, mixed) sort of environment, for a box to be deployed co-located. I wanted to talk about some of that, and see if some of my experience qualifies as 'bug'.
Note that I'm notoriously verbose, so if that bothers you, read no further ....
Since it's a more-or-less closed server, I didn't want to use pam (well, I wouldn't mind, for users with shell accounts, but I can't see a way to mix pam and passwd-file ... is there a way to do that?).
It turns out that digest-md5 support for clients is, well, not very widespread. I expect this box to be used by various windoze clients, eventually, and while I'm willing to lay down the law a little, I can't find enough digest-md5 support to lay down that law. So, regretfully, I abandoned that plan. This kinda bothers me, since I think TLS/STARTTLS is absolutely the *wrong* solution for mailbox access (or for anything that deals with a store-and-forward transport).
I therefore tried md5 passwords in a passwd-file, with STARTTLS enabled. Didn't work. I turned off SSL, and reenabled plain-text, and watched the login go by. Very sniffable, of course. But correct username and password ... failed. There are instructions for creating digest-md5 style secrets in auth.txt, but none for md5 passwords; I used openssl passwd -1 [password] (and cut and paste). It seems odd to me that this didn't work; does that command use a different algorithm than dovecot?
Falling back ... since it *shouldn't* matter if the passwords are weak, as long as they're inside TLS (along with the entire rest of the transaction, ugh), I used mkpasswd to generate a standard unix passwd (and cut and paste). This worked. It worked with TLS, and it worked without (as long as I remembered to allow sniffable logins).
One more oddity: I originally had a realm in the passwd-file, which also established the mail location and 'home' directory (most of the users can't actually log in and don't have accounts in /etc/passwd, so it's not a real home directory). There was an odd message in syslog, approximately like so (where 'user' represents the username, and 'domain.realm' represents both my domain name and the realm in the passwd-file):
imap(user:@omain.realm): Failed to create storage with data: domain.realm
Note the missing first letter after user:@ And I don't know what it was trying to do; the maildirs already exist. /etc/dovecot.conf sets the default mail location to /home/users/%n/Maildir (non-shell users are all inside /home/users; shell users have mail there, with symlinks to ~/Maildir); the passwd-file establishes the location of the INBOX pretty definitively, I would think. The solution was to remove the realm (which isn't useful except for digest md5, anway, right?).
Hey, it's working! Wahoo! *laugh* Anyway, if someone can offer suggestions on what's up with the pieces that *aren't* working, I'd be interested to know. It might give me a greater range of options.
Amy!
Amelia A. Lewis amyzing {at} talsever.com The less I seek my source for some definitive, the closer I am to fine. -- Indigo Girls
Amelia A.Lewis wrote:
Heyas ...
I'm trying to use dovecot to set up a 'closed server' (actually, mixed) sort of environment, for a box to be deployed co-located. I wanted to talk about some of that, and see if some of my experience qualifies as 'bug'.
Note that I'm notoriously verbose, so if that bothers you, read no further ....
Since it's a more-or-less closed server, I didn't want to use pam (well, I wouldn't mind, for users with shell accounts, but I can't see a way to mix pam and passwd-file ... is there a way to do that?).
It turns out that digest-md5 support for clients is, well, not very widespread. I expect this box to be used by various windoze clients, eventually, and while I'm willing to lay down the law a little, I can't find enough digest-md5 support to lay down that law. So, regretfully, I abandoned that plan. This kinda bothers me, since I think TLS/STARTTLS is absolutely the *wrong* solution for mailbox access (or for anything that deals with a store-and-forward transport).
I therefore tried md5 passwords in a passwd-file, with STARTTLS enabled. Didn't work. I turned off SSL, and reenabled plain-text, and watched the login go by. Very sniffable, of course. But correct username and password ... failed. There are instructions for creating digest-md5 style secrets in auth.txt, but none for md5 passwords; I used openssl passwd -1 [password] (and cut and paste). It seems odd to me that this didn't work; does that command use a different algorithm than dovecot?
Falling back ... since it *shouldn't* matter if the passwords are weak, as long as they're inside TLS (along with the entire rest of the transaughction, ugh), I used mkpasswd to generate a standard unix passwd (and cut and paste). This worked. It worked with TLS, and it worked without (as long as I remembered to allow sniffable logins).
Not to be confrontational at all, but I'm very curious as to why you have such an aversion to SSL/TLS for IMAP access? I think actualy an entirely encrypted transport for something as (possibly sensitive) email is a good thing.
One more oddity: I originally had a realm in the passwd-file, which also established the mail location and 'home' directory (most of the users can't actually log in and don't have accounts in /etc/passwd, so it's not a real home directory). There was an odd message in syslog, approximately like so (where 'user' represents the username, and 'domain.realm' represents both my domain name and the realm in the passwd-file):
imap(user:@omain.realm): Failed to create storage with data: domain.realm
Note the missing first letter after user:@ And I don't know what it was trying to do; the maildirs already exist. /etc/dovecot.conf sets the default mail location to /home/users/%n/Maildir (non-shell users are all inside /home/users; shell users have mail there, with symlinks to ~/Maildir); the passwd-file establishes the location of the INBOX pretty definitively, I would think. The solution was to remove the realm (which isn't useful except for digest md5, anway, right?).
Hey, it's working! Wahoo! *laugh* Anyway, if someone can offer suggestions on what's up with the pieces that *aren't* working, I'd be interested to know. It might give me a greater range of options.
Amy!
-- Jesse Peterson / jesse@pixeltechs.com
On Sat, 04 Jan 2003 21:05:48 -0800 Jesse Peterson jpeterson275@attbi.com wrote:
Amelia A.Lewis wrote:
It turns out that digest-md5 support for clients is, well, not very widespread. I expect this box to be used by various windoze clients, eventually, and while I'm willing to lay down the law a little, I can't find enough digest-md5 support to lay down that law. So, regretfully, I abandoned that plan. This kinda bothers me, since I think TLS/STARTTLS is absolutely the *wrong* solution for mailbox access (or for anything that deals with a store-and-forward transport).
Not to be confrontational at all, but I'm very curious as to why you have such an aversion to SSL/TLS for IMAP access? I think actualy an entirely encrypted transport for something as (possibly sensitive) email is a good thing.
That's exactly why.
TLS doesn't secure email. It secures this particular transaction over IMAP. Worse, from my particular perspective, it's the preferred solution to secure authentication, which means that lighter-weight solutions that protect only the authentication secret are much less available.
TLS also tends to be associated with ecommerce, and the famous (or possibly notorious) lock icon. It has a widespread connotation of comfortable security which, of course, IMAP+TLS alone cannot by any means actually guarantee.
My particular installation is supposed to protect the authentication secret, only, because I don't want someone using the system to think "my email is secure" because it runs over a TLS session. It isn't.
Secure email means end-to-end, an agreement between the people who are exchanging it and a willingness to encrypt (and usually to store encrypted). I dislike the impression given by TLS that it's a magical solution to the problem of security (which one hears from programmers that ought to know better, btw ... create an insecure system, and answer questions about security with "anyone worried about it can use SSL!").
But we're off topic, I think, and I'm ranting, because I ended up needing to use the heavyweight solution as client support for the solutions I prefer doesn't seem to be out there. Which is prolly why I made the snide and unnecessary remarks in the first place.
Amy!
Amelia A. Lewis amyzing {at} talsever.com Light is the left hand of darkness and darkness the right hand of light. Two are one, life and death, lying together like lovers in kemmer, like hands joined together, like the end and the way. -- Tormer's Lay [Ursula K. Le Guin, "The Left Hand of Darkness"]
On Sun, 2003-01-05 at 00:30, Amelia A.Lewis wrote:
Not to be confrontational at all, but I'm very curious as to why you have such an aversion to SSL/TLS for IMAP access? I think actualy an entirely encrypted transport for something as (possibly sensitive) email is a good thing.
That's exactly why.
TLS doesn't secure email.
=)
if email was secure, I wouldn't be spending a truly significant amount of time dealing with spam. But you're right in saying that TLS/SSL does not create a truly end-to-end secure email solution. Then again, neither does dovecot by itself. Nor should it. It should do one thing and do it well.
While digest-md5 is fairly secure from a transport perspective, it's a nightmare on the server side. In order for it to work, you've got to store account passwords in plain text on the server. In my opinion, this is "plain" wrong. (pun intended) Passwords should be hashed: even for closed systems. The fallacy lies with the wetware and people tend to forget passwords. Therefore, a lot of people have only one (or a set of) password(s) for everything they do. You can lobby against it, but people can be a hard species to change. If an attacker (or administrator) gained access to the database that a system relied upon for authentication (in the context of md5-digest), not only is that system's (or application's) security compromised for every other user, but so are many, many other systems that that user accesses. With hashed passwords, my users don't have to trust me to be honest enough not to look, but I can still reset their password.
TLS/SSL is merely a mechanism to provide privacy. In my case, I want my PLAIN password to remain private across a transport session. As a side note, most SSL/TLS sessions tend to use rc4 for their cipher. WEP uses rc4 too. I'm not that familiar with the details of SSL/TLS (and I just skimmed over RFC2246), so I might be talking out of the wrong hole, but as far as I know, it doesn't renegotiate keys during long sessions like IPsec or OpenVPN do. Think about that next time you spend all day with an IMAP-over-SSL connection open, transferring megabyte after megabyte of email around.
Personally, I just use stunnel to manage all my SSL connections. It beats having to manage every other application's unique method for handling SSL/TLS. I use PAM with pam_ldap to manage my logins. It just allows for much greater flexibility than what most application developers can bloat with their apps. (but it can also screw you up if you're not careful.) Using LDAP has complicated things a little, but that extra complexity has saved me BIG-TIME. (that whole idea of replication... yeah, decentralizing your data can be VERY handy when your system drive fails catastrophicly.)
What really ticked me off about Courier-imap is that it over-wrote my pam-configs for imap every time I did a "make install". I emailed Sam about it and his take was that I shouldn't be installing the imap server from source on a production box anyway. Now, I'm a from-source kinda guy. Daniel J. Bernstein is a from-source kinda guy. Package management has a high up-front cost and doesn't allow for the kind of customization that I do on everything box that I have.... and RPM won't even compile for me. (dpkg will and while I like the format and the design, I have some issues with a lot of the code that has been written for it.)
I have a few production systems that handle email. Half run uw imap and the other half, courier. dovecot seemed like a perfect solution for converting to. It still has a couple deployment issues that I'm trying to resolve, but I'll probably bring them up soon enough. (some of which have already been addressed since my last attempt)
so anyway... first time poster, had to make my comments. Am I speaking to the choir? d!
On 05 Jan 2003 18:48:01 -0500 "David E. Storey" dave@tamos.net wrote:
While digest-md5 is fairly secure from a transport perspective, it's a nightmare on the server side. In order for it to work, you've got to store account passwords in plain text on the server. In my opinion, this is "plain" wrong. (pun intended) Passwords should be hashed: even for closed systems. The fallacy lies with the wetware and people tend to
Umm, forgive me, but as I understand DIGEST-MD5, it does store hashed. Are you thinking of CRAM-MD5? As far as I know, that requires plain-text storage on the server, and I agree with your criticisms. I happen to like DIGEST-MD5 because it looks like someone finally came along and got the SASL auth mechanism right.
But perhaps I'm the one that's mistaken.
Amy!
Amelia A. Lewis amyzing {at} talsever.com Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise. -- The Duchess [Lewis Carroll]
On Sun, 2003-01-05 at 19:00, Amelia A.Lewis wrote:
Umm, forgive me, but as I understand DIGEST-MD5, it does store hashed. Are you thinking of CRAM-MD5? As far as I know, that requires plain-text storage on the server, and I agree with your criticisms. I happen to like DIGEST-MD5 because it looks like someone finally came along and got the SASL auth mechanism right.
But perhaps I'm the one that's mistaken.
=) no, you're right in that it's stored hashed. I was thinking of CRAM-MD5 specifically, but after reviewing section 3.9 of RFC2831, I'm still thinking that DIGEST-MD5 isn't really for me.
What's hashed is the username + ":" + realm + ":" + password. This is used to compute a part of the protocol. (referenced as A1) To quote the RFC:
There are two important security consequences of this. First the password file must be protected as if it contained plaintext passwords, because for the purpose of accessing documents in its realm, it effectively does.
A second consequence of this is that the realm string should be unique among all realms that any single user is likely to use. In particular a realm string should include the name of the host doing the authentication.
To me, this means a few things: 1. You can no longer simply change a user's name. 2) you can no longer simply change a host's name if you follow the RFC and finally 3) you can't efficiently use digest-md5 in a distributed authentication environment. (just doesn't scale well)
Since I deal with system-level accounts across multiple systems with occasional username changes (such as when someone marries) and system migrations where users and mail get shifted over to systems with different names or domains, then digest-md5 looks more and more like the wrong tools for the job.
Your requirements may be different, however and digest-md5 may be the perfect solution. =)
d!
On Sun, 2003-01-05 at 06:46, Amelia A.Lewis wrote:
Since it's a more-or-less closed server, I didn't want to use pam (well, I wouldn't mind, for users with shell accounts, but I can't see a way to mix pam and passwd-file ... is there a way to do that?).
Not really. I don't think it'd be worth the trouble.
It turns out that digest-md5 support for clients is, well, not very widespread. I expect this box to be used by various windoze clients, eventually, and while I'm willing to lay down the law a little, I can't find enough digest-md5 support to lay down that law. So, regretfully, I abandoned that plan. This kinda bothers me, since I think TLS/STARTTLS is absolutely the *wrong* solution for mailbox access (or for anything that deals with a store-and-forward transport).
I think Outlook supported only NTLM besides the plaintext auth. There's specs for it now so it would be possible to be supported too.
I therefore tried md5 passwords in a passwd-file, with STARTTLS enabled. Didn't work. I turned off SSL, and reenabled plain-text, and watched the login go by. Very sniffable, of course. But correct username and password ... failed. There are instructions for creating digest-md5 style secrets in auth.txt, but none for md5 passwords; I used openssl passwd -1 [password] (and cut and paste). It seems odd to me that this didn't work; does that command use a different algorithm than dovecot?
It uses different algorithm, although Dovecot could be made to support that too.. The Dovecot's algorithm is very simple and is compatible with pwdfile PAM module, it's simply the MD5 sum of a given text, eg:
perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex("pass")."[34]\n"'
Digest-MD5 passwords should probably rather be used so that could be used also by people who can. The description was a bit broken it seems, for plaintext authentication it works only if the realm is empty, so this should work:
perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex("user::pass")."[56]\n"'
imap(user:@omain.realm): Failed to create storage with data: domain.realm
Guess I should have actually tested this :) It tried to replace the ':' char with '@'. Fixed.
Note the missing first letter after user:@ And I don't know what it was trying to do; the maildirs already exist. /etc/dovecot.conf sets the default mail location to /home/users/%n/Maildir (non-shell users
%n was then "user:", so it didn't work.
The solution was to remove the realm (which isn't useful except for digest md5, anway, right?).
It's not really useful for digest-md5 either. It's mostly to support multiple realms running in same server. I'm not yet sure how I'd actually even properly support those .. probably fallback to user@realm style in plaintext passwords.
Maybe I should consider anyway using Cyrus SASL library, at least optionally. Would make life so much easier :) Everyone keeps wanting LDAP and MySQL and whatever support, but I'd rather concentrate on the IMAP side for now.
Quick replies from the man who knows! Thanks, Timo!
A request for clarification ...
On 05 Jan 2003 11:32:25 +0200 Timo Sirainen tss@iki.fi wrote:
On Sun, 2003-01-05 at 06:46, Amelia A.Lewis wrote: I think Outlook supported only NTLM besides the plaintext auth. There's specs for it now so it would be possible to be supported too.
If I could think of a way to break outlook without breaking other windows clients, I'd do it. As a service to the community (reduction of virus infections). But prolly you want to be compatible.
I therefore tried md5 passwords in a passwd-file, with STARTTLS enabled. Didn't work. I turned off SSL, and reenabled plain-text, and watched the login go by. Very sniffable, of course. But correct username and password ... failed. There are instructions for creating digest-md5 style secrets in auth.txt, but none for md5 passwords; I used openssl passwd -1 [password] (and cut and paste). It seems odd to me that this didn't work; does that command use a different algorithm than dovecot?
It uses different algorithm, although Dovecot could be made to support that too.. The Dovecot's algorithm is very simple and is compatible with pwdfile PAM module, it's simply the MD5 sum of a given text, eg:
perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex("pass")."[34]\n"'
Digest-MD5 passwords should probably rather be used so that could be used also by people who can. The description was a bit broken it seems, for plaintext authentication it works only if the realm is empty, so this should work:
perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex("user::pass")."[56]\n"'
Okay. In other words, any of the three password styles will work with plaintext auth and no realm?
And digest-md5 with no realm can be used both in plaintext, and in digest-md5 (making sure that dovecot.conf has an empty realms list)?
If the latter is true, I think that that's what I want to do ....
I think some clarifications to auth.txt might be in order; perhaps I'll write some bits and offer the diff? Or the modified file?
Maybe I should consider anyway using Cyrus SASL library, at least optionally. Would make life so much easier :) Everyone keeps wanting LDAP and MySQL and whatever support, but I'd rather concentrate on the IMAP side for now.
I *like* your focus. I like dovecot and its ease of setup very much. If lots of features are addded, then complexity is likely to rise ... in that case, perhaps the postfix pattern of config files would be worth emulating? Because basic postfix configuration remains simple; certain sorts of more complex configuration (like virtual alias domains and virtual mailbox domains) live in their own files, referenced from main, but documented separately.
I'm unthrilled with the current state of SASL; it seems to be in flux between version 1.5 and version 2.1, which are not mutually compatible (I'm pretty sure that this is why mutt doesn't do digest-md5 on my system). That will eventually get straightened out, I'm sure. But the current state of auth in dovecot seems to allow most things that SASL might offer, so perhaps it isn't yet worth the hassle of linking.
Amy!
Amelia A. Lewis amyzing {at} talsever.com alicorn@mindspring.com I stopped by the bar at 3 a.m. to seek solace in a bottle, or possibly a friend. I woke up with a headache like my head against a board, twice as cloudy as I'd been the night before. I went in seeking clarity. -- Indigo Girls
Timo Sirainen wrote:
Maybe I should consider anyway using Cyrus SASL library, at least optionally.
Please do! It works, it's flexible, it's secure, and allows central administration of authentication.
Yours truly,
Paul C. Bryan email@pbryan.net
On Sun, 2003-01-05 at 21:36, Paul C. Bryan wrote:
Maybe I should consider anyway using Cyrus SASL library, at least optionally.
Please do! It works, it's flexible, it's secure, and allows central administration of authentication.
Well, current CVS has some code for it, but it's still missing some configuration. Actually I'm not really sure how I should do that, I found one way but Postfix doesn't seem to doing that..
And secure? I doubt it, I did a quick audit to it a month ago and found 3 buffer overflows. I checked mostly just PLAIN mechanism which I use with Postfix, so there may well be more left in other auth mechanisms.
Hi ;-)
[...]
Well, current CVS has some code for it, but it's still missing some configuration. Actually I'm not really sure how I should do that, I found one way but Postfix doesn't seem to doing that..
And secure? I doubt it, I did a quick audit to it a month ago and found 3 buffer overflows. I checked mostly just PLAIN mechanism which I use with Postfix, so there may well be more left in other auth mechanisms.
Personaly I don't like too mutch Cyrus SASL for lots of reasons :
I don't trust it a lot
this yet another lib to add to the thousands of lib used for authentication eg : server code (here dovecot) -> sasl -> pam -> mod_someth -> something lib -> something server -> db ..
Yes I know there is patch for sasl 1.x and there some other backend for sasl 2.x but I still don't like it.
Adding some lines of code into dovecot for authentication against MySQL (for example) or LDAP should not too mutch and mutch easy to debug / audit than a big library like SASL.
For my point of view, I going, when time available a patch for dovecot to do mysql auth, since I want to move from courier-imap (sorry) to a better solution that is dovecot.... (that I use at home using pam)... to get a 100% virtual account solution without adding 3rd party code... ;-)
my 0.02c
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. For mail address, please check header of this mail. Spams are not accepted. Caudium: http://caudium.net/ Making friends with FreeBSD: Just because the system has panicked doesn't mean that you should panic too
Timo Sirainen wrote:
And secure? I doubt it, I did a quick audit to it a month ago and found 3 buffer overflows. I checked mostly just PLAIN mechanism which I use with Postfix, so there may well be more left in other auth mechanisms.
Was this version 1 or version 2?
Paul
On Mon, 2003-01-06 at 01:15, Paul C. Bryan wrote:
And secure? I doubt it, I did a quick audit to it a month ago and found 3 buffer overflows. I checked mostly just PLAIN mechanism which I use with Postfix, so there may well be more left in other auth mechanisms.
Was this version 1 or version 2?
- 1.5.x didn't have the same problems, because it didn't even have those features (or two of them).
participants (6)
-
Amelia A.Lewis
-
David E. Storey
-
Jesse Peterson
-
Paul C. Bryan
-
Timo Sirainen
-
Xavier Beaudouin