Re: gnutls tofu support? or even --insecure?

[Nix <nix@esperi.org.uk>]

On 11 Aug 2015, Eli Zaretskii outgrape:

>> So GnuTLS 3.2.21 has randomly (as in, I haven't updated it or touched
>> anything) started rejecting all connections to my work mailserver with
>> an apparently totally spurious certificate validation error:
>> 
>> - Status: The certificate is NOT trusted. The certificate issuer is unknown.
>> *** PKI verification of server certificate failed...
>> *** Fatal error: Error in the certificate.
>> *** Handshake has failed
>> GnuTLS error: Error in the certificate.
>> 
>> (when it's a perfectly normal Verisign cert in my certificate store, as
>> far as I can tell).
>> 
>> Life is *far* too short to figure out why this is (the whole thing is
>> happening over a VPN anyway, I trust this connection! I just can't tell
>> GnuTLS that!), so the thing that will save me is apparently --tofu,
>
> Before you press the panic button, wouldn't it be better to try to
> find out why GnuTLS started failing?  My first suspect is the
> certificate bundle.

It was the certificate bundle. I dug out the relevant new root cert and
added it, and then things started working -- briefly. Now I've got into
a new state where it's failing in Emacs ("error in the pull function",
as usual), but working with gnutls-cli...

>                      Since this is Emacs 25.0 and GnuTLS > 3.0.20,
> gnutls.c is supposed to use the system-stored certificates, but does
> it?

Yes.

>      The GnuTLS logs should show: if something goes wrong with that,
> you should see a log message saying something like "setting system
> trust failed with code NNN".

I jacked up the gnutls-log-level to 2 and it failed:

Opening connection to xxxxx via tls...
gnutls.c: [1] (Emacs) connecting to host: xxxxx
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [2] (Emacs) allocating x509 credentials
gnutls.c: [2] (Emacs) using default verification flags
gnutls.c: [1] (Emacs) setting the trustfile:  /etc/ssl/ca-bundle.pem
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string
gnutls.c: [audit] Note that the security level of the Diffie-Hellman key exchange has been lowered to 256 bits and this may allow decryption of the session data

gnutls.c: [2] ASSERT: gnutls_constate.c:583

gnutls.c: [2] ASSERT: gnutls_buffers.c:1078

gnutls.c: [2] ASSERT: gnutls_buffers.c:521

gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
gnutls.c: [2] ASSERT: gnutls_buffers.c:1078

gnutls.c: [2] ASSERT: gnutls_buffers.c:521

gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
gnutls.c: [2] ASSERT: gnutls_buffers.c:1078

gnutls.c: [2] ASSERT: gnutls_buffers.c:521

gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
gnutls.c: [2] ASSERT: gnutls_buffers.c:1078

gnutls.c: [2] ASSERT: gnutls_buffers.c:521

gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
gnutls.c: [2] ASSERT: gnutls_buffers.c:1078

gnutls.c: [2] ASSERT: gnutls_buffers.c:521

gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again.
gnutls.c: [2] ASSERT: gnutls_buffers.c:1078

gnutls.c: [2] ASSERT: gnutls_buffers.c:336

gnutls.c: [2] ASSERT: gnutls_buffers.c:521

gnutls.c: [2] ASSERT: gnutls_record.c:1026

gnutls.c: [2] ASSERT: gnutls_record.c:1146

gnutls.c: [2] ASSERT: gnutls_buffers.c:1329

gnutls.c: [2] ASSERT: gnutls_handshake.c:1414

gnutls.c: [2] ASSERT: gnutls_handshake.c:2701

gnutls.c: [1] (Emacs) fatal error: Error in the pull function.
gnutls.c: [2] errno: 32

gnutls.c: [2] ASSERT: gnutls_buffers.c:195

gnutls.c: [2] ASSERT: gnutls_buffers.c:653

gnutls.c: [2] ASSERT: gnutls_record.c:564

gnutls.el: (err=[-54] Error in the pull function.) boot: (:priority NORMAL :hostname xxxxx :loglevel 2 :min-prime-bits 256 :trustfiles (/etc/ssl/ca-bundle.pem) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :callbacks nil)
Unable to open server nnimap+xxxxx due to: GnuTLS error: #<process *nnimap*>, -54

(Errno 32 is -EPIPE.)

I jacked the log level up to 3, and everything worked! It looks like
control flow paths are quite different after gnutls_buffers.c:1078...

This is consistent behaviour, not a one-off.

This looks like a bug somewhere -- I'll report it as such shortly, after
spending a bit of time seeing if the bug is obvious enough that I can
fix it myself and just send a patch. I have a horrible workaround now,
which means I can at least get my work done today while sitting in a
nice pleasant Emacs :) -- always assuming that the other end doesn't
change again and make this problem go away for good.

> Or maybe you made some change to your system, unrelated to Emacs,
> which somehow affected the system store of the certificates?

No changes -- howeer, work's email is up the creek to a greater or
lesser degree right now, so who knows what sort of weird edge case
gnutls is being hit with -- but still it is working for gnutls-cli and
Thunderbird and the web client and everything but Emacs at this point :(

> Or maybe one of your customizations forced it to use the external
> bundle of certificate files, and that bundle is outdated or missing?
> Again, there should be signs of that in the logs.

That was definitely true at first: I found the bundle by stracing
gnutls-cli, and put one where it was expecting.

> So I'd suggest to set gnutls-log-level to 10, and show all the logs
> you get in *Messages* while initiating such a failing connection.

Tried that. This is, it seems, one of those bugs that goes away when you
look more closely at it.

> P.S. I have no opinions and no objections to applying the patch you
> mentioned, but AFAICT the discussion back then raised a few issues
> which the OP promised to work on.  Was there ever an updated patch?

Not that I've been able to find.

-- 
NULL && (void)