TLS problem: gnutls-e-again

TLS problem: gnutls-e-again

[Magnus Henoch]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Hi all,

I just updated to the latest master, and found that there are problems
establishing TLS connections. With jabber.el, this is what appears in the
messages buffer:

Connecting to xmpp.l.google.com:5222...
gnutls.el: (err=[gnutls-e-again] Resource temporarily unavailable, try
again.) boot: (:priority NORMAL :hostname gmail.com :loglevel 0
:min-prime-bits nil :trustfiles (/opt/local/share/curl/curl-ca-bundle.crt)
:crlfiles nil :keylist nil :verify-flags nil :verify-error (:hostname . t)
:callbacks nil)
magnus.henoch@gmail.com: connection lost: ‘STARTTLS negotiation failed:
GnuTLS error: #<process jabber>, gnutls-e-again’

Unfortunately, my attempts at creating a self-contained test case have
failed so far... What jabber.el does, is that it opens an asynchronous
network connection (:nowait t), performs XMPP feature negotiation in
cleartext, and then attempts to do STARTTLS using gnutls-negotiate.

I can reproduce this on OSX as well as GNU/Linux:

GNU Emacs 25.1.50.4 (x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version
10.10.5 (Build 14F1509)) of 2016-03-05
GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2) of
2016-03-05

Any idea what might be wrong? Is there any more information that would be
helpful?

Regards,
Magnus

[-- Attachment #2: Type: text/html, Size: 1530 bytes --]

Re: TLS problem: gnutls-e-again

[Lars Magne Ingebrigtsen]

Magnus Henoch <magnus.henoch@gmail.com> writes:

> Connecting to xmpp.l.google.com:5222...
> gnutls.el: (err=[gnutls-e-again] Resource temporarily unavailable, try again.)
> boot: (:priority NORMAL :hostname gmail.com :loglevel 0 :min-prime-bits nil
> :trustfiles (/opt/local/share/curl/curl-ca-bundle.crt) :crlfiles nil :keylist nil
> :verify-flags nil :verify-error (:hostname . t) :callbacks nil)
> magnus.henoch@gmail.com: connection lost: ‘STARTTLS negotiation failed:
> GnuTLS error: #<process jabber>, gnutls-e-again’
>
> Unfortunately, my attempts at creating a self-contained test case have failed
> so far... What jabber.el does, is that it opens an asynchronous network
> connection (:nowait t), performs XMPP feature negotiation in cleartext, and
> then attempts to do STARTTLS using gnutls-negotiate.

On non-blocking sockets, gnutls-boot no longer waits for the connection
to complete.  But if you try to talk to it before it's completed, it
should block the communication until that has happened, so what function
is it that gets that return value?

Anyway, there should be a way to specify that you want TLS negotiation
to complete even on non-blocking sockets, so I've now added this to the
trunk.  It should probably fix your use case, too.

Could you try updating from git and running jabberd again?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: TLS problem: gnutls-e-again

[Magnus Henoch]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Magnus Henoch <magnus.henoch@gmail.com> writes: 
> 
>> Connecting to xmpp.l.google.com:5222...  gnutls.el: 
>> (err=[gnutls-e-again] Resource temporarily unavailable, try 
>> again.)  boot: (:priority NORMAL :hostname gmail.com :loglevel 
>> 0 :min-prime-bits nil :trustfiles 
>> (/opt/local/share/curl/curl-ca-bundle.crt) :crlfiles nil 
>> :keylist nil :verify-flags nil :verify-error (:hostname . t) 
>> :callbacks nil) magnus.henoch@gmail.com: connection lost: 
>> ‘STARTTLS negotiation failed: GnuTLS error: #<process jabber>, 
>> gnutls-e-again’ 
>> 
>> Unfortunately, my attempts at creating a self-contained test 
>> case have failed so far... What jabber.el does, is that it 
>> opens an asynchronous network connection (:nowait t), performs 
>> XMPP feature negotiation in cleartext, and then attempts to do 
>> STARTTLS using gnutls-negotiate. 
> 
> On non-blocking sockets, gnutls-boot no longer waits for the 
> connection to complete.  But if you try to talk to it before 
> it's completed, it should block the communication until that has 
> happened, so what function is it that gets that return value?

The symbol gnutls-e-again was returned from gnutls-boot, inside 
gnutls-negotiate.  It then called gnutls-errorp on it, which 
returned t, and thus an error was signalled.

> Anyway, there should be a way to specify that you want TLS 
> negotiation to complete even on non-blocking sockets, so I've 
> now added this to the trunk.  It should probably fix your use 
> case, too. 
> 
> Could you try updating from git and running jabberd again? 

That fixes the problem.  Thanks!

Regards,
Magnus

Re: TLS problem: gnutls-e-again

[Lars Magne Ingebrigtsen]

Magnus Henoch <magnus.henoch@gmail.com> writes:

> The symbol gnutls-e-again was returned from gnutls-boot, inside
> gnutls-negotiate.  It then called gnutls-errorp on it, which returned
> t, and thus an error was signalled.

Aha.  gnutls-errorp should say that e_again is an error.  I'll fix
that...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: TLS problem: gnutls-e-again

[Ted Zlatanov]

On Sun, 06 Mar 2016 10:20:32 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Magnus Henoch <magnus.henoch@gmail.com> writes:
>> The symbol gnutls-e-again was returned from gnutls-boot, inside
>> gnutls-negotiate.  It then called gnutls-errorp on it, which returned
>> t, and thus an error was signalled.

LMI> Aha.  gnutls-errorp should say that e_again is an error.  I'll fix
LMI> that...

Is it? Is it? Is it? Is it?

:)

Ted