reverting recent SSL-related patches

[Nicolas Sebrecht]

On Mon, Jan 12, 2015 at 06:24:08PM +0300, Eygene Ryabinkin wrote:

> My thinking is the following:
> 
>  1. if there is just a default (or non-default) CA bundle and IMAP
>    server's certificate can't be verified with it, an error will occur
>    (OI will error out with X.509 verification error); this is the
>    default and expected behaviour;
> 
>  2. prior to the introduction of default CA bundle, users with just
>    cert_fingerprint enabled will get no CA root verification (obviously);
> 
>  3. making cert_fingerprint to inhibit the implicit usage of default
>    bundle retains the standard behaviour [2] and explicit usage (either
>    full pathname or OS-DEFAULT meta-value) retains the expected behaviour
>    [1] too;
> 
>  4. this undermines the notion of a default CA bundle and that's the
>    problem you're pointing our and it is the real one.  I had tried
>    to do my best in documenting this in offlineimap.conf, but I realize
>    that it won't be enough in many cases.

Yes.

> However, I had tried to build the model for the class of users that
> will be fooled by this behaviour (taking for granted that they don't
> read the documentation).  Basically, cert_fingerprint is a
> quick'n'dirty way to solve the problem of CA roots and the only
> affected users are those who are using this option.  Moreover, to be
> fooled about default behaviour they should know what is default CA
> bundle, because the only broken expectation is that the bundle will be
> still used to verify connection even when cert_fingerprint is used.
> And these users will have no sslcacertfile set, so either
> 
>  - they had never tried to use real CA roots (and found out that
>    default CA bundle errors out for them) and found relief in
>    cert_fingerprint;
> 
>  - they come from pre-default bundle times, so they are fine with
>    the fact that their server's certificate won't be verified;
> 
>  - they are fine with default bundle, but believe that cert_fingerprint
>    will add extra protection layer.
> 
> Only the latter ones seem to be really fooled by OI behaviour I am
> trying to introduce, expectation of other aren't harmed.  It is likely
> that they will read the documentation, but I am still not relying
> on this.

I disagree a bit. My approach is just to NOT introduce regressions
without making any assumptions of what the users did or not. The first
regression comes from the OS-default-CA series.

The second point is about not confusing the users with a complex CA Cert
sub-system that sometimes take defaults or not.

Since your fixed the regression and that I expect the documentation
avoid confusions enough, I think it is good enough to be merged.

> Theoretically, I can modify the patch to have the full processing
> of both CA bundle and cert_fingerprint, falling back to bundle-less
> verification that is supplemented with warning about problems with
> implicitely-configured CA bundle.  This won't break any compatibility
> with prior behaviour.

I expect this to add too much complexity in the code for few use cases
in the long run.

> Or I may break the compatibility and introduce a way to disable default
> CA bundle, but users will then be forced to modify their configuration.
> 
> Or there can be new option that enables default CA bundle, but that is
> off by-default.

I'm not convinced because it fails at the main purpose of having
defaults: having to enable defaults make them options, not a default.

> Not that I am trying to convince anyone that the current approach is
> the best one, just thinking loudly in a hope that either I or anyone
> else will be striked by the good idea about this.
> 
> 
> The reason why I do care for default CA bundles is that it seems that
> people and OS really care more for security in the X.509 world and
> it is not something exotic to have distro with properly-configured
> default CAs.  So, the more out-of-the-box it will be, the more
> likelihood of spotting malicious actions there'll be.  And that's the
> right thing.

Thanks for sharing. I didn't give this topic the full thinking it would
require but I believe you have the best approach.

> I'll then postpone the last patch to allow for some more thinking.
> Feel free either to wait for some time or to remove the default CA
> bundle commits -- I'll reintegrate them when/if the time will come.

Thinking a bit more, there's no more regression, right? Apply them. We
will have the time to revert back later in this cycle (before the next
stable release) if we change of minds.

-- 
Nicolas Sebrecht