Re: [mailop] self-signed cert for inbound TLS
On Thu, Jul 27, 2017 at 9:05 AM, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > > Il 26 luglio 2017 alle 19.10 Brandon Long 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). 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." > Well, yes, that is the DANE argument in a nutshell. That doesn't mean it's correct, and there are reasons why DANE was not the solution chosen for the browser market. I think because of the historical weakness of SMTP, that we have to upgrade to security, that DANE may be the better solution in this case, but we shouldn't kid ourselves that the problems identified with it in the browser world don't apply also. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] self-signed cert for inbound TLS
On Thu, Jul 27, 2017 at 11:32 AM, Grant Taylor via mailop wrote: > On 07/27/2017 11:44 AM, Dave Warren wrote: > >> 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. >> > > It's my understanding that the problem has to do with the (lack of) people > involved in the transaction. > > Usually, HTTPS / XMPP / etc. have a human in front of the client that can > make (presumably) intelligent decisions. > > Sure, humans can make (presumably) intelligent decisions between the MUA > and their configured MTA. However, said configured MTA doesn't have a > human to make a (presumably) intelligent decision when the receiving MTA > uses a self signed (or otherwise untrusted) cert. > > There is no human in the MTA-to-MTA exchange to "click ok" or "add > exception" to the SSL / TLS certificate issue. Humans make terrible security decisions, which is why browsers are moving to making it harder or impossible to click through certificate issues. A human can't be expected to know that a self-signed certificate is the same one that was presented by the host for the last N days. Yes, if there are failures, you'd have to have monitoring for them, and bounces back to the senders on failures would often cause confusion and have to be escalated to admins who can make choices. People always make the decision to reach their goal, they will virtually always click through any dialogue to do so. In the argument about CAs and such, the real answer is that consistency of what's presented is probably the more useful signal, whether its the same cert that you always see, or the same CA is signing the cert, and then publishing what you see to something like the certificate transparency. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] self-signed cert for inbound TLS
On 2017-07-25 at 22:10 -0400, Eric Tykwinski wrote: > Sorry, probably straying from the topic, but does anyone know any good SMTP > tests for DANE. > I’m using https://dane.sys4.de/ currently and it works, but I would like > something with some more details if possible. Self-pimping: https://go.pennock.tech/smtpdane/ Golang tooling, stand-alone binary. I invoke from cron as part of monitoring, something along the lines of: smtpdane -nagios -expect-ocsp -mx spodhuis.org Nagios-compatible exit status and output enabled; error if OCSP missing; look up MX records for the arguments (domains, not hostnames) and check them all. See the README.md for more details. Requires Golang 1.8+ for hooking into the TLS APIs properly. % mkdir ~/go % go get go.pennock.tech/smtpdane (or see more mind-numbing detail in the aforementioned readme file). ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] self-signed cert for inbound TLS
On 07/27/2017 11:44 AM, Dave Warren wrote: 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. It's my understanding that the problem has to do with the (lack of) people involved in the transaction. Usually, HTTPS / XMPP / etc. have a human in front of the client that can make (presumably) intelligent decisions. Sure, humans can make (presumably) intelligent decisions between the MUA and their configured MTA. However, said configured MTA doesn't have a human to make a (presumably) intelligent decision when the receiving MTA uses a self signed (or otherwise untrusted) cert. There is no human in the MTA-to-MTA exchange to "click ok" or "add exception" to the SSL / TLS certificate issue. 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. I believe recent versions of Thunderbird are doing something like this. (I don't remember the exact error I got when setting up a new mail server.) 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? I'm not following your question. Are you asking about using a naming standard for MXs? Or are you asking about making sure that the MX hostname is either the CN and / or (one of) the SAN(s)? 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. If we're talking about names matching, shouldn't we also be checking the EHLO name? If so, it's too late to use SNI when using STARTTLS . -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] self-signed cert for inbound TLS
On Thu, Jul 27, 2017, at 09:05, Vittorio Bertola wrote: > >> Il 26 luglio 2017 alle 19.10 Brandon Long 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
Re: [mailop] self-signed cert for inbound TLS
> Il 26 luglio 2017 alle 19.10 Brandon Long 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). 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." Regards, -- kind regards, Vittorio Bertola Research & Innovation Engineer Cell: +39 348 7015022 Skype: in-skype...@bertola.eu Email: vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein Chairman of the Board: Richard Seibt European Office: Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 Managing Directors: Frank Hoberg, Martin Kauss US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Restricted email address UIDs for public email domains
On Wed, Jul 26, 2017 at 04:22:55PM -0700, Michael wrote: > You might be going too stringent in that case.. I don't think so. This would allow fred.amazon@ and things that meet those kinds of use cases, while disallowing amazon@ and amazon.com@. Note that I don't particularly like this -- years ago, I would have argued against it. But long, bitter experience has changed my mind. ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
