dovecot - Feb 2016 - Disable Client Certificate Authentication for Unencrypted Connections?

On 02 Feb 2016, at 13:09, Haravikk <dovecot at haravikk.me>
wrote:
> 
> So I still haven?t found a way to require client certificates only for port
993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
> 
> Is there really no way to do this? I just found out how to do the same
thing for postfix (turns out it?s fairly easy, just a matter of adding the
settings in the right parts of master.cf instead of main.cf), allowing me to
restrict client certificate verification to port 587 (I don?t accept port 465)
without interfering with incoming mail server connections on port 25.
If you really want to do it, you could do it something like this (not tested -
probably needs some additions/changes):

# no 993 port for this imap-login
service imap-login {
  inet_listener imaps {
    port = 0
  }
}

# create a duplicate 993 service
service imap-login-ssl {
  executable = imap-login login-ssl
  chroot = login
  user = $default_login_user
  # add other settings similarly as to service imap-login
  inet_listener imaps {
    port = 993
  }
}

# create a separate auth master process for port 993
service auth-ssl {
  executable = auth -o auth_ssl_require_client_cert=yes
  # add other settings similarly as to service auth
  unix_listener login/login-ssl {
    mode = 0666
  }
}

> On 02 Feb 2016, at 14:19, Timo Sirainen <tss at iki.fi> wrote:
> 
> On 02 Feb 2016, at 13:09, Haravikk <dovecot at haravikk.me> wrote:
>> 
>> So I still haven?t found a way to require client certificates only for
port 993/IMAPS while leaving unencrypted IMAP open for local, trusted, services.
>> 
>> Is there really no way to do this? I just found out how to do the same
thing for postfix (turns out it?s fairly easy, just a matter of adding the
settings in the right parts of master.cf instead of main.cf), allowing me to
restrict client certificate verification to port 587 (I don?t accept port 465)
without interfering with incoming mail server connections on port 25.
> 
> If you really want to do it, you could do it something like this (not
tested - probably needs some additions/changes):
Oh, except now you have two auth master processes, so the final userdb lookup
would have to go to the right auth process. This requires the attached patch.
After that you can do:

# no 993 port for this imap-login
service imap-login {
 inet_listener imaps {
   port = 0
 }
}

# create a duplicate 993 service
service imap-login-ssl {
 executable = imap-login -P imap-ssl login-ssl
 chroot = login
 user = $default_login_user
 # add other settings similarly as to service imap-login
 inet_listener imaps {
   port = 993
 }
}

service imap-ssl {
  executable = imap -S auth-master-ssl
  unix_listener login/imap-ssl {
    user = $default_login_user
  }
}

# create a separate auth master process for port 993
service auth-ssl {
 executable = auth -o auth_ssl_require_client_cert=yes
 # add other settings similarly as to service auth
 unix_listener login/login-ssl {
   mode = 0666
 }
 unix_listener auth-master-ssl {
 }
}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi-auth-master.diff
Type: application/octet-stream
Size: 2961 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20160202/11396b16/attachment.obj>

That definitely seems promising! Though I?m a little uncomfortable about having
to apply a patch to make it work.

However it?s got me curious; could I do something similar by defining a second
IMAP protocol? Since the protocol !smtp option can enable client certificates
for only some protocols, it seems like if I could copy (or symlink) the IMAP
protocol into a second IMAPS protocol then I could possibly create the exception
using protocol !imap !smtp, could something like that work? Of course I don?t
know enough about how dovecot?s protocol modularity works, so I?m not sure what
this would involve exactly, but if it could avoid the need for patching it might
be a nice way to achieve the same goal.
> On 2 Feb 2016, at 12:44, Timo Sirainen <tss at iki.fi> wrote:
> 
> 
>> On 02 Feb 2016, at 14:19, Timo Sirainen <tss at iki.fi> wrote:
>> 
>> On 02 Feb 2016, at 13:09, Haravikk <dovecot at haravikk.me>
wrote:
>>> 
>>> So I still haven?t found a way to require client certificates only
for port 993/IMAPS while leaving unencrypted IMAP open for local, trusted,
services.
>>> 
>>> Is there really no way to do this? I just found out how to do the
same thing for postfix (turns out it?s fairly easy, just a matter of adding the
settings in the right parts of master.cf instead of main.cf), allowing me to
restrict client certificate verification to port 587 (I don?t accept port 465)
without interfering with incoming mail server connections on port 25.
>> 
>> If you really want to do it, you could do it something like this (not
tested - probably needs some additions/changes):
> 
> Oh, except now you have two auth master processes, so the final userdb
lookup would have to go to the right auth process. This requires the attached
patch. After that you can do:
> 
> # no 993 port for this imap-login
> service imap-login {
> inet_listener imaps {
>   port = 0
> }
> }
> 
> # create a duplicate 993 service
> service imap-login-ssl {
> executable = imap-login -P imap-ssl login-ssl
> chroot = login
> user = $default_login_user
> # add other settings similarly as to service imap-login
> inet_listener imaps {
>   port = 993
> }
> }
> 
> service imap-ssl {
>  executable = imap -S auth-master-ssl
>  unix_listener login/imap-ssl {
>    user = $default_login_user
>  }
> }
> 
> # create a separate auth master process for port 993
> service auth-ssl {
> executable = auth -o auth_ssl_require_client_cert=yes
> # add other settings similarly as to service auth
> unix_listener login/login-ssl {
>   mode = 0666
> }
> unix_listener auth-master-ssl {
> }
> }
> 
> <multi-auth-master.diff>