[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnutls tofu support? or even --insecure?
From: |
Nix |
Subject: |
Re: gnutls tofu support? or even --insecure? |
Date: |
Wed, 12 Aug 2015 14:19:45 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
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)