[Dovecot] imap, imaps, ports; config for secure-only service
Hello, having difficulty setting up a 'secure-only' service on a non-standard port.
Objective is to open a secure Dovecot service on an internet-visible port, while also using an insecure service for hosts on an internal network (so that one particular client which is not SSL/TLS-capable can continue to use the service).
Checking wiki1 and wiki2, I think that port 143 can be used for a service in both encrypted and unencrypted operations. (Wiki2 describes how port 143 can be used with or without STARTTLS.) I've managed to run both TB/Vista, and KMail/Debian on 143 from local machines, and they seem to work fine. (Though they do only work if the clients are set to use 'unencrypted logins' such as KMail's 'clear text' setting, and TB's 'don't use secure authentication'.) Dovecot's SSL certificate on the server expires in 2028.
But I cannot get my 'secure-only service' working at all. I've chosen port 10943 for that service, and have been testing from both KMail on the server, and TB/Vista on another local machine.
Here's the config:
protocol imap {
# inet users, and also users presented from offsite via an SSH tunnel, # will use IMAP (any capability) on 143. listen = *:143 # 143 will not be reachable from outside the internal network (except # via an SSH tunnel) # # External users will be allowed only to use port 10943 (as forwarded # from the gateway), and will have to use SSL ssl_listen = *:10943 }
Other settings include:
#other settings protocols = imap imaps disable_plaintext_auth = no ssl_disable = no ssl_cert_file = /etc/ssl/certs/dovecot.pem ssl_key_file = /etc/ssl/private/dovecot.pem ssl_verify_client_cert = no ssl_cipher_list = ALL:!LOW ssl_require_client_cert = no ssl_username_from_cert = no mail_location = maildir:~/Maildir
#log and debug settings mail_debug = yes auth_debug = yes
Log from a successful session on port 143:
Logs (using port 143, KMail on the server)
14:43:22 auth(default): client in: AUTH^I1^IPLAIN^Iservice=IMAP^Isecured^Ilip=127.0.0.1^Irip=127.0.0.1^Iresp=<hidden>
14:43:22 auth(default): client out: OK^I1^Iuser=ron
14:43:22 auth(default): master in: REQUEST^I1^I4057^I1
14:43:22 auth(default): master out: USER^I1^Iron^Isystem_user=ron^Iuid=1001^Igid=1001^Ihome=/home/ron
14:43:22 IMAP(ron): Effective uid=1001, gid=1001
14:43:22 IMAP(ron): maildir: data=/home/ron/Maildir
14:43:22 IMAP(ron): maildir: root=/home/ron/Maildir, index=/home/ron/Maildir, control=, inbox=
14:43:22 imap-login: Login: user=<ron>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS
Unsuccessful session
Logs (using 10943, KMail on the server) - absolutely no sign of any authentication, and the client reports a timeout.
17:03:30 imap-login: Disconnected: Inactivity: rip=127.0.0.1, lip=127.0.0.1, TLS handshake
17:04:06 imap-login: Disconnected: rip=127.0.0.1, lip=127.0.0.1, TLS handshake
17:05:08 imap-login: Disconnected: Inactivity: rip=127.0.0.1, lip=127.0.0.1, TLS handshake
143 works fine, so Dovecot is (of course) perfectly good at managing the auth and service, so I must have something wrong in the config. I cannot see it. Could anyone share a config they've used for *secure-only* IMAP service on an internet-visible port? I'd like to compare the settings.
regards, Ron
Ronald Leach wrote:
Hello, having difficulty setting up a 'secure-only' service on a non-standard port.
Upgraded version on the server to the latest backport available for the server, having saved the conf file. Started from scratch with standard settings. Particularly:
protocol = imap imaps listen = *
Checking wiki1 and wiki2, I think that port 143 can be used for a service in both encrypted and unencrypted operations. (Wiki2 describes how port 143 can be used with or without STARTTLS.)
143 only worked when protocols = imap was present. In this case, Thunderbird (on a Vista client) worked in 'TLS' mode. The log showed authentication using PLAIN, and TLS secured. The wiki implies that TLS provides end to end (client to dovecot) encryption, and (I think) means that the initial username/password exchange is, therefore, also protected. (On the basis that the link protection is built before the authentication sequence is started.)
But I want to force secure working - in some kind of secure-only mode, so that internet-based users can reach the server securely. So I changed the protocols to:
protocol = imaps
with:
disable_plaintext_auth = yes
In this configuration, TB could not connect on 143, but only on 993, *and*, only if TB's SSL option is selected (not its TLS option). This was good, and bad.
Good, because it 'forced' use of a secure connection (assuming that in this mode the connection is *actually* protected end-to-end); the email client asked if Dovecot's certificate should be accepted, so there was certainly some protection going on at some point.
But this was *bad*, I thought, because the wiki suggests http://wiki.dovecot.org/SSL that TLS has replaced SSL, so I am not sure that using SSL is the proper thing to do. Incidentally - almost in a tribute to the wiki article - Dovecot recorded the authentication as TLS.
I think I've disabled insecure access from any client - which is a pity because we have one client application that is not SSL/TLS-capable, as I mentioned before. The Dovecot website also talks about a proxy operation, so I may set up an insecure proxy on our other server, and let that proxy for that one application.
Otherwise, I think it is running securely, which is a good step forward to allow access from the internet.
regards, Ron
On 2010-08-22 11:47 AM, Ron Leach ronleach@tesco.net wrote:
But I want to force secure working - in some kind of secure-only mode, so that internet-based users can reach the server securely. So I changed the protocols to:
<snip>
I think I've disabled insecure access from any client - which is a pity because we have one client application that is not SSL/TLS-capable, as I mentioned before.
There are 2 ways I can think of to do this...
To do it with dovecot you'd use extra fields (allow_nets to be precise)...
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets
Another way would be to open both ports, but limit access to the insecure port to only the desired host(s) using your firewall... ie, block access to port 143 at the firewall for all external clients...
--
Best regards,
Charles
On Sun, 2010-08-22 at 16:47 +0100, Ron Leach wrote:
But I want to force secure working - in some kind of secure-only mode, so that internet-based users can reach the server securely. So I changed the protocols to:
protocol = imaps
with:
disable_plaintext_auth = yes
In this configuration, TB could not connect on 143, but only on 993, *and*, only if TB's SSL option is selected (not its TLS option). This was good, and bad.
You need either v2.0 or run two separate Dovecot installations with different configs. With v2.0 you could do simply:
disable_plaintext_auth = yes remote_ip 10.0.0.0/8 { disable_plaintext_auth = no }
or something like that.
participants (4)
-
Charles Marcus
-
Ron Leach
-
Ronald Leach
-
Timo Sirainen