Re: [mailop] TLS verify=FAIL

[Franck Martin via mailop]

Client certificates in emails are not rare, even to the contrary, they are
predominant. The proportion of verifiable client certificates is about the
same proportion of verifiable server certificates.

I think there are a few MTAs that have different config for certificate
presented as a client vs a receiver.

For instance postfix has a different config and says not to use client
certs, I tend to disagree. This advice may have been written in the early
days of STARTTLS. The world has changed, especially after Snowden.

http://www.postfix.org/TLS_README.html#client_cert_key

On Thu, Apr 14, 2016 at 8:23 AM, Al Iverson 
wrote:

> Thanks for that. :)
>
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
>
>
> On Thu, Apr 14, 2016 at 3:02 AM, Steve Freegard 
> wrote:
> >
> > On 14/04/16 00:58, Al Iverson via mailop.org wrote:
> >>
> >> Boo @ designing something so that "FAIL is really nothing is to be
> >> concerned with."
> >>
> >> It's the kind of thing deliverability people will now be spending the
> >> rest of their lives explaining to clients that this big ole FAIL is to
> >> be ignored.
> >>
> >
> > Agreed - which is why it's been changed now.
> >
> > Cheers,
> > Steve.
> >
> >
> > ___
> > 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
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS verify=FAIL

[Al Iverson]

Thanks for that. :)

--
Al Iverson
www.aliverson.com
(312)725-0130


On Thu, Apr 14, 2016 at 3:02 AM, Steve Freegard  wrote:
>
> On 14/04/16 00:58, Al Iverson via mailop.org wrote:
>>
>> Boo @ designing something so that "FAIL is really nothing is to be
>> concerned with."
>>
>> It's the kind of thing deliverability people will now be spending the
>> rest of their lives explaining to clients that this big ole FAIL is to
>> be ignored.
>>
>
> Agreed - which is why it's been changed now.
>
> Cheers,
> Steve.
>
>
> ___
> 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] TLS verify=FAIL

[Steve Freegard]

On 14/04/16 01:19, Franck Martin via mailop wrote:
Have a look at 
https://tools.ietf.org/html/draft-martin-authentication-results-tls-03 
may be jump to the example...


I did not pursue, but many MTA clients are sending the certificates, 
meant for receiving email to the server they are connecting too.


You can verify that the certificate is trusted (based on your list of 
trusted CAs), but there are no good method to do hostname 
verification. May be a FCrDNS would allow you to compare with the DNS 
names in the SubjectAltNames of the certificate...




Thanks for this reference Franck - I hadn't seen this draft before, but 
I'm certainly going to look at adding this into Haraka as one of the 
many uses of Haraka is for anti-spam so having additional data points 
like this in the headers is useful.


Kind regards,
Steve.

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

Re: [mailop] TLS verify=FAIL

[Steve Freegard]

On 14/04/16 00:58, Al Iverson via mailop.org wrote:

Boo @ designing something so that "FAIL is really nothing is to be
concerned with."

It's the kind of thing deliverability people will now be spending the
rest of their lives explaining to clients that this big ole FAIL is to
be ignored.



Agreed - which is why it's been changed now.

Cheers,
Steve.

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

Re: [mailop] TLS verify=FAIL

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2016-04-13 at 17:19 -0700, Franck Martin via mailop wrote:
> You can verify that the certificate is trusted (based on your list of
> trusted CAs), but there are no good method to do hostname
> verification. May be a FCrDNS would allow you to compare with the DNS
> names in the SubjectAltNames of the certificate...

dnssec/dane with tlsa records.

If we are willing to accept dkim keys via insecure dns, why not also
accept tls keys in tlsa records? If the target domain is dnssec secure,
so much the better.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlcO6OIACgkQL6j7milTFsF4sACfXrbqfUhbYoSEy2f/Ixg5HKLY
LtUAn27mlPTooYCIJGRcox6/XtcYzHJP
=zyY6
-END PGP SIGNATURE-



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

Re: [mailop] TLS verify=FAIL

[Franck Martin via mailop]

Have a look at
https://tools.ietf.org/html/draft-martin-authentication-results-tls-03 may
be jump to the example...

I did not pursue, but many MTA clients are sending the certificates, meant
for receiving email to the server they are connecting too.

You can verify that the certificate is trusted (based on your list of
trusted CAs), but there are no good method to do hostname verification. May
be a FCrDNS would allow you to compare with the DNS names in the
SubjectAltNames of the certificate...

On Wed, Apr 13, 2016 at 4:58 PM, Al Iverson 
wrote:

> Boo @ designing something so that "FAIL is really nothing is to be
> concerned with."
>
> It's the kind of thing deliverability people will now be spending the
> rest of their lives explaining to clients that this big ole FAIL is to
> be ignored.
>
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
>
>
> On Wed, Apr 13, 2016 at 5:33 PM, Steve Freegard 
> wrote:
> > Hi Robert,
> >
> > I'm one of the developers of Haraka.
> >
> > verify=FAIL simply means that the TLS certificate presented by the peer
> host
> > could not be verified as trusted by a CA.
> > In the case of an MUA (which this appears to be), it would be normal as
> an
> > MUA does not usually present client TLS certificates, so this would
> always
> > be expected to fail verification because we have no certificate to verify
> > against, so I changed this in the latest alpha say verify=NO meaning we
> > couldn't verify the certificate as one wasn't presented.
> >
> > Your logs will provide more information e.g.:
> >
> > haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369]
> [defendermx/tls]
> > secured: cipher=ECDHE-RSA-AES256-SHA38
> > 4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer
> > certificate"
> >
> > haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F]
> > [defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256
> > version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com"
> organization="Google
> > Inc" issuer="Google Inc" expires="Oct 12 00:00:00 2016 GMT"
> > fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00
> >
> > In short - it's really nothing to be concerned with.
> >
> > Kind regards,
> > Steve.
> >
> >
> >
> > On 13/04/16 22:56, Robert Guthrie via mailop.org wrote:
> >
> > Hello List,
> >
> > I wonder if someone could tell me about the verify=FAIL messages I'm
> seeing
> > in email headers sent from my SMTP's.
> >
> > Received: from loomio.io (errbit.loomio.org [45.55.128.240])
> >   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id
> > 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
> >   envelope-from  (authenticated bits=0)
> >   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384
> verify=FAIL);
> >   Wed, 13 Apr 2016 21:05:59 +
> >
> > If I'm seeing this, is there something I can or should do to resolve
> this?
> > Sometimes I see verify=NO also.
> >
> >
> > ___
> > 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
> >
>
> ___
> 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] TLS verify=FAIL

[Al Iverson]

Boo @ designing something so that "FAIL is really nothing is to be
concerned with."

It's the kind of thing deliverability people will now be spending the
rest of their lives explaining to clients that this big ole FAIL is to
be ignored.

--
Al Iverson
www.aliverson.com
(312)725-0130


On Wed, Apr 13, 2016 at 5:33 PM, Steve Freegard  wrote:
> Hi Robert,
>
> I'm one of the developers of Haraka.
>
> verify=FAIL simply means that the TLS certificate presented by the peer host
> could not be verified as trusted by a CA.
> In the case of an MUA (which this appears to be), it would be normal as an
> MUA does not usually present client TLS certificates, so this would always
> be expected to fail verification because we have no certificate to verify
> against, so I changed this in the latest alpha say verify=NO meaning we
> couldn't verify the certificate as one wasn't presented.
>
> Your logs will provide more information e.g.:
>
> haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369] [defendermx/tls]
> secured: cipher=ECDHE-RSA-AES256-SHA38
> 4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer
> certificate"
>
> haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F]
> [defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256
> version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com" organization="Google
> Inc" issuer="Google Inc" expires="Oct 12 00:00:00 2016 GMT"
> fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00
>
> In short - it's really nothing to be concerned with.
>
> Kind regards,
> Steve.
>
>
>
> On 13/04/16 22:56, Robert Guthrie via mailop.org wrote:
>
> Hello List,
>
> I wonder if someone could tell me about the verify=FAIL messages I'm seeing
> in email headers sent from my SMTP's.
>
> Received: from loomio.io (errbit.loomio.org [45.55.128.240])
>   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id
> 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
>   envelope-from  (authenticated bits=0)
>   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL);
>   Wed, 13 Apr 2016 21:05:59 +
>
> If I'm seeing this, is there something I can or should do to resolve this?
> Sometimes I see verify=NO also.
>
>
> ___
> 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
>

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

Re: [mailop] TLS verify=FAIL

[Steve Freegard]

Hi Robert,

I'm one of the developers of Haraka.

verify=FAIL simply means that the TLS certificate presented by the peer 
host could not be verified as trusted by a CA.
In the case of an MUA (which this appears to be), it would be normal as 
an MUA does not usually present client TLS certificates, so this would 
always be expected to fail verification because we have no certificate 
to verify against, so I changed this in the latest alpha say verify=NO 
meaning we couldn't verify the certificate as one wasn't presented.


Your logs will provide more information e.g.:

haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369] 
[defendermx/tls] secured: cipher=ECDHE-RSA-AES256-SHA38
4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer 
certificate"


haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F] 
[defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256 
version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com" 
organization="Google Inc" issuer="Google Inc" expires="Oct 12 00:00:00 
2016 GMT" 
fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00


In short - it's really nothing to be concerned with.

Kind regards,
Steve.


On 13/04/16 22:56, Robert Guthrie via mailop.org wrote:

Hello List,

I wonder if someone could tell me about the verify=FAIL messages I'm 
seeing in email headers sent from my SMTP's.

Received: fromloomio.io   (errbit.loomio.org 
  [45.55.128.240])
bysmtp.loomio.io   (Haraka/2.8.0-alpha.7) with 
ESMTPSA id 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
envelope-from mailto:err...@loomio.io>> 
(authenticated bits=0)
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384*verify=FAIL*);
Wed, 13 Apr 2016 21:05:59 +
If I'm seeing this, is there something I can or should do to resolve this?
Sometimes I see verify=NO also.


___
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] TLS verify=FAIL

[Brandon Long via mailop]

If the server is saying your client connection is verify=FAIL/NO, I would
imagine that means either you have a client certificate that doesn't
verify, or you don't have a client certificate the remote server is being
pedantic about it.

Brandon

On Wed, Apr 13, 2016 at 2:56 PM, Robert Guthrie  wrote:

> Hello List,
>
> I wonder if someone could tell me about the verify=FAIL messages I'm
> seeing in email headers sent from my SMTP's.
>
> Received: from loomio.io (errbit.loomio.org [45.55.128.240])
>   by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id 
> 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1
>   envelope-from  (authenticated bits=0)
>   (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 *verify=FAIL*);
>   Wed, 13 Apr 2016 21:05:59 +
>
>
> If I'm seeing this, is there something I can or should do to resolve this?
> Sometimes I see verify=NO also.
>
> ___
> 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