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
Attachment:
signature.asc
Description: Digital signature