[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [msmtp-users] [mpop-users] support SHA-2 and SHA-3



Hi!

On Sun, 10 Apr 2016 18:28:14 +0200, ilf wrote:
> Is there a convincing reason *not* to support the others? (SHA-224, 
> SHA-384, SHA-512/224, SHA-512/256) The neccessary code seems minimal
> and trivial, so I propose to implement support for all six SHA-2 hash 
> functions.

First, you need a convincing reason to add a feature; the lack of a
convincing reason *not* to add it is not sufficient.

Second, yes there is a reason not to add them: they provide no
additional value and only add confusion. Why should msmtp/mpop support
methods for fingerprinting that nobody else uses?

> Going further: SHA-3 has been standardized half a year ago. Any
> reason for not implementing it? There's free reference code: 
> https://github.com/gvanas/KeccakCodePackage/blob/master/Standalone/CompactFIPS202/Keccak-readable-and-compact.c
> (But I admit, even GnuTLS seems to still be finalizing their code 
> support.)

For SHA-3, the same as above applies, but additionally msmtp/mpop
should always use the appropriate GnuTLS (or OpenSSL) function to get a
fingerprint and should never implement fingerprint calculation
themselves. That can only lead to trouble.

> > That keeps MD5 supported although it is discouraged. I expect that
> > when certificates are renewed or replaced and thus fingerprints in
> > the mpop/msmtp configuration need updating, users will most likely
> > use --serverinfo to get the new fingerprint and thus update to
> > SHA256 automatically. I see no need to break their configurations
> > now.  
> 
> That's a good way for now. But since MD5 is seriously broken and
> SHA-1 should be avoided, I think they should both be sunsettet. How
> about adding a note to the NEWS, that MD5 will be *disabled* in - say
> - half a year, and SHA1 will be disabled in one year?
> 
> That may sound drastic, but it's what all the big browsers are doing: 
> https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html

This is a different topic: browsers will soon stop accepting
certifcates with SHA1 *signatures* (e.g. in Firefox, see View
certficate -> Details -> Certificate Fields -> Certificate Signature
Algorithm). This is not the same as a certificate fingerprint.

Still of course, SHA1 should be replaced everywhere, including
fingerprints. I just think in this case it can be done by letting
users do it instead of us breaking their configuration.

> On a related note: Is the "tls" option enabled or disabled per
> default? The man page only sais:
> 
> > Enable or disable TLS (also known as SSL) for secured connections.  
> 
> If it's off by default, I propose changing that to on.

It is indeed off by default, and that is unfortunate. See below [*].

> Going even further, I also propose to change the default of 
> "tls_starttls" to "off". Taking from the SMTP Strict Transport
> Security draft:
> 
> > The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
> > hosts to establish secure SMTP sessions over TLS. In its current
> > form, however, it fails to provide (a) message confidentiality --
> > because opportunistic STARTTLS is subject to downgrade attacks […]  
> 
> https://tools.ietf.org/html/draft-margolis-smtp-sts-00

That text is a different topic and different context that does not
apply here. It handles MTA-to-MTA sessions. There you can downgrade
when you can modify the start of an SMTP session and prevent the server
end from advertising its STARTTLS capability, thereby causing the
client end to fall back to unencrypted SMTP. But msmtp/mpop do not do
this: they will never fall back to unencrypted SMTP/POP.

> Proper TLS beats StartTLS hands-down.

I don't think that is true in general. Do you have any information that
supports this claim?


[*]

Today a few msmtp/mpop defaults do not make sense anymore. Msmtp should
now default to the mail submission port 587, with TLS enabled (note
that this *requires* STARTTLS). That would require changing the
defaults for 'port' and 'tls'. For mpop, only the second applies.

The problem is that 'tls on' as a default does not simply work, because
you need at least 'tls_trust_file', and that is unfortunately different
everywhere.

Regards,
Martin

Attachment: pgpUB9D0zb1pC.pgp
Description: OpenPGP digital signature