Re: [mailop] self-signed cert for inbound TLS

2017-07-31 Thread Luis E. Muñoz 



On 31 Jul 2017, at 19:55, John Levine wrote:


Other than the usual horrible problems getting certs installed and
configured, it's a great way to do client authentication.


+1

Specially when you manage your own CA and can issue your own certs to 
the clients at onboarding.


-lem
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-31 Thread John Levine 
In article  
you write:
>If someone connects to you, they don't send you a cert unless you're
>dealing with client certs, and I don't think
>DANE covers that at all, though I haven't read through it completely.

The client can present a cert in the TLS handshake if it wants to.
Few do and equally few servers check them, but somewhere I have
patches for qmail that verify submission clients by the cert they
send.

Other than the usual horrible problems getting certs installed and
configured, it's a great way to do client authentication.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-29 Thread Grant Taylor via mailop 
On 07/28/2017 03:19 PM, Brandon Long via mailop wrote:
> If someone connects to you, they don't send you a cert unless you're 
> dealing with client certs, and I don't think DANE covers that at all, 
> though I haven't read through it completely.

It's my understanding that DANE covers client certs for S/MIME.  So I'd
be surprised if that technique can't be (re)used for TLS client certs as
well.



-- 
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

2017-07-28 Thread Brandon Long via mailop 
That's a good point.

The number is only for encrypted, not authenticated and it looks like we
don't currently log verification.
We do CA verification and a GSuite domain can choose to require it for a
connection, but we don't use the
information generally.  Presumably when we finish our STS and DANE work, it
will come into play more.

Brandon

On Fri, Jul 28, 2017 at 2:32 PM, Michael Orlitzky 
wrote:

> On 07/28/2017 05:19 PM, Brandon Long wrote:
> >
> > We're hovering at 88% encrypted, inbound & outbound, if those in charge
> > decided to move the needle, they could
> > probably start a path along the likes of what Chrome is doing
> > (https://security.googleblog.com/2016/09/moving-towards-
> more-secure-web.html).
> >
> > I'm sure that 12% is hiding a lot of small servers, but if they wanted
> > to learn who's encrypted and enforce that they stay
> > that way, it wouldn't be too hard.
> >
>
> Is that 88% encrypted channel, or 88% that are encrypted and
> authenticated using your system's CA bundle?
>
> The former is easy and that's why it's what we all do. If it's the
> latter, well then I learned something today.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-28 Thread Michael Orlitzky 
On 07/28/2017 05:19 PM, Brandon Long wrote:
> 
> We're hovering at 88% encrypted, inbound & outbound, if those in charge
> decided to move the needle, they could 
> probably start a path along the likes of what Chrome is doing 
> (https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html).
> 
> I'm sure that 12% is hiding a lot of small servers, but if they wanted
> to learn who's encrypted and enforce that they stay
> that way, it wouldn't be too hard.
> 

Is that 88% encrypted channel, or 88% that are encrypted and
authenticated using your system's CA bundle?

The former is easy and that's why it's what we all do. If it's the
latter, well then I learned something today.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-28 Thread Brandon Long via mailop 
On Fri, Jul 28, 2017 at 5:58 AM, Michael Orlitzky 
wrote:

> On 07/27/2017 01:44 PM, Dave Warren wrote:
> >>
> >> "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.
> >
>
> The practical reason is that unencrypted SMTP has to work if you want to
> be able to communicate with the world. So, adding a second more-secure
> channel *in addition to* the existing unsecured channel doesn't really
> gain you anything. If someone connects to me and I don't like his CA, he
> can fall back to plain text and I have to allow it (because of the
> bajillions of people who don't do TLS over SMTP at all).
>

If someone connects to you, they don't send you a cert unless you're
dealing with client certs, and I don't think
DANE covers that at all, though I haven't read through it completely.

And you don't have to accept it over plain text.  You could learn that most
connections from foo.com are encrypted and
choose to reject unencrypted ones, for example.

Doing TLS but without a trust chain is a nice compromise that lets us
> encrypt the channel opportunistically, and doesn't discourage the
> participants who would otherwise be put off by the trust chain issues.
>
> This differs from e.g. HTTP in that a website can unilaterally make a
> decision to go HTTPS-only and be fine, but your mail server can't
> unilaterally decide that it will only accept mail from people with a
> certificate that you approve of.


Yes, actually, you can.  It depends on what your users want, of course, and
it's probably rare
for any email service to do that yet, but that doesn't make it impossible.

We're hovering at 88% encrypted, inbound & outbound, if those in charge
decided to move the needle, they could
probably start a path along the likes of what Chrome is doing
(https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
).

I'm sure that 12% is hiding a lot of small servers, but if they wanted to
learn who's encrypted and enforce that they stay
that way, it wouldn't be too hard.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-28 Thread Grant Taylor via mailop 

On 07/28/2017 02:10 AM, Vittorio Bertola wrote:
On the Web, instead, users do want to know which company is actually 
running the website that they are visiting, and not just that they are 
really connecting to that hostname, so CAs offer additional value in 
respect to DANE.


Full STOP!

I disagree that CAs can offer what I think you are ascribing to them.

I agree that end users probably do want to believe that paypal.com is 
truly PayPal.  I also agree that the CA ecosystem that we have does in 
fact do that.  I.e. Extended Validation certificates.


certs.>


I do not believe that our current CA ecosystem prevents a different 
entity (in a different language / culture / etc) from running a site as 
PaypALL.com, having fully validated themselves as a legitimate business 
entity.


Sadly, these two domain names, paypal.com and paypall.com, are 
effectively homonyms of each other, and can be relatively easily be 
confused by end users.


Think of this like the two different businesses below:

AirPower (Engines)
10 Example Drive
New York NY

AirPower (Paint Sprayers)
10 Example Street
New York NY

I feel like there is extreme potential for confusion of "street" vs 
"drive" and that packages will inevitably go to the wrong business.


Which business has more authority to claim the name / address?

What if the businesses owners are from different cultures / languages / etc?

Can anyone really say with any authority that either of them should not 
be allowed to use the name / address / URL?


I am firmly of the opinion that the existing CA ecosystem can say that 
each business is indeed who they claim to be, at they address they sate. 
 -  However this does not extend to saying that they are NOT elsewhere.


I believe that humans want this, but that this can not be done the way 
things are done today.


(This also screams of some of the ongoing discussions with Let's Encrypt 
offering DV certificates, which only validate the hostname that you're 
connecting to, not who runs them.)


I feel like we are evolving into a new era where we are no longer 
satisfied with just saying that something is encrypted ~> secure.  We 
now want new information that speaks to "who" something is and is not. 
This is a new question that we need to answer, and the industry will 
need to adjust, or educate end users.




--
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

2017-07-28 Thread John Levine 
In article <808816365.710.1501249729...@appsuite.open-xchange.com> you write:
>> The practical reason is that unencrypted SMTP has to work if you want to
>> be able to communicate with the world. ...

>This, by the way, is another advantage of DANE. By publishing a TLSA record 
>for the server's
>certificate, the operator does not just provide a chain of trust (anchored 
>into the DNS root) to
>validate the certificate at connection, but it also signals that it requires 
>encryption. This allows
>any sender to know that, if it cannot validate the certificate and establish a 
>trusted encryption
>connection, it should not fall back to cleartext, but rather throttle or 
>bounce the message. 

Sounds like an excellent way to be sure you don't get the mail you want.

R's,
John

PS: My MTAs have LE certs that match the MTA names, but I have no
plans to validate anyone else's MTA certs anytime soone.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-28 Thread Grant Taylor via mailop 

On 07/28/2017 06:58 AM, Michael Orlitzky wrote:

If someone connects to me and I don't like his CA, he
can fall back to plain text and I have to allow it (because of the
bajillions of people who don't do TLS over SMTP at all).


I disagree.  You do have the choice to not accept messages over an 
unsecured channel.  The SMTP protocol easily accommodates this.


The question is do you want to / will your business allow you to not 
accept unencrypted messages.




--
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

2017-07-28 Thread Vittorio Bertola 

> Il 28 luglio 2017 alle 14.58 Michael Orlitzky ha scritto:
> 
> The practical reason is that unencrypted SMTP has to work if you want to
> be able to communicate with the world. So, adding a second more-secure
> channel *in addition to* the existing unsecured channel doesn't really
> gain you anything. If someone connects to me and I don't like his CA, he
> can fall back to plain text and I have to allow it (because of the
> bajillions of people who don't do TLS over SMTP at all).
> 

This, by the way, is another advantage of DANE. By publishing a TLSA record for 
the server's certificate, the operator does not just provide a chain of trust 
(anchored into the DNS root) to validate the certificate at connection, but it 
also signals that it requires encryption. This allows any sender to know that, 
if it cannot validate the certificate and establish a trusted encryption 
connection, it should not fall back to cleartext, but rather throttle or bounce 
the message. So this allows backwards compatibility with the opportunistic 
encryption model for those destinations that do not use DANE, but at the same 
time allows modern recipients to tell senders that any request to downgrade 
their connection to cleartext should be interpreted as a potential MITM attack 
and rejected.

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] self-signed cert for inbound TLS

2017-07-28 Thread Michael Orlitzky 
On 07/27/2017 01:44 PM, Dave Warren wrote:
>>
>> "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.
> 

The practical reason is that unencrypted SMTP has to work if you want to
be able to communicate with the world. So, adding a second more-secure
channel *in addition to* the existing unsecured channel doesn't really
gain you anything. If someone connects to me and I don't like his CA, he
can fall back to plain text and I have to allow it (because of the
bajillions of people who don't do TLS over SMTP at all).

Doing TLS but without a trust chain is a nice compromise that lets us
encrypt the channel opportunistically, and doesn't discourage the
participants who would otherwise be put off by the trust chain issues.

This differs from e.g. HTTP in that a website can unilaterally make a
decision to go HTTPS-only and be fine, but your mail server can't
unilaterally decide that it will only accept mail from people with a
certificate that you approve of.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-28 Thread Vittorio Bertola 

> Il 27 luglio 2017 alle 23.48 Brandon Long via mailop  ha 
> scritto:
> 
> 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.
> 

Can I ask which ones? I thought it was mostly because HTTPS is much older than 
DANE.

At the same time, however, I do find the arguments in RFC 7672 reasonable: for 
an automated, non-interactive, high volume application, having a method that 
removes any need for real time management of exceptions by a user/administrator 
is paramount.

Also, there is an important difference that RFC 7672 does not mention: in 
email, your task is to deliver the message to the domain name contained in the 
destination address. No assumption is made by the email service on the real 
world identity of the address owner or of the owner of his email domain, and 
there would be no one to show this information to anyway, so the additional 
value of CAs - verifying identities in the real world - is almost useless; on 
the other hand, an automated system that verifies that the server establishing 
the connection really belongs to that domain name is spot on. On the Web, 
instead, users do want to know which company is actually running the website 
that they are visiting, and not just that they are really connecting to that 
hostname, so CAs offer additional value in respect to DANE.

However, I also think that the point about the inherent weaknesses of the 
security of the CA model is valid. We have seen so many failures and security 
breaches, and if you couple them with the fact that a single broken CA is 
enough to break security for everyone everywhere, IMHO finding a different 
system whenever the "real world validation" part is not particularly necessary 
is a good plan.

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] self-signed cert for inbound TLS

2017-07-27 Thread Brandon Long via mailop 
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

2017-07-27 Thread Brandon Long via mailop 
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

2017-07-27 Thread Phil Pennock 
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

2017-07-27 Thread Grant Taylor via mailop 

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

2017-07-27 Thread Dave Warren 
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

2017-07-27 Thread Vittorio Bertola 

> 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] self-signed cert for inbound TLS

2017-07-26 Thread Eric Tykwinski 

> On Jul 26, 2017, at 5:42 PM, Steve Atkins  wrote:
> 
> It doesn't _really_ matter in the context of deciding whether a certificate
> is being presented by a legitimate domain owner or a MitM.

Well I think that’s the whole solution of DANE, ie validate through DNSSCEC 
that the owner of the domain is the owner.
Obviously the DNS chain could be compromised, but at some point we have to let 
birds fly.

> A domain-validated certificate doesn't stop being domain-validated
> the day it's dodgy CA is removed from the approved list.

But that is the point of anyone removing the CA from authoritative chains, or 
intermediates.
Quick google search and GlobalSign comes up, sorry guys: 
https://www.theregister.co.uk/2016/10/13/globalsigned_off/ 


> It's relationship to the domain continues to be about as trustworthy
> as it was before the CA was smacked down, and still more so
> than anything self-signed or created using a private CA.

Trust me, if you ask the CAs, if you get “smacked” down, it’s probably all 
hands on deck.
Having a self signed cert, you the domain owner know what you are getting into.

> Cheers,
>  Steve

I think the major argument would be with corporate as they don’t care about 
random joe, but then do they than care about DNSSEC to actually publish 
records.  It’s sort of like the same catch 22 that DANE was supposed to fix.  I 
personally think of it like DEMARC, it’s that extra bit of time that spammers 
sure are not going to go through, but possible.  So security wise, it’s 
basically the same, we know mail.example.com  sent an 
email, it’s either DNS validated through DNSSEC, or some CA did it’s magic.  

The major problem apparently is that most solutions don’t check CA certificate 
paths, so at least DANE does something.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Steve Atkins 

> On Jul 26, 2017, at 1:43 PM, valdis.kletni...@vt.edu wrote:
> 
> On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
>> 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.
> 
> Quick: What two CAs did Google just remove from Chrome's list?
> 
> Has your OS vendor followed suit?  And what percent of your OS vendor's 
> installs
> are prompt in applying patches?

It doesn't _really_ matter in the context of deciding whether a certificate
is being presented by a legitimate domain owner or a MitM.

A domain-validated certificate doesn't stop being domain-validated
the day it's dodgy CA is removed from the approved list.

It's relationship to the domain continues to be about as trustworthy
as it was before the CA was smacked down, and still more so
than anything self-signed or created using a private CA.

Cheers,
  Steve



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Brandon Long via mailop 
If it becomes important, I'm sure it can be done.

I mean, you all update your av signatures at least daily, or your spam
rules.

And whether they would need to follow the browser list or whatever isn't
clear, sure.

It's early in this stuff for email, maybe DANE will be the solution that
catches on for smtp, and CA verified won't be the common choice.

Brandon

On Jul 26, 2017 1:55 PM, "Kevin A. McGrail"  wrote:

> On 7/26/2017 4:43 PM, valdis.kletni...@vt.edu wrote:
>
>> Quick: What two CAs did Google just remove from Chrome's list?
>>
> Not to mention the Chrome v Symantec issue that's about to cause the 2nd
> coming...
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread valdis . kletnieks 
On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
> 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.

Quick: What two CAs did Google just remove from Chrome's list?

Has your OS vendor followed suit?  And what percent of your OS vendor's installs
are prompt in applying patches?


pgpwnCPJNDv7D.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Luis E. Muñoz 

I think the key part is not "expect", but actually don't require it.

-lem

On 26 Jul 2017, at 10:10, Brandon Long via mailop wrote:

> 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.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Brandon Long via mailop 
On Wed, Jul 26, 2017 at 1:23 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

>
> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
>
>
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
>
> To protect against passive Man-in-the-Middle, there is no actual
> difference between the self-signed certificate and certificate from
> recognized CA, so, except may be very few unsignificant implementors,
> all peers accept self-signed certificates for STARTTLS (unless DANE or
> SMTP STS are used).
>
>
> I agree that this matches historical norms. I suspect that DANE and /
> or SMTP STS are going to be changing this.
>
> If you use DANE, whether the certificate is self-signed or signed by a CA
> does not make any significant difference; your trust derives from a secure
> DNS query that verifies that the certificate you show is actually the same
> that is pinned in appropriate DNS records for your hostname. Actually,
> using a self-signed certificate may make DANE deployment easier. Also, SMTP
> software (differently from browsers) cannot be expected to maintain a list
> of trusted certification authorities, so there is no advantage in using a
> CA-signed certificate. You can refer to RFC 7672 for further details on the
> topic.
>
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.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Vittorio Bertola 

> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
> 
> 
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
> 
> > > To protect against passive Man-in-the-Middle, there is no actual
> > difference between the self-signed certificate and certificate from
> > recognized CA, so, except may be very few unsignificant 
> > implementors,
> > all peers accept self-signed certificates for STARTTLS (unless DANE 
> > or
> > SMTP STS are used).
> > 
> > > I agree that this matches historical norms. I suspect that DANE 
> > and /
> or SMTP STS are going to be changing this.
> 

If you use DANE, whether the certificate is self-signed or signed by a CA does 
not make any significant difference; your trust derives from a secure DNS query 
that verifies that the certificate you show is actually the same that is pinned 
in appropriate DNS records for your hostname. Actually, using a self-signed 
certificate may make DANE deployment easier. Also, SMTP software (differently 
from browsers) cannot be expected to maintain a list of trusted certification 
authorities, so there is no advantage in using a CA-signed certificate. You can 
refer to RFC 7672 for further details on the topic.

(SMTP-STS is mainly a short term workaround while DNSSEC is being deployed, so, 
if you can, you should go for DANE instead.)

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] self-signed cert for inbound TLS

2017-07-25 Thread Eric Tykwinski 

> On Jul 25, 2017, at 7:46 PM, Brandon Long via mailop  
> wrote:
> 
> Agreed that STS and DANE are the solution for enforcing, however it's still 
> early days for those.
> 
> Brandon 

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.

Eric

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-25 Thread Brandon Long via mailop 
On Tue, Jul 25, 2017 at 4:13 PM, Ted Cabeen 
wrote:

> On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:
>
>> STARTTLS is opportunistic and doesn't protect against active
>> Man-in-the-Middle. In case of TLS problems it falls back to plain text.
>>
>
> Interestingly, that's not always the case now.  We typoed the cert on one
> of our list servers earlier this year, and discovered that Google outbound
> SMTP will not downgrade from TLS to plain text.  If you offer STARTTLS and
> then break the handshake, they bounce the mail.  I presume that it's a
> protection against downgrade attacks, but that's just a guess.


This has been the case for Google for more than three years.  Which doesn't
mean that MITM can't happen, just that if it does, it should be more
obvious, both from our transparency report, etc.

Agreed that STS and DANE are the solution for enforcing, however it's still
early days for those.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-25 Thread Ted Cabeen 

On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:

STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.


Interestingly, that's not always the case now.  We typoed the cert on 
one of our list servers earlier this year, and discovered that Google 
outbound SMTP will not downgrade from TLS to plain text.  If you offer 
STARTTLS and then break the handshake, they bounce the mail.  I presume 
that it's a protection against downgrade attacks, but that's just a guess.


--Ted

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-25 Thread Grant Taylor via mailop 

On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
STARTTLS is opportunistic and doesn't protect against active 
Man-in-the-Middle. In case of TLS problems it falls back to plain text.


STARTTLS is opportunistic, but MTAs can be configured to require 
protected channels and to refuse email over unprotected channels.


SMTPS (now defunct?) avoids this, but is (was?) non-standard.

To protect against passive Man-in-the-Middle, there is no actual 
difference between the self-signed certificate and certificate from 
recognized CA, so, except may be very few unsignificant implementors, 
all peers accept self-signed certificates for STARTTLS (unless DANE or 
SMTP STS are used).


I agree that this matches historical norms.  I suspect that DANE and / 
or SMTP STS are going to be changing this.


I have also had problems with some MTAs (at least Thunderbird) 
complaining if the STARTTLS cert doesn't match the hostname it connects 
to.  (SAN is sufficient.)  -  Though I don't know that this applies to 
your use case.


Also, why not send bounces back to a different server and avoid needing 
to expose SMTP to the world?




--
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

2017-07-25 Thread Vick Khera 
I've not had any issues with self signed certs with TLS on SMTP. That said,
lately I've been using Lets Encrypt certificates with the certbot program
to manage them, and that has worked really well. The initial setup takes a
little effort to do a DNS based verification since the mail hosts are not
running HTTP servers to do the automatic verification. Renewals are
automatic, though.


On Tue, Jul 25, 2017 at 10:51 AM, Jonathan Leist  wrote:

> Hello,
>
> We're looking to implement inbound TLS on machines that are only used to
> send mail and receive bounces, and I was wondering if anyone has
> encountered problems using a self-signed cert for that purpose. It seems
> like it would be easier to implement on a larger scale than would CA-signed
> certs—and using the self-signed cert worked fine in tests—but we also
> obviously don't want to do anything that would prevent us from receiving
> bounces.
>
> Thanks for your time.
>
> --
> Jonathan
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-25 Thread Vladimir Dubrovin via mailop 

STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.

To protect against passive Man-in-the-Middle, there is no actual
difference between the self-signed certificate and certificate from
recognized CA, so, except may be very few unsignificant implementors,
all peers accept self-signed certificates for STARTTLS (unless DANE or
SMTP STS are used).



25.07.2017 17:51, Jonathan Leist пишет:
> Hello,
>
> We're looking to implement inbound TLS on machines that are only used
> to send mail and receive bounces, and I was wondering if anyone has
> encountered problems using a self-signed cert for that purpose. It
> seems like it would be easier to implement on a larger scale than
> would CA-signed certs—and using the self-signed cert worked fine in
> tests—but we also obviously don't want to do anything that would
> prevent us from receiving bounces. 
>
> Thanks for your time. 
>
> --
> Jonathan
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] self-signed cert for inbound TLS

2017-07-25 Thread Jonathan Leist 
Hello,

We're looking to implement inbound TLS on machines that are only used to
send mail and receive bounces, and I was wondering if anyone has
encountered problems using a self-signed cert for that purpose. It seems
like it would be easier to implement on a larger scale than would CA-signed
certs—and using the self-signed cert worked fine in tests—but we also
obviously don't want to do anything that would prevent us from receiving
bounces.

Thanks for your time.

--
Jonathan
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop