<<Reiterate original post in new thread>>
In my config, I forward deliveries to Dovecot over LMTPS. The machine
(there is just one for now) forwarding the mail has a certificate from a
well known and trusted CA. How can I configure Dovecot to accept mail
deliveries from that one machine?
Currently I have:
protocol lmtp{ login_trusted_networks = 192.168.x.y
0011:2233:4455:6677:8899:aabb:ccdd:eeff auth_ssl_require_client_cert =
yes ssl_verify_client_cert = yes ssl_ca = (a private - single purpose
CA) ...
The IP addresses are the addresses of the LMTPS client machine.
I have a created a CA for the sole purpose of signing the certificate of
the LMTPS client. I regard this as a horrible horrible kludge.
I would like to be able to set ssl_ca to the root certificate of the
public trusted CA but can't work out how to get Dovecot to check the
name on the certificate.
<<End original post>>
On 17/05/2023 12:13 am, Jochen Bern wrote:
On 16.05.23 14:27, Sean Gallagher wrote:
I have a created a CA for the sole purpose of signing the certificate
of the LMTPS client. I regard this as a horrible horrible kludge.
... how do you figure that? *Someone*, and that means you, has to
specify which clients are allowed to connect. Which leaves three
possibilities:
a) You run the CA and thus, the CA can do the selection for you. Which
means that in order to deal with a single-permissible-client
situation, you need the CA to issue client certs to just that
one entity.
b) The CA does *not* and issues (client) certs to entities you do *not*
want to grant access. Then the selection job remains yours and,
assuming that requiring a client cert from that CA makes any sense in
the first place, auth_ssl_username_from_cert is there to help you (by
making sure that the username will be "the ID" from the cert so that
you can base some additional filtering on that).
c) The CA is willing to enrich the certs it issues with DN parts, X509v3
extensions or the like signalling access rights as granted beforehand
by a *fourth* party, as in, you. Which is a terrible can of worms as
soon as things, especially the number of such fourth parties to
support by the same CA, start to scale up IMHO. Which promptly brings
us back to you running the CA yourself ...
We can start by ruling out possibility "c". If there was code in Dovecot
to check esoteric X509v3 extensions, then surely there could be code to
check the certificate name. There are obviously many other problems with
getting third party CA's to do anything special for one client but
exploring that won't add to this discussion.
Of the other two options, I currently have "a" but would prefer to have
"b" - if it can be implemented securely.
Before going into reasons, I would like to make an assertion that guides
my thinking on this: Complexity is the enemy of security. Complexity
implies large attack surfaces. It implies more code that is harder to
debug. It implies fewer people willing and able to understand it and
therefore, a more complex solution to any given problem is more likely
to have vulnerabilities. Case in point: CVE-2019-3814. That said, any
two people may weight "complexity" differently and so there is still
room for personal preference.
possibility "a" has the advantage of a trivially simple security
analysis. If the server requires a certificate from a specific CA, and
that CA has only ever signed one certificate, you don't need to read the
certificate to know what it says. The disadvantage of "a" is that it is
not how PKI is understood to work. In fact it is Pre-Shared-Keys,
dressed up as PKI. Maintaining different CA's for each service requires
ongoing knowledge and effort. This is complexity that is best avoided.
If systems are configured to work the "normal" way, they are more easily
understood and maintained securely.
possibility "b" has the advantage of being immediately recognizable to
anyone familiar with PKI. However it is not obvious that it will even
work on Dovecot. as pointed out the "auth_ssl_username_from_cert" is
generally used in Dovecot to do certificate based client authentication.
This authentication happens in the "-login" process associated with each
service, however the LMTP server does not have a login process and does
not require explicit authentication. My current config accepts
deliveries from Postfix. Postfix does not issue the AUTH command and
deliveries proceed as expected. It is not obvious the this setting has
any effect on the LMTP server. Even if we DID set the USERNAME to the
certificate name, we still need to validate it somehow.
Perhaps I am missing some key piece of the puzzle, in which case please
correct me, but it seems Dovecot is deficient in the authentication of
LMTP client certificates. It continues to surprise me that this is not
given a higher priority.
Sean.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
