Re: [Fetchmail-users] TLS fingerprints, and option --pinnedpublickey <sha256//b64hash>

[grarpamp <gra...@gm...>]

It's info for people to understand various background on why
--pinnedpublickey is showing up now in softwares that speak TLS.
If users like to pool together and implement, and have available to
use the feature as desired or not, in whatever upcoming release,
great for them. If not, then they won't have it yet is all.
Simple, no problem, no need to shoot when even ...

Here are more background link reasons, and sample code, and related...

https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
https://owasp.org/www-project-cheat-sheets/cheatsheets/Pinning_Cheat_Sheet

https://www.netcraft.com/internet-data-mining/ssl-survey/
https://www.ssllabs.com/ssl-pulse/
https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/
https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-internet-standard/
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://tools.ietf.org/html/rfc8446


> minor releases

pinnedpublickey would be new, not change, so doesn't apply.

Who nobody said anything about when TLS.
Though given deprecation of SSL since decade,
the 6.4 -> 7.x would seem be good for s/SSL/TLS/ig
forward so as not to perpetuate SSL in overall thoughts
when TLS is the majority standard now and ssl dead by then.

Regardless of option names, posters are often writing mail things
as "SSL", this implies maybe some missing knowledge that
it is actually TLS nowdays in use since decade, even in use
by fetchmail in maybe their particular case, so no problem
to help not perpetuate that, or to help accuracy. See above links.

> Aunt Tillie

Aunt Tillie has a support team, it's called Niece Julie,
else she'd just be called Lady Tillie. And if Lady Tillie is
here using unix fetchmail, good for her, and confident
she can search and read links like other amazing users.

> And what prevents a state

Yes various actors are the reasons a variety of options
and tools are made to combine together against
various adversaries, including pinnedpublickey, PGP,
tor, etc. It is about having many options in depth, not
one single one waiting to fail.

People could and do even pinnedpublickey with i2p/onion/etc
services to detect potential attack before moving data,
even on web like facebook onion, and mail systems too.

> I see no difference to state orders forcing the mail service to reveal
> unencrypted information.
> plaintext

Some jurisdictions and attacks and spies and vantage points treat or
can hit the wire different from the service. Everything on the wire needs
wrapped in TLS, and TLS has some various use cases for various options.
What content or crypto travels inside is of no relavance to fetchmail binary.

> Mozilla (who are normally the source for the trust lists)

Microsoft originates its own, so do a few others, they all
overlap and intershare.

> I think they have removed CAs that were involved in scandals

Removal of obvious scandals logically does not and cannot
certify the remaining CA's as being pure now, or in the future.

> Oh they do serve a purpose, and that's permitting delegating server
> authentication.

Intermediate org level certs issued by roots seem quite rare,
and LetsEnc haven't yet [?] issue any. Roots signing
whatever server certs are handed to them is different from
delegating intermediates to orgs.

> Those that mess with certificates, will, too.

Such attacks against big gmail size frontends affecting
everyone loudly would be stupid expose of attacker.
Real adversaries can also target individual users at their network
edges where such little noise is hardly heard from them.

> 5/1/384/512/3 hashes

CA's are mostly using sha256 now, people have 256
in their toolsets, pinnedpublickey matches that nicely,
and 256 isn't broken yet so can suffice alone without
composition till then, unlike 5/1 which are broken.
Sha-3 is in hedge pool.

> ...alleviating the need to keep huge CRLs.

Many implementations still don't bother checking CRLs,
they just trust whatever looks like a CA. And checking
CRLs is a massive metadata privacy and monetization
leak that some users might not want to do.

> Which is its very purpose.

Fingerprints can be held over whatever desired cert
parameters to serve different purposes. If a user
really cares what some CA says, they can pin the sig.
If they don't care what CA says, can pin just the pubkey linked.
Or check both. The existance of two print methods
proves more than one purpose.

> historically you'd find tons of instructions

Backward compat is fine, but not to the point
of inhibiting good movement into the future.

> validate the fingerprints *in practice.

Plenty of old blogs would say to contact the mail
provider and ask. As before, now many of them
are publishing attestations in public places for users to
various degrees of trust assignability. Better than nothing.


> IMPLICITLY follows an INSECURE!!! trust-on-first-use setting

Post mentioned variety of means to verify assess a security position.
Contrary, most users use of TLS is actually completely unverified,
and based entirely on "trusting" non-fiduciary third parties and other
entities they have no reason or agreement to trust. By doing some
verification and pinning many parties and attacks are removed.
Even TOFU via simple vpn/tor observatory check can be better
at defeating some threats than untrusted CA "trust".
Fine if users don't want to pin, most don't, but they should have
and know some things on they could and why.

> lobby all the mail service providers to actually upgrade their TLS stuff
> to be v1.3 capable.

Many of the big providers, and the privacy oriented ones,
already have 1.3 at the head of their ciphersuite preference list.
Now that 1.3 is standard, the rest are adding it and dropping
older than 1.2 in the process, its linked above.

> the transmission channel often only has opportunistic TLS.

That's not fetchmail business :) Msmtp and others can pin too.

> out of perspective for the mail transmission chain between
> the sender and the fetchmail user as a whole system.

Defense in depth.

> add SHA256 and stronger hashes for fingerprinting

SHA256 is fine alone. The adding was to give users
options to not use broken md5 / sha1 pins. Any composition
was probably meant as easy to do logic hedge. Years
ago most public attestations used md5 / sha1, at then
either sha 256 or 3 were thus non broken options.
Attestation seems to be slowly moving to sha256 now
(since the certs hash internally already did too), but that
doesn't affect which strong one is used for pinning, other than
to be easy cut paste compare compatible to today attestations.


Happy fetchmailing :)