Thanks, Martin! Martin Lambers:
A quick check suggests that the one function in current widespread use to report TLS certificate fingerprints is SHA256 (Firefox, Chrome, various TLS-related websites), with SHA1 still being usually reported too.
Yes, SHA-256 seems very widespread. But I have actually seen SHA-512, too.
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.
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.)
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
Also, people who build their own mpop/msmtp from source should be able to transition to SHA-2 after being told so. People using packages from distibutions will probably receive the update with months (or years) of delay, leaving enough time to transition to SHA-2 with their MTAs cert renewal. Also, since this only affects people doing certificate pinning, I assume they will all be able to handle this.
What do you think?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.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-00Proper TLS beats StartTLS hands-down. There should be few MTAs not supporting this. It's 2016.
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________ msmtp-users mailing list msmtp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msmtp-users
