[Dovecot] Enforcing TLS
Hello all,
I've happily been using Dovecot for a couple of years now, but only a couple of days ago I configured it to speak both TLS and SSL for both POP3 and IMAP. Ideally I want users to use TLS, but I've enabled SSL, because some mailers (at least Apple Mail on OS X Tiger) don't support TLS.
Right now I'm in sort of a transitional phase, where I'm asking users to enable TLS in their email clients, if not enabled already. After a couple of weeks/months I want to disable any (non-local) connections that don't use TLS or SSL.
I already asked on IRC whether this was possible, because I was unable to find this on the Wiki. It turns out there is a configuration switch called `disable_plaintext_auth', but looking at the description this only prevents people from using plain-text username/password authentication. It does not actually enforce TLS or SSL.
My question: is there support to enforce TLS when people connect to non-SSL ports? If someone comes up with a solution, I'll add it to the SSL article on the Wiki.
I'm using Dovecot 1.1.7, installed on a FreeBSD 6.4-STABLE system.
Thanks!
-- Ed Schouten ed@80386.nl WWW: http://80386.nl/
On Tue, 2009-01-06 at 14:59 +0100, Ed Schouten wrote:
I've happily been using Dovecot for a couple of years now, but only a couple of days ago I configured it to speak both TLS and SSL for both POP3 and IMAP. Ideally I want users to use TLS, but I've enabled SSL, because some mailers (at least Apple Mail on OS X Tiger) don't support TLS.
BTW. Your TLS/SSL term usage isn't correct. http://wiki.dovecot.org/SSL
I already asked on IRC whether this was possible, because I was unable to find this on the Wiki. It turns out there is a configuration switch called `disable_plaintext_auth', but looking at the description this only prevents people from using plain-text username/password authentication. It does not actually enforce TLS or SSL.
My question: is there support to enforce TLS when people connect to non-SSL ports? If someone comes up with a solution, I'll add it to the SSL article on the Wiki.
Have you enabled non-plaintext authentication? If not, then disable_plaintext_auth practically does what you want, because you can't authenticate without SSL/TLS.
- Timo Sirainen tss@iki.fi wrote:
Have you enabled non-plaintext authentication? If not, then disable_plaintext_auth practically does what you want, because you can't authenticate without SSL/TLS.
Oh, great. I don't know a lot of IMAP/POP3-internals, but I was unsure whether `disable_plaintext_auth' still allowed non-secured connections to take place in my setup, as long as the client used some broken form of hashing/encoding the password (like base64), which is obviously not what I want.
Thanks for the information. I'll add it to the Wiki article "SSL/DovecotConfiguration".
-- Ed Schouten ed@80386.nl WWW: http://80386.nl/
On 2009-01-06, Timo Sirainen tss@iki.fi wrote:
I already asked on IRC whether this was possible, because I was unable to find this on the Wiki. It turns out there is a configuration switch called `disable_plaintext_auth', but looking at the description this only prevents people from using plain-text username/password authentication. It does not actually enforce TLS or SSL. =20 My question: is there support to enforce TLS when people connect to non-SSL ports? If someone comes up with a solution, I'll add it to the SSL article on the Wiki.
Have you enabled non-plaintext authentication? If not, then disable_plaintext_auth practically does what you want, because you can't authenticate without SSL/TLS.
We have the opposite requirement... Is it possible to enable SSL on the POPS/IMAPS-port, without also enabling STARTTLS on the POP/IMAP ports?
We're hosting many mail domains on the same ip-addresses, and offer mail.$partnername.com as pop/imap server. Now we'd like to also offer a single name for POPS/IMAPS with a non-per-partner-branded name mail.securedomain.com on the same set of servers as the non SSL-version of dovecot is running. This is mostly to avoid needing lots of SSL certificates.
We're afraid that if we enable STARTTLS, many of our existing clients will automatically try using SSL towards the wrong name, and get ugly SSL warnings about certifcate mismatch.
-jf
Dunno if I'm talking about the right thing or if this would help, but...
we have gone over to a single wildcard certficate for everything in the *.bard.edu domain (from Digicert)...this costs $495 for a single year, less for multiple years.
Then everything coming at a machine of the format: <somename>.bard.edu comes up valid. If the hostname is of the format <somename1>.<somename2>.bard.edu (or <somename1>.<somename2>...<somenameN>.bard.edu) , then you have to explicitly list it when submitting the CSR, but you can list up 10 host names for the certificate you generate for that machine when submitting the CSR........
Jan-Frode Myklebust wrote:
On 2009-01-06, Timo Sirainen tss@iki.fi wrote:
We're afraid that if we enable STARTTLS, many of our existing clients will automatically try using SSL towards the wrong name, and get ugly SSL warnings about certifcate mismatch.
-jf
-- ==== Once upon a time, the Internet was a friendly, neighbors-helping-neighbors small town, and no one locked their doors. Now it's like an apartment in Bed-Stuy: you need three heavy duty pick-proof locks, one of those braces that goes from the lock to the floor, and bars on the windows.... ==== Stewart Dean, Unix System Admin, Bard College, New York 12504 sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
On Fri, Jan 09, 2009 at 09:25:46AM -0500, Stewart Dean wrote:
Dunno if I'm talking about the right thing or if this would help, but...
we have gone over to a single wildcard certficate for everything in the
*.bard.edu domain (from Digicert)...this costs $495 for a single year,
less for multiple years.
Yes, I know about these, but that's not what we need. We need lots of second level domain certs, so a wildcard woun't help.
-jf
On Jan 9, 2009, at 6:34 AM, Jan-Frode Myklebust wrote:
We have the opposite requirement... Is it possible to enable SSL on
the POPS/IMAPS-port, without also enabling STARTTLS on the POP/IMAP ports?
Not currently unless you run two Dovecot installations with different
configuration files.
On T 6 Jan, 2009, at 14:59 , Ed Schouten wrote:
My question: is there support to enforce TLS when people connect to non-SSL ports? If someone comes up with a solution, I'll add it to the SSL article on the Wiki.
I'm using Dovecot 1.1.7, installed on a FreeBSD 6.4-STABLE system.
not sure I understand the question correctly, if I do then the answer
would be you cannot. If the client wants to speak plain it will. I do
not see why you would want to keep on listening on port 143 if you
want to enforce SSL, but if you really want to:
protocol imap {
listen = 127.0.0.1:143
ssl_listen = *:993 <interface-ip>:143
}You can of course drop <interface-ip>:143.
Giuliano
On F 9 Jan, 2009, at 13:11 , Giuliano Gavazzi wrote:
On T 6 Jan, 2009, at 14:59 , Ed Schouten wrote:
My question: is there support to enforce TLS when people connect to non-SSL ports? If someone comes up with a solution, I'll add it to
the SSL article on the Wiki.I'm using Dovecot 1.1.7, installed on a FreeBSD 6.4-STABLE system.
not sure I understand the question correctly, if I do then the
answer would be you cannot. If the client wants to speak plain it
will. I do not see why you would want to keep on listening on port
143 if you
sorry, I wasn't aware that disable_plaintext_auth would suppress the
AUTH=PLAIN capability list. I would not rely on that though, there
might be around buggy clients (of which there are in general plenty!)
that would ignore that...
g
participants (5)
-
Ed Schouten
-
Giuliano Gavazzi
-
Jan-Frode Myklebust
-
Stewart Dean
-
Timo Sirainen