[Dovecot] Allowing non-SSL connections only for certain Password Databases
I'm trying to set up my system (using Dovecot 2.0.9) so that certain Password Databases are available over pop3 and imap and others are available over pop3s and imaps.
In particular, I would like users to be able to connect without SSL to accounts set up in vpopmail, but to require SSL for system accounts.
Is there a way to set "disable_plaintext_auth" to different values for different Password Databases? Is there another way to do it?
Thank you, Dan
Hi,
Is there a way to set "disable_plaintext_auth" to different values for different Password Databases? Is there another way to do it?
Why do you not force SSL for all users?
I have no idea how this could be made with different databases. I have only build a solution for all users stored in mysql.
I'm able to force SSL for imap and pop3 on a per user basis with e.g.:
... password_query = SELECT password FROM users WHERE userid = '%u' AND allow_login = 'y' AND ( force_ssl = 'y' OR '%c' = 'secured'); ...
Query adopted from: http://wiki2.dovecot.org/Authentication/RestrictAccess
For available variables see: http://wiki2.dovecot.org/Variables
As I just said, this works for me, but only for users stored in mysql.
Regards Urban
On Tuesday, April 22, 2014 3:31:47 PM CEST, Urban Loesch wrote:
Waitasecond. I might be totally off here, but the way I read that query you accept plaintext credentials, unsecured and then check the DB. After which you might say "You're not allowed to log in".
If that is correct every user might send their credentials over unsecured connections?
In my opinion this doesn't help. Clients cannot know in advance that they shouldn't try to login.
I guess I'd either
drop the requirement (best option, hit the users that don't support TLS or offer them help to upgrade/fix their setup)
live with the possibility that the system users are potentially disclosing their credentials.
Take a step back: A random client connects to dovecot. It didn't log in yet. How would you change the capabilities to reflect 'login without starttls is allowed or not', depending on a username that you cannot know at this point?
My take, ignoring the "There shouldn't be a need for that" quip, is that this is next to impossible. And not worth the challenge.
Ben
On Apr 23, 2014, at 1:38 AM, Benjamin Podszun <dar@darklajid.de> wrote:
I would like to move everyone onto more modern mail programs, but at the moment I have a couple of them that are stuck using very old software installed for them on work computers. The rest of my clients can connect on ports 993 and 995 without it being a problem.
It's far from a perfect setup.
This is quite easy to set up on Courier-imap, but for a number of reasons I would much rather be using Dovecot. (In courier-imap, you can configure different password databases independently for each of pop3, imap, pop3-ssl and imap-ssl.)
Given that Dovecot features seem to be a superset of those from Courier-imap so far, I was hoping this configuration option would exist there as well.
Dan
On Wednesday, April 23, 2014 10:50:37 AM CEST, Dan Pollock wrote:
What's wrong with starttls? How are the ports relevant? Do you happen to know what the problem is? Total lack of TLS support (I .. cannot quite believe that) or is it a problem with key sizes/ciphers or whatever, i.e. with your configuration vs. the legacy apps?
Which is really not that helpful, I think. Joe random system user can still set up his mailclient to point to mail.yourdomain.tld and try to login unencrypted. You'll only deny him afterwards (even with a different password DB), after the password was transmitted over unencrypted wifi in his local StarBucks™ or equivalent. Or what am I missing here? All system users are too clever for that? In that case they can already use the ports listed above (or set their mail client to require starttls on 143/110). If they're not that security conscious, what protects them from the scenario above?
See above: What would you gain? Would that actually help you? In the end it's your setup and I don't want to come across and say "You're doing it wrong" here, but so far it's hard to see what you're trying to archive with that .. feature?
Regards, Ben
Am 23.04.2014 10:38, schrieb Benjamin Podszun:
Yes that is correct and I knew that when I configured the setup. But I can't manipulate the clients.
If that is correct every user might send their credentials over unsecured connections?
Yes, that is a disadvantage. As I just said, I can't change that.
Can you help me to upgrade/fix 40k users, which have no idea how to change the settings of a mail client? Send me your phonenumber and I will redirect all requests of that to you :-)
You will see very quickly that it's not practicable to force all users to use SSL at the same time. With this setup I can bring users step by step to use SSL.
I have no system users.
I know all usernames as I activate them. So I can control which user must use SSL and which not. I also for example can control which user is forced to use port 587 for sending their email and which not.
On Wednesday, April 23, 2014 10:57:23 AM CEST, Urban Loesch wrote:
I haven't defined an hourly rate so far, but I could think about something here.. ;-)
Really, my 'you' in most of the reply was about Dan's requirement/targeting the thread: He has system users, probably with shell access(?) and wants to protect those 'more' than virtual users, as far as I understood. I claim that his requirement is hard to implement/next to impossible.
You on the other hand .. have other issues. ;) Takeaway from my response to you, Urban, should've been: "I don't think your workaround helps with the original author's requirement", not "Fix your own setup!".
Ben
participants (3)
-
Benjamin Podszun
-
Dan Pollock
-
Urban Loesch