Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

[Matthias A. <mat...@gm...>]

Am 20.02.2017 um 06:36 schrieb grarpamp:
> On Sun, Feb 19, 2017 at 8:31 PM, Matthias Andree <mat...@gm...> wrote:
> It's rather having the TLS 1.3 bits in place on the assumption that
>> OpenSSL's API remains in line
>> Am 19.02.2017 um 21:45 schrieb grarpamp:
> Don't know, maybe they will adopt some reform notions
> from libressl. Old libraries can be hard to deal with.

I will not support "old" libraries that have gone out of their
respective vendor's support (the 6.4.x branch refuses to build against
OpenSSL 1.0.1), and I'm not sure what level of "support" I will provide
to LibreSSL either - the former is a matter for the paid backporters of
enterprise distros, not for spare-time projects, and LibreSSL's
appearance was good to get some pressure on and funding for the OpenSSL
project, but AFAICS it's currently causing more pain than what it's
worth because it misrepresents the OpenSSL API level in its header files
and needs explicit LibreSSL checks. I will not guarantee LibreSSL
compatibility as long as OpenSSL is alive.

>> I can negotiate TLS v1.3 connections to a web server, but am not aware of
>> any IMAP or POP3 server that talks TLSv1.3 yet.
> Unlikely in production. There's always './openssl s_server' to
> just check the connection. Maybe ssllabs has some other tests.

That just not useful because it connects a developer OpenSSL library to
itself. It would have to be another major software on the server end
(GnuTLS, Mozilla NSS) to be useful, and that's why I've tested talking
to a cloudflare web server. ->
https://blog.cloudflare.com/ietf-hackathon-getting-tls-1-3-working-in-the-browser-2/amp/

> At least on this page, WolfSSL claims draft 1.3 support...
> https://en.wikipedia.org/wiki/Transport_Layer_Security
>
> So servers should be coming before long.

Nothing on https://www.wolfssl.com/wolfSSL/Docs-wolfssl-changelog.html
though.

>
>>> Then you have the cert observatory projects.
>> None of which is used by fetchmail, and if I need to implement or link a
>> web browser to fetch that information, (or to log in anywhere, OAuth was
>> proposed but servers a different purpose), it's rather unlikely to happen.
> Those services are too new and changing to bother implementing
> or linking anything.
> But as with 'mda' option, maybe shelling out via some new
> 'sslfpcheck' option that passes the fingerprint out environment
> and accepts exit of 0 or 1 back. That way users can do
> whatever they want with it.

Now there's a thought worth consideration, thanks for the idea, I'll
roll it forth and back a bit. Only it might need a tri-state return
value, 0 "OK", 23 for "REJECT", anything else for "ERROR=DUNNO", or
possibly sysexits.

>> directive in the manual page, fixed in Git (but upload to sourceforge
>> https://gitlab.com/fetchmail/fetchmail/commits/legacy_64
> You've had the cool options more than any other fetching project
> out there so no worries, I know they're there :)

Only their names suck. --sslcert vs. --sslcertfile? Uh. Not easily
changed unless you want to have duplicate names for the same option for
compatibility.