On Fri, 11 Jul 2014 12:53:36 -0400 (EDT) wie...@porcupine.org (Wietse Venema) wrote:
>BlueStar88: >> for quite some while. I can see successful chain walks on inbound >> connections resulting in "Trusted TLS connection established from". > >"Trusted" verifies the CA chain, not the client DNS name. Just half the way, but better than no checks at all. But I can't make any domain or host specific use of it yet. >With HTTP clients, the certificate name check confirms that the >client has a TLS connection to the server with a specific DNS name. > >An SMTP server rarely needs confirmation that it has a TLS connection >from a client with a specific DNS name. This is so rare that it is >not implemented in Postfix. It is a difference to talk about MUA-MTA or MTA-MTA connections (client-server role or server-server role). It's quite easy for MTAs, to have proper client certificates, to show perfect host integrity to other MTAs. Maybe it is time to make progress into that direction. Especially since most of the large email providers serve client certificates with correct CN to FQDN match on MTA-MTA connections already. >Instead, we recommend that the server looks whether the client >certificate is issued by a trusted CA (permit_tls_clientcerts), or >whether the certificate or public key has a particular fingerprint >(check_ccert_access). I'd like to do CA chain walk by domain or host, but "check_ccert_access" does only allow fingerprint pinning. "permit_tls_clientcerts" does work only for all TLS based connections together. That does only makes sense on special intranet hosts (MTA-MTA and where you're in control of all nodes) or SMTP hosts (MUA-MTA as client/user authentication for making a PERMIT decision). Is there a way to have a host/domain specific chain walk decision, like in "smtp_tls_policy_maps"? For example: Let Google's MTA proceed on an inbound connection only if a previous chain walk was successful. If, at some time, a MITM breaks the chain walk, the connections must be rejected. I think that is not possible yet and that is the thing, which is quite stupid. >> I think the server checks, if the peer hostname fits the CN. > >It does not. It should. Since strictness to a given security level is a) a decision of each MX node itself and b) must cover both directions in my opinion. Having only inbound connections covered, is a weak point of relying on security levels at all. You see, I can't tell Google, to proceed in my direction only if my certificate chain was walked by them successfully. It's a sort of chicken-egg problem. To solve this and if we really want to harden public MTA-MTA links, we should allow Postfix operators to set a better security level (Verify or DANE for example) on well known links independently. That means both directions without any cooperation of the remote node. > Wietse BlueStar88
signature.asc
Description: PGP signature
