Re: [fetchmail-devel] fetchmail 7.0.0-alpha5 alpha preview release - SSL cipher setting/info

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

It compiles against openssl 1.0.1e fine, will test when I can.

autoreconf -fiv adds a missing ./test-driver to the distribution.

>From a quick read of NEWS and man diff...


- sslprotocolversion
Counter to fm manpage, openssl supports through TLSv1.2 since 1.0.1.
So perhaps AUTO should have/doc a version order/pref/default in
there now. And have 1.x options. I don't know much on that to say
(other than noting the apparrent tls.bigger_num -> ssl3 history in
reverse).

Ssl/tls version was separate from the socket(wrapped)/starttls init
point anyway afaik so this breakout is nicer.

If fm is doing auto negotiations of things, its debug mode should
print whatever was finally agreed upon as confirmation and for later
use in fixed mode.

Maybe shorten to 'sslprotover'.


- sslmode
Man page: this is a subparameter, not the entire option, so...
change from
 starttls=may: this option is implicity upgraded to starttls=must.
to
 starttls=may: if starttls=may is specified, it is implicitly
 upgraded to starttls=must.

At the top in this man, starttls=may is *not* the default if below
at that subparameter sslcertck is also default thus forcing
starttls=must.


- sslcertck -> starttls default, wrapped legacy
I agree starttls is the 'new way' but the installed server base
merits retaining wrapped as the default on the standalone ports.
ie: how often does one see starttls on (25/110/143) advertised.
Wrapped was interim crypto till starttls could be implemented, but
now it seems used to guarantee buggy/partial/cleartext implementations
are never used.


- I presume this sort of custom ability still exists as needed:
service 465 + protocol imap + sslmode none


- sslcertck / sslfingerprint
These two sections mention failing regardless of the other. That
is good for high combined security [1], but I think there may be a
conflict... there may be a case, perhaps in a corporate thing, where
the signing cert isn't available but the print is documented. You'd
want the print to pass it and the certcheck (in the presence of a
print) to have a tri-option like...
sslcertck = abort | warn | off

[1] With 6.3.26 I still use both sslcertck (with an add upon need
from empty systemwide subject hashed certs dir) and sslfingerprint.
People can go further with only a certfile/certpath per server.


- Some people might want to use OCSP. Perhaps even when using cert
prints, checkfiles, etc... to alert them to some management or risk
issue for which the apparent server cert hasn't been changed out
yet. Firefox has an example OCSP preferences panel. CRL/OCSP is
maybe only mentioned as an aside in the man page, without saying
what CRL/OCSP and other verification/validation process/parameters
are checked with certs. That is maybe in the SSL README's, didn't
look.

sslremotecheck ocsp = abort | warn | off
sslremotecheck crl = abort | warn | off

A similar model may be thought of regarding any certificate
observatories / transparencies that may be coming online.

sslremotecheck observ = abort | warn | off


- sslcertfile
Man says 'in addition to sslcertpath' twice.

My 2013/07/28 note about PFS had some examples for people
to see what their server works with. Some more links:
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations


- pidfile /dev/null

Sometime back there was early talk on parallel. I run some things
in parallel. A simple disable key would be nice. Right now it's in
form of: --pidfile $(mktemp ...), which is actually further wrapped
in shell to check mktemp before fm exec. /dev/null doesn't work there
but would suffice as key to avoid open/write/unlink and allow para.