[Dovecot] Disable TLS on port 143?
Hi all,
Is there a way to disable the TLS support provided by Dovecot on port 143? I'd like to run SSL on 993, so as far as I can tell I can't use ssl_disable, since the will disable SSL. I'm looking for the equivalent of an ssl_disable_tls setting.
Thanks much, Jackie
Jackie Hunt
ACNS Voice: (970) 663-3789
Colorado State University FAX: (970) 491-1958
Fort Collins, CO 80523 Email: jackie.hunt@colostate.edu
Jackie Hunt wrote:
Hi all,
Is there a way to disable the TLS support provided by Dovecot on port 143? I'd like to run SSL on 993, so as far as I can tell I can't use ssl_disable, since the will disable SSL. I'm looking for the equivalent of an ssl_disable_tls setting.
You can use ipchains or your external firewall to disable TLS, though why you care, I don't know. TLS is exactly the same thing as SSL, except that the initial connection isn't encrypted (though nothing of significance is passed before the connection is upgraded to an encrypted one).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Jackie Hunt wrote:
Hi all,
Is there a way to disable the TLS support provided by Dovecot on port 143?
You can use ipchains or your external firewall to disable TLS, though why you care, I don't know.
Thanks, John. I'm replacing a UofW IMAP server, and would like to do a "transparent" switch to Dovecot. We found that the clients are negotiating a TLS connection on 143, and then complaining about our certificate. I want to avoid having to reconfigure clients.
I haven't hear of ipchains, I'll investigate.
Jackie
Jackie Hunt
ACNS Voice: (970) 663-3789
Colorado State University FAX: (970) 491-1958
Fort Collins, CO 80523 Email: jackie.hunt@colostate.edu
On 9.1.2007, at 21.53, Jackie Hunt wrote:
Is there a way to disable the TLS support provided by Dovecot on port 143?
You can use ipchains or your external firewall to disable TLS, though why you care, I don't know.
Thanks, John. I'm replacing a UofW IMAP server, and would like to do a "transparent" switch to Dovecot. We found that the clients are negotiating a TLS connection on 143, and then complaining about our certificate. I want to avoid having to reconfigure clients.
I don't think you'll find any simple way to do that other than
modifying the sources. I'd rather not add yet another new setting
just for that. In v2.0 it'll probably be possible because I'm adding
support for all kinds of setting groups.
I haven't hear of ipchains, I'll investigate.
It'd have to remove "STARTTLS" from CAPABILITY response. No idea if
it's actually capable of doing that.
Timo Sirainen wrote:
It'd have to remove "STARTTLS" from CAPABILITY response. No idea if it's actually capable of doing that.
No, ipchains isn't smart enough (I wasn't paying attention, DUH). It could only be done with a transparent proxy. But just stripping the STARTTLS from the CAPABILITY like this:
--- ./src/imap-login/client.c.orig 2007-01-09 15:03:49.298055528 -0500 +++ ./src/imap-login/client.c 2007-01-09 15:04:06.883739152 -0500 @@ -100,7 +100,7 @@ auths = client_authenticate_get_capabilities(client->common.secured); return t_strconcat(capability_string, (ssl_initialized && !client->common.tls) ? - " STARTTLS" : "", + "" : "", disable_plaintext_auth && !client->common.secured ? " LOGINDISABLED" : "", auths, NULL); }
(watch wrapping) should be sufficient. Of course, if the real issue is that the users are frightened by the unsigned certificate message, he could pony up the $100 for a cert signed by a trusted authority and the clients won't even bleat... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Tue, 09 Jan 2007 15:07:21 -0500 John Peacock jpeacock@rowman.com wrote:
Of course, if the real issue is that the users are frightened by the unsigned certificate message, he could pony up the $100 for a cert signed by a trusted authority and the clients won't even bleat...
--
Brian Morrison
bdm at fenrir dot org dot uk
"Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it."
GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html
Brian Morrison wrote:
How many older mail clients have the CACert trusted root installed? From the CACert FAQ:
Why a CAcert-signed certificate better than a self-signed?
Even though we're not included by default in main stream browsers a number of linux distributions are already including us in their builds of Mozilla and other browsers/email clients.
This would not be a 100% painless upgrade, whereas buying a cert from a Geotrust partner would be cheap insurance that most clients, even a few years old, would see no warning...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Tuesday, January 09, 2007, at 11:28AM, "John Peacock" jpeacock@rowman.com wrote:
Brian Morrison wrote:
This would not be a 100% painless upgrade, whereas buying a cert from a Geotrust partner would be cheap insurance that most clients, even a few years old, would see no warning...
*** QUOTE *** GeoTrust News & Events
September 5, 2006, VeriSign Completes Acquisition of GeoTrust *** END QUOTE ***
Maybe because he doesn't want to be hit with VeriSign's renewal fees in a year....
Peter Giessel wrote:
*** QUOTE *** GeoTrust News & Events
September 5, 2006, VeriSign Completes Acquisition of GeoTrust *** END QUOTE ***
Maybe because he doesn't want to be hit with VeriSign's renewal fees in a year....
Thoroughly offtopic now, but when VeriSign bought Thawte, there were similar doom/gloom predictions, which have not panned out. FWIW, I am a GeoTrust reseller (via Tucows) and as far as anyone can tell, VeriSign is simply looking to add to it's different channels, and Tucows is claiming up and down that their pricing isn't going to change (and hence my pricing isn't either).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
But just stripping the STARTTLS from the CAPABILITY like this:
...
(watch wrapping) should be sufficient.
Of course, if the real issue is that the users are frightened by the unsigned certificate message, he could pony up the $100 for a cert signed by a trusted authority and the clients won't even bleat...
Thanks much for the feedback John & Timo. I hope you do add ssl_disable_tls as an option in v 2.0 Timo. That's be great.
Our users run a wide variety of clients, so it'd be difficult to confirm that we wouldn't affect someone with the TLS capability, even with a trusted authority. Changing source is an option, true. The other option is sslwrap, which we use with UofW. We could disable ssl on Dovecot and use sslwrap for 993. I just wanted to use Timo's code where possible.
Jackie
Jackie Hunt
ACNS Voice: (970) 663-3789
Colorado State University FAX: (970) 491-1958
Fort Collins, CO 80523 Email: jackie.hunt@colostate.edu
Jackie Hunt wrote:
Our users run a wide variety of clients, so it'd be difficult to confirm that we wouldn't affect someone with the TLS capability, even with a trusted authority.
For reference purposes, in most mail clients there is a single "Trust this certificate forever" dialog that has to be responded to, even with a self-signed certificate. After you instruct the client to trust that certificate (regardless of the chain), the dialog never reappears. You may be worrying for no reason (or you may have particularly timid users, for which you have my sympathy).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Tue, Jan 09, 2007 at 01:31:42PM -0700, Jackie Hunt wrote:
But just stripping the STARTTLS from the CAPABILITY like this:
...
(watch wrapping) should be sufficient.
Of course, if the real issue is that the users are frightened by the unsigned certificate message, he could pony up the $100 for a cert signed by a trusted authority and the clients won't even bleat...
Thanks much for the feedback John & Timo. I hope you do add ssl_disable_tls as an option in v 2.0 Timo. That's be great.
Our users run a wide variety of clients, so it'd be difficult to confirm that we wouldn't affect someone with the TLS capability, even with a trusted authority. Changing source is an option, true. The other option is sslwrap, which we use with UofW. We could disable ssl on Dovecot and use sslwrap for 993. I just wanted to use Timo's code where possible.
STARTTLS is a newer standard than allocating separate ports for the SSL-equivalents. Note that IMAP, POP, and SMTP protocols all support this (it is called STLS in POP) and it is generally preferred over the SSL-at-connect ports (465, 993, 995). If we turned one or the other one off, it would certainly not be the STARTTLS-enabled ports (110, 143, 587). Note, however, that we still require STARTTLS (we don't allow plain-text connections due to the lack of password security it would imply.)
If I were you, I'd add another IP alias on the host (an additional IP address) in which you could run Dovecot on, so as not to interfere with your existing software listening on the existing IP address. This may or may not work for you, depending on how you are transitioning, but I just wanted to make that suggestion.
Jackie
Jackie Hunt
ACNS Voice: (970) 663-3789
Colorado State University FAX: (970) 491-1958 Fort Collins, CO 80523 Email: jackie.hunt@colostate.edu
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
On Tue, 9 Jan 2007 21:57:59 +0200 Timo Sirainen tss@iki.fi wrote:
I haven't hear of ipchains, I'll investigate.
iptables would be better, ipchains is from kernel 2.2 so it's deprecated.
It'd have to remove "STARTTLS" from CAPABILITY response. No idea if
it's actually capable of doing that.
The sane thing is simply to block all incoming traffic on port 143, then only port 993 is available. If this creates problems with other site policies, or external access if people need it, then it isn't a good solution.
--
Brian Morrison
bdm at fenrir dot org dot uk
"Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it."
GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html
Jackie Hunt jackie@yuma.acns.colostate.edu writes:
Thanks, John. I'm replacing a UofW IMAP server, and would like to do a "transparent" switch to Dovecot. We found that the clients are negotiating a TLS connection on 143, and then complaining about our certificate. I want to avoid having to reconfigure clients.
How about fixing the certificate or pointing clients to the right root certificate?
Alternatively, using stunnel as SSL service wrapper on port 993 on an otherwise unencrypted ssl-disabled Dovecot installation might work.
-- Matthias Andree
participants (7)
-
Brian Morrison
-
Jackie Hunt
-
John Peacock
-
Matthias Andree
-
Peter Giessel
-
Steven F Siirila
-
Timo Sirainen