Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
October 15 2018 11:19 AM, "Kris Deugau" 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. nam...@example.com). 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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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. nam...@example.com). 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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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?
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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.
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
On October 13, 2018 5:32:54 PM GMT+02:00, Gary 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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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.
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
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: pg...@dev-mail.net Sent: October 13, 2018 7:40 AM To: postfix-users@postfix.org 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.
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.
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
On Saturday, October 13, 2018 2:02 AM, 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. nam...@example.com). 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.
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
On Friday, October 12, 2018 06:02:40 PM pg...@dev-mail.net 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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
On 12 Oct 2018, at 21:02, pg...@dev-mail.net 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
On 13/10/18 14:02, pg...@dev-mail.net 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
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
> 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.
Re: Are sha1 & TLSv1 fully deprecated wrt mail, and time to block them?
On October 13, 2018 12:06:03 AM UTC, pg...@dev-mail.net 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=xx > 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
