[Dovecot] TLS / SSL mixed w/ plaintext auth and virtual hosting
Traditionally this server has only accepted plaintext authentications; however, we want to change that and enable TLS/SSL. The challenge is the server has hundreds of IP addresses it binds to to listen on ports 110/143.
Enabling TLS/SSL is not an option because as this is a virtual hosting environment, if a connection comes in on any other hostname other than the specific one tied to the crt all mail clients will throw a mis-matched certificate error if TLS is initiated by the client, and a surprisingly large number of customers have "use TLS if available" selected in their clients.
According to most of the suggestions on the list, I've setup 2 dovecot instances. The first listening on *:110 and *:143, and the second listening on 10.0.0.2:993 and 10.0.0.2:995. This works great for SSL support; however, I would also like to offer TLS to connections coming in on a single IP address.
Because the server has hundreds of IPs, with new IPs adding all the time, seemingly the only way would be to configure every one of these IPs (as they occur) into the primary dovecot.conf file, and then only setup the single IP that's handling SSL/TLS in the dovecot-ssl.conf (the conf file the SSL/TLS instance loads). This can be time consuming and has no way to automate. It would be terrific if one of the following exists, or potentially could exist:
Ideal scenario. A config option which tells TLS to only respond on certain IPs. In our case if a connection attempts to initiate TLS on any IP address except 10.0.0.2, it would respond with no TLS support. This would be ideal as we could continue running just a single dovecot instance.
Secondary scenario. A way to exclude an IP from being bound to. Something like the following to bind to all except 10.0.0.2 listen = *:110, -10.0.0.2
As is, based on my understanding of the config neither of these are options. Any support for adding either of these options, or alternate ideas anyone might have?
- N
On 27/08/2009 02:27, Nathan M wrote:
- Ideal scenario. A config option which tells TLS to only respond on certain IPs. In our case if a connection attempts to initiate TLS on any IP address except 10.0.0.2, it would respond with no TLS support. This would be ideal as we could continue running just a single dovecot instance.
You could use your local flavour of firewall (iptables, ipfw, pf, whatever) with a rule to pass inbound TCP to 10.0.0.2:993 and then a following rule to drop all other inbound TCP to port 993 ?
Regards,
Jase.
Nathan M wrote:
Traditionally this server has only accepted plaintext authentications; however, we want to change that and enable TLS/SSL. The challenge is the server has hundreds of IP addresses it binds to to listen on ports 110/143.
It may be 3am, but I'm pretty sure that this is the part of your setup that doesn't make sense. Why does your POP/IMAP server need to be accessed via so many addresses?
On Thu, Aug 27, 2009 at 12:03 AM, Michael Orlitzky<michael@orlitzky.com> wrote:
Nathan M wrote:
Traditionally this server has only accepted plaintext authentications; however, we want to change that and enable TLS/SSL. The challenge is the server has hundreds of IP addresses it binds to to listen on ports 110/143.
It may be 3am, but I'm pretty sure that this is the part of your setup that doesn't make sense. Why does your POP/IMAP server need to be accessed via so many addresses?
Because everybody wants to check email at mail.$theirdomain.com. Also, some users "need" to check email with username only, so the local_ip variable is used within the dovecot-sql query to lookup some virtual users by username only + match the local_ip to a table with domain+ip lookup.
- N
Nathan M wrote:
On Thu, Aug 27, 2009 at 12:03 AM, Michael Orlitzky<michael@orlitzky.com> wrote:
Nathan M wrote:
Traditionally this server has only accepted plaintext authentications; however, we want to change that and enable TLS/SSL. The challenge is the server has hundreds of IP addresses it binds to to listen on ports 110/143. It may be 3am, but I'm pretty sure that this is the part of your setup that doesn't make sense. Why does your POP/IMAP server need to be accessed via so many addresses?
Because everybody wants to check email at mail.$theirdomain.com.
But that can be a CNAME for mail.$yourdomain.com, which resolves to one address.
Also, some users "need" to check email with username only, so the local_ip variable is used within the dovecot-sql query to lookup some virtual users by username only + match the local_ip to a table with domain+ip lookup.
Ok, you got me. How many users need that ability? Would anyone notice if you killed them?
I started writing a long and involved migration plan to work around this requirement, but honestly, "wait for v2.0" is probably a better one.
On Thu, Aug 27, 2009 at 8:55 AM, Michael Orlitzky<michael@orlitzky.com> wrote:
Also, some users "need" to check email with username only, so the local_ip variable is used within the dovecot-sql query to lookup some virtual users by username only + match the local_ip to a table with domain+ip lookup.
Ok, you got me. How many users need that ability? Would anyone notice if you killed them?
I started writing a long and involved migration plan to work around this requirement, but honestly, "wait for v2.0" is probably a better one.
We "assimilate" a lot of existing hosting customers, and in order to successfully transfer a domain from X server to our server, if they were logging in previously with username only, we try to accommodate that and not require all the users to change their settings (it's a customer service thing I guess). Because dovecot supports a very flexible SQL lookup function, it's easy to do by assigning the domain in particular a static IP and pointing mail.$domain at the static IP.
On any given server, it could be between 200 and 2000 email accounts which are logging in with username only. So, really the "need" is ours to not have to have all those accounts change their settings in order to use our servers.
I think I'm OK providing SSL only for now, and offering TLS once 2.0 is stable as a solution. It's still better than plaintext. =)
- N
On Wed, 2009-08-26 at 18:27 -0700, Nathan M wrote:
- Ideal scenario. A config option which tells TLS to only respond on certain IPs. In our case if a connection attempts to initiate TLS on any IP address except 10.0.0.2, it would respond with no TLS support. This would be ideal as we could continue running just a single dovecot instance.
Dovecot v2.0 supports this. I'm hoping to get the first alpha version out in a month or two.
On Thu, Aug 27, 2009 at 6:54 AM, Timo Sirainen<tss@iki.fi> wrote:
On Wed, 2009-08-26 at 18:27 -0700, Nathan M wrote:
- Ideal scenario. A config option which tells TLS to only respond on certain IPs. In our case if a connection attempts to initiate TLS on any IP address except 10.0.0.2, it would respond with no TLS support. This would be ideal as we could continue running just a single dovecot instance.
Dovecot v2.0 supports this. I'm hoping to get the first alpha version out in a month or two.
Timo, that's terrific to hear!! I think we'll just support SSL only for now, and when 2.0 is stable we can offer SSL+TLS. Thanks for the absolutely incredible software.
- N
participants (4)
-
Jase Thew
-
Michael Orlitzky
-
Nathan M
-
Timo Sirainen