reverting recent SSL-related patches

[Eygene Ryabinkin]

Michael, good day.

Tue, Jan 13, 2015 at 08:48:43AM +0100, Michael Vogt wrote:
> I feel strongly that the user should not have to configure a default
> ca-certificates anywhere in its configuration file. I don't have to do
> this with e.g. wget or curl or ldap, there is a default
> (distro/os specific) thats used unless the user overrides this.

That is the point of our discuission with Nicolas.  But the thing
with the default CA bundle is currently twofold.

There is cert_fingerprint that behaves weird when default CA bundle is
introduced; that's the problem you're trying to address below and I'll
comment on that below too.

There is a viewpoint of some security-minded people (but not all of
them) that even the default CA bundle should be made explicitely
selectable.  The underlying idea of that is trust: the whole X.509 CA
stuff is about of trust to small number of entities that are to be
behave correctly (CAs) rather than about trust to every certificate
(or, more correctly, anything that says "this public key belongs to
this ID"), the model on which SSH/PGP is relying (but both are
extending it in various ways).

So, when you're using curl that is configured to use default CA bundle
(if you'll glance over cURL's configure, you'll see that you should
enable its usage explicitely), it is your packager's/OS/own decision
and you basically put another trust component into a chain: "I trust
packager/OS that they provide a reasonable set of CAs that will be
trusted to identify other entities".  So, you trust that the trust (of
reasonable people who builts curl for you) in the provided CA set is
that good that you can rely on it.

Of course, it is better for users if default CA bundle (be there any)
will work out-of-the-box.  But the above-referenced viewpoint is a
different one: let users choose what they trust to explicitely.
I understand that most people just don't care or believe that things are
provided by the reasonable people, so it is safe to trust them.

My current intention is to give people who want out-of-the-boxiness
an easy way to once say
{{{
sslcacertfile = OS-DEFAULT
}}}
and live with available CA bundle, if any.

> I'm probably missing something here but it seems that for those users
> who have the fingerprint configured in the repo you simply unset
> self.ca_certs in WrappedIMAP4_SSL for this imap repository and reply
> entirely on the fingerprint. Something like (untested):
> 
> --- a/offlineimap/imaplibutil.py
> +++ b/offlineimap/imaplibutil.py
> @@ -145,6 +145,9 @@ class WrappedIMAP4_SSL(UsefulIMAPMixIn,
> IMAP4_SSL):
>          if 'fingerprint' in kwargs:
>              del kwargs['fingerprint']
>          super(WrappedIMAP4_SSL, self).__init__(*args, **kwargs)
> +        # fingerprint overrides the certs
> +        if 'fingerprint' in kwargs:
> +            self.ca_certs = None
>  
>      def open(self, host=None, port=None):
>          if not self.ca_certs and not self._fingerprint:
> 
> I imagine that people who use this option do not trust the cert chain
> and use the fingerprint as a sort of cert-pinning so this should do
> exactly what they want.

Actually, sslcacertfile and cert_fingerprint are ortogonal in the sense
that they can both be present and this adds a way for people to detect
changes of remote certificate (e.g. for rekeying) and review what happens.
So there is a use-case for people who have both options enabled.

http://codelabs.ru/patches/offlineimap/2015-SSL-properly-configure-certificate-and-fingerprint-validation.diff
does what you mean, but only in the case when sslcacertfile hadn't been
explicitely configured.

But Nicolas's point that I am currently support is that approach makes
the default OS bundle location to be not a strict default: it will be
used when there is no cert_fingerprint and it won't be used when people
waht fingerprinting.  It creates possible point of confusion, so our
recent conversation in this topic and out-of-list were dedicated to
finding more sane solution.  Seems like we had found one (that I was
describing above), but I'll need to turn it into code and test.

Once the patch will be ready and tested, I'll post it here for review
of interested parties, since there seems to still be some ground for
discussion, but it is better to continue them having working
implementation of proposed solution.

Thanks!
-- 
rea