On Thu, Jul 27, 2017, at 09:05, Vittorio Bertola wrote: >
>> Il 26 luglio 2017 alle 19.10 Brandon Long <bl...@google.com> ha scritto:>> >> Why can't smtp software being expected to maintain a list of trusted CAs? >> Or at least run on an OS that is expected to do so.> There is a standard >> explanation (literally) in RFC 7672, section 1.3, and especially 1.3.4.:> >> "Even if it were generally possible to determine a secure server name, the >> SMTP client would still need to verify that the server's certificate chain >> is issued by a trusted CA (a trust anchor). I've never understood why this is a special challenge in the SMTP world, it's generally a solved problem for HTTPS, XMPP, and various other protocols. User-configured SMTP clients obtain a hostname from the user, using an incorrect hostname doesn't magically work, so adding one more validation test (certificate name matches hostname) doesn't seem onerous. Similarly, MX records with an incorrect hostname already don't work, so why would requiring a consistent mx.our-email-host.example. be used in MX records be a big deal? The STARTTLS command could be extended to allow "STARTTLS hostname" (like HTTPS SNI), where hostname would indicate the requested certificate, allowing multiple certificates to be used without a single certificate listing every possible alternate name. This would accommodate large virtual hosters who want to offer every client their own mail.client-company.example without dedicating IPs to every client. There would definitely be a transition period, and it would make suddenly renaming your SMTP server more of a challenge (at least in so far as maintaining secondary certificates), but these would have been more solvable problems had it been handled as STARTTLS was starting to take off rather than the current state of ignoring mismatching common names and assuming self-signed certificates are good enough (which implicitly means MITM attacks are not defended against). > > MTAs are not interactive applications where a human operator can make a > decision (wisely or otherwise) to selectively disable TLS security policy > when certificate chain verification fails. With no user to "click OK", the > MTA's list of public CA trust anchors would need to be comprehensive in order > to avoid bouncing mail addressed to sites that employ unknown CAs.> On the > other hand, each trusted CA can issue certificates for any domain. If even > one of the configured CAs is compromised or operated by an adversary, it can > subvert TLS security for all destinations. Any set of CAs is simultaneously > both overly inclusive and not inclusive enough." ... So we therefore assume that every attacker has the resources to compromise or become a CA and just don't bother trying. The CA system has it's flaws, but it's still better than "Trust every certificate implicitly". This just seems like a case of "We can't be 100% perfect, so we won't try".
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
