On Thu, May 26, 2016 at 05:44:28PM +0100, Rob Maidment wrote:
> VERIFY verification must have succeeded
Note, this does not check the peer name, it only checks the validity
of the chain.
> VERIFY:bits verification must have succeeded and ${cipher_bits} must
> be greater than or equal bits.
> ENCR:bits ${cipher_bits} must be greater than or equal bits.
Instead of setting cipher bits, Postfix lets you specify the cipher
grade. "high", "medium" and the obsolete "low" or "export". Plus
further exclusions or protocol version constraints.
> CN:name name must match ${cn_subject}
> CN ${server_name} must match ${cn_subject}
> CS:name name must match ${cert_subject}
> CI:name name must match ${cert_issuer}
Note, last time I looked this did not support subjectAltNames in
the certificate. And checking ${server_name} is not secure in
most cases. Postfix checks the nexthop domain or some locally
specified reference identifier.
> These can be enabled when Sendmail is acting as a client or as a
> server. Furthermore, using the routing table it is possible to define
> different settings for different remote hosts (clients or servers).
Postfix has substantially more complete and robust TLS support in
the client that is capable of everything Sendmail can do and much
more.
> Looking at the Postfix configuration pages I can see how the
> smtp_tls_policy_maps option can be used to enable verification of
> remote server certificates When Postfix is the client but there
> doesn't seem to be the same level of control over what verification
> takes place exactly.
The client-side controls are quite comprehensive, see:
http://www.postfix.org/TLS_README.html#client_tls_levels
http://www.postfix.org/TLS_README.html#client_tls_limits
http://www.postfix.org/TLS_README.html#client_tls_policy
> As for verification of client certificates, I can see the relevant
> section in TLS_README but it looks like a global option, i.e. it must
> be enabled for all clients or not at all.
Postfix has:
http://www.postfix.org/postconf.5.html#smtpd_tls_ask_ccert
http://www.postfix.org/postconf.5.html#smtpd_tls_req_ccert
With the latter all clients need certificates, with the former they
are optional, you can then use:
http://www.postfix.org/postconf.5.html#check_ccert_access
to provide greater access to clients that present suitable
certificates. Or you can use a policy service
http://www.postfix.org/SMTPD_POLICY_README.html#protocol
to make decisions based on the relevant client features.
ccert_subject = ... # Empty unless TLS cert present and trusted
ccert_issuer = ... # Empty unless TLS cert present and trusted
ccert_fingerprint = ... # Empty unless TLS cert present
encryption_protocol = ... # Empty unless TLS used
encryption_cipher = ... # Empty unless TLS used
encryption_keysize = ... # Empty unless TLS used
ccert_pubkey_fingerprint = ... # Empty unless TLS used
> 1. Am I correct that the same level of verification control is not
> possible in Postfix (perhaps for good reason) or am I overlooking
> something? If I'm right what steps does Postfix take exactly to
> verify certificates?
Verification control is much more flexible and comprehensive on
the client. On servers it is limited by the asymmetry between
the client and server roles:
http://www.postfix.org/TLS_README.html#client_tls_limits
but see below:
> 2. Is it possible to enable client certification verification for
> some clients and not others?
On Thu, May 26, 2016 at 12:57:02PM -0400, Wietse Venema wrote:
> Fine-grained control over clients is not implemented. Viktor can
> explain why Postfix doesn't go much beyond reject_plaintext_session.
This is a complex topic. A key difficulty is that restricting
access based on client certificates is not always possible, because
clients can then simply omit their certificate to get more access
(the same as everyone without a scarlet letter certificate).
So all you can really do is grant some additional access to clients
with suitable certificates, and for that you have:
http://www.postfix.org/postconf.5.html#check_ccert_access
or the policy service extension mechanism. Keep in mind that almost
nobody has user certificates, and client certificates for hosts
can not be used to "discriminate" against malicious actors, because
they won't present malicious actor certificates.
So the role of client certificates in SMTP is largely limited to
"SSL VPN" functionality. Remote machines can use client certs
instead of (or in combination with) SASL to securely attain the
privileges of trusted internal machines.
Since Verisign, Comodo, ... aren't generally sensible choices for
certifying your own machines to you, the preferred client auth
model is by fingerprint, not by CA notarization. (A client can
get a DV cert by responding to insecure email to admin@domain!)
When you issue submission certs to remote clients, keep track of
their fingerprints, and "revoke" them by removing the entry from
the access table if and when keys are compromised or the client
is no longer trusted.
--
Viktor.
