Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

pg151
1st, this is -- for me -- a postix/mail-RELATED security question.  But if it's too general, I'm happy to take it elsewhere; suggestions as to the appropriate forum, if not here, are welcome.

A 'major financial institution', call 'em "FinCo", sends email to users on my server that arrives with 'invalid' dkim sig,

        dkim=invalid (unsupported algorithm rsa-sha1, 1024-bit rsa key sha1)
        Fri Oct 12 16:18:05 2018 authentication_milter_mx[7045]       header.d=FINCO.com header.i=@FINCO.com header.b=xxxxxx
        Fri Oct 12 16:18:05 2018 authentication_milter_mx[7045]       header.a=rsa-sha1 header.s=mail-dkim;

and negotiates TLSv1

        postfix/postscreen-internal/smtpd[52027]: Anonymous TLS connection established from mta11.FINCO.com[xx.xx.xx.xx]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

I know that, generally, uses of TLSv1 & sha1 are, at least, fish-slap-worthy -- if not downright fully deprecated.

What I don't know is if, in current practice, either is a concern -- from viewpoint of general security, standards compliance, etc -- for *MAIL* security.  Namely, DKIM sig and TLS negotation.

        What *IS* the current recommendation on these?

        IS it time, yet, to block TLSv1 negotation &/or sha1-signed DKIM sigs in mail flow?

Applying blanket blocks for either, in Postfix setup, is trivial enough.  Just a question for me of wheter it's "safe", or "sensical", to do it.



       
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Scott Kitterman-4


On October 13, 2018 12:06:03 AM UTC, [hidden email] wrote:

>1st, this is -- for me -- a postix/mail-RELATED security question.  But
>if it's too general, I'm happy to take it elsewhere; suggestions as to
>the appropriate forum, if not here, are welcome.
>
>A 'major financial institution', call 'em "FinCo", sends email to users
>on my server that arrives with 'invalid' dkim sig,
>
> dkim=invalid (unsupported algorithm rsa-sha1, 1024-bit rsa key sha1)
> Fri Oct 12 16:18:05 2018 authentication_milter_mx[7045]      
> header.d=FINCO.com header.i=@FINCO.com header.b=xxxxxx
> Fri Oct 12 16:18:05 2018 authentication_milter_mx[7045]      
>header.a=rsa-sha1 header.s=mail-dkim;
>
>and negotiates TLSv1
>
> postfix/postscreen-internal/smtpd[52027]: Anonymous TLS connection
>established from mta11.FINCO.com[xx.xx.xx.xx]: TLSv1 with cipher
>DHE-RSA-AES256-SHA (256/256 bits)
>
>I know that, generally, uses of TLSv1 & sha1 are, at least,
>fish-slap-worthy -- if not downright fully deprecated.
>
>What I don't know is if, in current practice, either is a concern --
>from viewpoint of general security, standards compliance, etc -- for
>*MAIL* security.  Namely, DKIM sig and TLS negotation.
>
> What *IS* the current recommendation on these?
>
> IS it time, yet, to block TLSv1 negotation &/or sha1-signed DKIM sigs
>in mail flow?
>
>Applying blanket blocks for either, in Postfix setup, is trivial
>enough.  Just a question for me of wheter it's "safe", or "sensical",
>to do it.

RFC 8301 removes rsa-sha1 from DKIM, so "FinCo" isn't wrong to consider the signature invalid.  It's a bit aggressive for my taste, be it's the receivers call.  The most I might do is ignore the signature.  It's definitely not a reason to block the message.

Scott K
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

pg151


> RFC 8301 removes rsa-sha1 from DKIM, so "FinCo" isn't wrong to consider
> the signature invalid.  It's a bit aggressive for my taste, be it's the
> receivers call.  The most I might do is ignore the signature.  It's
> definitely not a reason to block the message.

Thanks for the relevant rfc.

I tend to agree.

I may have been unlcear -- it's my server receiving emails from the errant FinCo, dkim-signed with sha1 sigs.  So up to me to determine if they are 'putting clients at risk' by being lazy about their security, and blocking their messages.

Simply, IMO, FinCo's admins are being lazy/sloppy.  They _should_ know & do better.  (This really is a BIG organization; personally, I'd be embarrassed ...)

My suspicion is that this is NOT rising to "nuke the basatards" smtp response, and that I should figure out how to get the attention of the right persons (NOT 'customer service') at FinCo.  TBH, how to make that contact is beyond me; public shaming on Twitter might be an option ;-)

That's for DKIM.

Same question remains, and I suspect with a similar answer, re: TLSv1.

Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Peter Ajamian
On 13/10/18 14:02, [hidden email] wrote:
> I may have been unlcear -- it's my server receiving emails from the
> errant FinCo, dkim-signed with sha1 sigs.  So up to me to determine
> if they are 'putting clients at risk' by being lazy about their
> security, and blocking their messages.
You're presenting two different issues here, let's look at each one
separately:

Issue #1 the use of TLSv1.0.  Unless I'm mistaken the only actual
vulnerability to TLSv1.0 is BEAST, which can be (and likely is)
mitigated client-side, so if your version of openssl mitigates BEAST
then TLSv1.0 should actually be safe to use as a client.  Using it as a
server will depend on whether or not the connecting client has mitigated
BEAST.

That said, when making public connections on port 25, the recommended
setting for smtp[d]_tls_security_level is "may", because if you set it
to enforce there are still a number of servers that do not support
encryption at all that you will not be able to communicate with.  So if
you were to limit TLS connections to TLSv1.2 and higher then a TLSv1.0
connection will simply fall back to plain text, and then you're left
with no encryption at all, so ask yourself which is better, broken
encryption, or no encryption and you will see that it's probably best to
go ahead and accept TLSv1.0 connections, even from a financial institution.

As for SHA1, that is a different matter.  Do you accept a DKIM sig
signed with SHA1 or not?  Personally I would just accept it and not
worry about it, but if you're concerned then there are a couple of
options.  You can treat it as unsigned, and accumulate a SPAM score
appropriately, or perhaps you can go part way in-between and give it a
lesser SPAM score than an unsigned message but still give it something.

Anyways, at the end of the day the choice is up to you, and it comes
down to two things to consider:

Is it worth blocking mail from a financial institution in order to gain
marginally better security?

What is the likely hood that a spammer is going to try to brute-force an
SHA1 hash collision in order to send out SPAM?

Good Luck,


Peter
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Bill Cole-3
In reply to this post by pg151
On 12 Oct 2018, at 21:02, [hidden email] wrote:

> Same question remains, and I suspect with a similar answer, re: TLSv1.

There's no reason for negotiating a TLSv1.0 session with a partner
capable of doing better other than being lazy, cheap, and/or generally
careless.

There are much better reasons to accept TLSv1.0 sessions from partners
incapable of doing anything better. If you are not willing to refuse
attempts to pass mail unencrypted and lose mail as a result, TLSv1.0 may
be your only option to get mail from some senders. TLSv1.0 with decent
ciphers is unequivocally better than cleartext transport, and most
people do not have email worth the effort of cracking TLSv1.0 to anyone
capable of doing so.

So, while FinCo definitely should be doing better, you probably wouldn't
be doing anyone a service by refusing to accommodate their incompetence.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Scott Kitterman-4
In reply to this post by pg151
On Friday, October 12, 2018 06:02:40 PM [hidden email] wrote:

> > RFC 8301 removes rsa-sha1 from DKIM, so "FinCo" isn't wrong to consider
> > the signature invalid.  It's a bit aggressive for my taste, be it's the
> > receivers call.  The most I might do is ignore the signature.  It's
> > definitely not a reason to block the message.
>
> Thanks for the relevant rfc.
>
> I tend to agree.
>
> I may have been unlcear -- it's my server receiving emails from the errant
> FinCo, dkim-signed with sha1 sigs.  So up to me to determine if they are
> 'putting clients at risk' by being lazy about their security, and blocking
> their messages.
>
> Simply, IMO, FinCo's admins are being lazy/sloppy.  They _should_ know & do
> better.  (This really is a BIG organization; personally, I'd be embarrassed
> ...)
>
> My suspicion is that this is NOT rising to "nuke the basatards" smtp
> response, and that I should figure out how to get the attention of the
> right persons (NOT 'customer service') at FinCo.  TBH, how to make that
> contact is beyond me; public shaming on Twitter might be an option ;-)
>
> That's for DKIM.

To amplify a bit:

RFC 8301 changed two security properties relative to DKIM:

1.  Removed rsa-sha1 from the algorithm set (later replaced by Ed25519-sha256
in another RFC).

2.  Bumped the minimum acceptable RSA key sized to 1024 bits (with 2048
recommended).

The latter change is operationally much more important today (it's at least 5
years late).  Not accepting DKIM signatures based on RSA keys < 1024 bits is
something everyone should be doing and there are risks in not doing so.

The removal of rsa-sha1 was done ahead of it being broken for this use case
(on the theory it's better disuse in advance of the need to panic over it).

Scott K
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Laura Smith
In reply to this post by pg151

On Saturday, October 13, 2018 2:02 AM, <[hidden email]> wrote:

> My suspicion is that this is NOT rising to "nuke the basatards" >smtp response, and that I should figure out how to get the >attention of the right persons (NOT 'customer service') at FinCo. >TBH, how to make that contact is beyond me; public shaming on >Twitter might be an option ;-)


Honestly, you are most likely wasting your time on that point because all that you are likely to get back is a page of waffle saying "blah blah blah ... security reasons... blah blah blah"

I know this because a sysadmin ex-colleague was having problems creating accounts with a FinCo using delimiters (e.g. [hidden email]).   FinCo's filters were rejecting this because it was "invalid".

Said individual wrote a carefully worded long letter to C-suite execs at FinCo, also taking the time to attach copies of RFCs referred to in the letter so they would not have to look them up.

A couple of weeks later, a reply arrived in the post ... "blah blah blah ... security reasons... blah blah blah... we know better... blah blah blah"

So the moral of this story is, unless you have friends working for FinCo, don't bother trying to engage them on how they could improve client service by fixing their IT infrastructure. They are unlikely to listen.


Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

pg151
I appreciate the comments on this.

Boils down to:

> ... moral of this story is ....

in no particular order,

 **    'Best/current Practice' _is_ better than sha1/dkim & TLSv1
 **    FinCo's lazy & sloppy, not worth rejecting, but I can flag & watch
 **    I've checked my ~12 month logs; FinCo represents ~ 95% of accepted/legit mail that's both sha1/dkim & TLSv1
 **    I'll send one letter to FinCo's CIO/CSO offices.  I expect no change, but it'll make me 'feel better'.
 **    I've confirmed that < 1024 bit sigs are not accepted at all
 **    for now, my TLS policy stays at ="may"

and get back to more useful work.

thanks all.

Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

lists@lazygranch.com

https://support.google.com/mail/answer/81126?hl=en

Look at "authenticate your mail" in the above link. Gmail required 1024 bits. Google market dominance makes it a defacto standard.

  Original Message  
From: [hidden email]
Sent: October 13, 2018 7:40 AM
To: [hidden email]
Subject: Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

I appreciate the comments on this.

Boils down to:

> ... moral of this story is ....

in no particular order,

**    'Best/current Practice' _is_ better than sha1/dkim & TLSv1
**    FinCo's lazy & sloppy, not worth rejecting, but I can flag & watch
**    I've checked my ~12 month logs; FinCo represents ~ 95% of accepted/legit mail that's both sha1/dkim & TLSv1
**    I'll send one letter to FinCo's CIO/CSO offices.  I expect no change, but it'll make me 'feel better'.
**    I've confirmed that < 1024 bit sigs are not accepted at all
**    for now, my TLS policy stays at ="may"

and get back to more useful work.

thanks all.
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

pg151
On Sat, Oct 13, 2018, at 8:32 AM, Gary wrote:
> Look at "authenticate your mail" in the above link. Gmail required 1024
> bits. Google market dominance makes it a defacto standard.

In this case, yes, that's a helpful reference to point folks at.

Generally, I don't accept/agree in the slightest that _because_ Google (or Facebook, Microsoft, Apple, etc etc) 'does it' it's necessarily correct, good, or even close to implying a 'standard'.

At best, it makes it 'currently used a lot' ...

For mail/security, I place _much_ more weight on what's done in/by Postfix & Openssl projects.
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Bill Cole-3
In reply to this post by Bill Cole-3
On 13 Oct 2018, at 0:33, Bill Cole wrote:

>  TLSv1.0 with decent ciphers is unequivocally better than cleartext
> transport, and most people do not have email worth the effort of
> cracking TLSv1.0 to anyone capable of doing so.

CLARIFYING:

There's nothing (yet) known that makes all implementations and useful
configurations of TLSv1.0 vulnerable to a sufficiently motivated,
skilled, and resourced attacker. The risk is that if you choose to
support TLSv1.0 to accommodate bozos, you may find yourself forced to
accommodate vulnerable implementations and configurations (e.g. CBC mode
ciphers, vulnerable types of renegotiation) and forego some stronger
ciphersuites for TLSv1.0 sessions. Every TLSv1.0 session isn't
vulnerable today, maybe none that you allow are, and maybe recorded
sessions won't be any more vulnerable in a decade. However, a session
using TLSv1.3 with a stronger ciphersuite than TLSv1.0 supports carries
a lower risk in those 'maybes.'

--
Bill Cole
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Christian Kivalo
In reply to this post by lists@lazygranch.com


On October 13, 2018 5:32:54 PM GMT+02:00, Gary <[hidden email]> wrote:
>
>https://support.google.com/mail/answer/81126?hl=en
>
>Look at "authenticate your mail" in the above link. Gmail required 1024
>bits. Google market dominance makes it a defacto standard.

They require to use at least 1024 bits keys for dkim signatures, more bits are good and accepted.
--
Christian Kivalo
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Bill Cole-3
In reply to this post by Peter Ajamian
On 12 Oct 2018, at 23:04, Peter wrote:

> Issue #1 the use of TLSv1.0.  Unless I'm mistaken the only actual
> vulnerability to TLSv1.0 is BEAST, which can be (and likely is)
> mitigated client-side, so if your version of openssl mitigates BEAST
> then TLSv1.0 should actually be safe to use as a client.  Using it as
> a
> server will depend on whether or not the connecting client has
> mitigated
> BEAST.

There's also POODLE in some TLS implementations and a weaker set of
ciphersuites.

Both known 'name' attacks on TLSv1.0 are logistically challenging to
mount and unlikely to ever be aimed at SMTP+TLS traffic and so are a
negligible risk, but that overlooks some significant issues:

1. If an implementation can't do better than TLSv1.0, it is old and
ill-maintained and has a substantial risk of having unknown or
lesser-known vulnerabilities that can't be mitigated by a lenient
partner running the latest and greatest implementation.

2. As TLSv1.0 is increasingly abandoned by both TLS implementations and
in operational configurations, novel vulnerabilities in the old protocol
are more likely to remain covert and hence highly useful, especially if
they are less painful to exploit than BEAST or POODLE.

--
Bill Cole
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Viktor Dukhovni
On Sat, Oct 13, 2018 at 12:12:21PM -0400, Bill Cole wrote:

> 2. As TLSv1.0 is increasingly abandoned by both TLS implementations and
> in operational configurations, novel vulnerabilities in the old protocol
> are more likely to remain covert and hence highly useful, especially if
> they are less painful to exploit than BEAST or POODLE.

That's all nice in theory, but if I disabled TLS 1.0, I'd have some
issues receiving messages from this list and the krbdev list.  My
logs since Sep 27 show non-trivial TLSv1 message counts:

  190 cloud9.net
   22 mit.edu
  ...

As yet, I see no compelling reason to disable TLS 1.0 in SMTP.  What
you can and should now disable is SSLv2 and SSLv3, which Postfix
now disables by default.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

pg151


On Sat, Oct 13, 2018, at 10:41 AM, Viktor Dukhovni wrote:
> As yet, I see no compelling reason to disable TLS 1.0 in SMTP.

Noted.

> What you can and should now disable is SSLv2 and SSLv3, which Postfix
> now disables by default.

Already done.

Ironically, FinCo's online 'security/privacy' missive crows about their commitment to ensuring "Email Security", their commitment to protecting their websites with "SSL3", and that users should look for "SSL Secured (128 Bit)." in their cert info.

Sigh. Whatchagonnado?
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Kris Deugau
In reply to this post by Laura Smith
Laura Smith wrote:
> Honestly, you are most likely wasting your time on that point because all that you are likely to get back is a page of waffle saying "blah blah blah ... security reasons... blah blah blah"
>
> I know this because a sysadmin ex-colleague was having problems creating accounts with a FinCo using delimiters (e.g. [hidden email]).   FinCo's filters were rejecting this because it was "invalid".
>
> Said individual wrote a carefully worded long letter to C-suite execs at FinCo, also taking the time to attach copies of RFCs referred to in the letter so they would not have to look them up.
>
> A couple of weeks later, a reply arrived in the post ... "blah blah blah ... security reasons... blah blah blah... we know better... blah blah blah"
>
> So the moral of this story is, unless you have friends working for FinCo, don't bother trying to engage them on how they could improve client service by fixing their IT infrastructure. They are unlikely to listen.

When I come across a site that won't accept a "foo+bar" username part
for the email, I roll my eyes and use "foo_bar" instead.  Thanks Wietse,
for adding support for multiple different characters in recipient_delimiter!

(I used to do this anyway when my personal server was running sendmail,
but there I had to add yet another entry in virtusertable each time.)

Of course, sometimes you don't find out that "foo+bar" isn't supported
until you notice curious lack of email from the site...  since their
form doesn't validate as tightly as their mail system.  Or sometimes the
login page is the picky one.

-kgd
Reply | Threaded
Open this post in threaded view
|

Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?

Curtis Maurand
October 15 2018 11:19 AM, "Kris Deugau" <[hidden email]> wrote:

> Laura Smith wrote:
>
>> Honestly, you are most likely wasting your time on that point because all that you are likely to
>> get back is a page of waffle saying "blah blah blah ... security reasons... blah blah blah"
>>> I know this because a sysadmin ex-colleague was having problems creating accounts with a FinCo
>> using delimiters (e.g. [hidden email]). FinCo's filters were rejecting this because it was
>> "invalid".
>>> Said individual wrote a carefully worded long letter to C-suite execs at FinCo, also taking the
>> time to attach copies of RFCs referred to in the letter so they would not have to look them up.
>>> A couple of weeks later, a reply arrived in the post ... "blah blah blah ... security reasons...
>> blah blah blah... we know better... blah blah blah"
>>> So the moral of this story is, unless you have friends working for FinCo, don't bother trying to
>> engage them on how they could improve client service by fixing their IT infrastructure. They are
>> unlikely to listen.
>
> When I come across a site that won't accept a "foo+bar" username part for the email, I roll my eyes
> and use "foo_bar" instead. Thanks Wietse, for adding support for multiple different characters in
> recipient_delimiter!
>
> (I used to do this anyway when my personal server was running sendmail, but there I had to add yet
> another entry in virtusertable each time.)
>
> Of course, sometimes you don't find out that "foo+bar" isn't supported until you notice curious
> lack of email from the site... since their form doesn't validate as tightly as their mail system.
> Or sometimes the login page is the picky one.
>
> -kgd


Looks to me like something that wants to be escaped.  I'm thinking that if it's a scripting language trying to accept the connection, it might see the plus sign and try to do math on it.  After all amavisd is written in Perl.  

--cjm