From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.bugs Subject: bug#10904: 24.0.93; Infinite loop in GnuTLS code during Gnus nnimap-initiated SSL handshake Date: Wed, 21 Mar 2012 11:40:09 -0400 Message-ID: References: <87haxk3dce.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1332344556 23586 80.91.229.3 (21 Mar 2012 15:42:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Mar 2012 15:42:36 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , 10904@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 21 16:42:33 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SANgF-0005yZ-GR for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Mar 2012 16:42:31 +0100 Original-Received: from localhost ([::1]:36735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SANgE-000591-S5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Mar 2012 11:42:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SANg9-000587-MU for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2012 11:42:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SANg4-0000YL-AP for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2012 11:42:25 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SANg4-0000YG-6z for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2012 11:42:20 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SAO9l-0000ga-Ut for bug-gnu-emacs@gnu.org; Wed, 21 Mar 2012 12:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Fitzsimmons Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Mar 2012 16:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10904 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10904-submit@debbugs.gnu.org id=B10904.13323463252549 (code B ref 10904); Wed, 21 Mar 2012 16:13:01 +0000 Original-Received: (at 10904) by debbugs.gnu.org; 21 Mar 2012 16:12:05 +0000 Original-Received: from localhost ([127.0.0.1]:59801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SAO8o-0000er-1g for submit@debbugs.gnu.org; Wed, 21 Mar 2012 12:12:05 -0400 Original-Received: from mail-gx0-f172.google.com ([209.85.161.172]:33004) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SAO8e-0000eU-0k for 10904@debbugs.gnu.org; Wed, 21 Mar 2012 12:12:00 -0400 Original-Received: by ggmi1 with SMTP id i1so1027809ggm.3 for <10904@debbugs.gnu.org>; Wed, 21 Mar 2012 08:41:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:x-gm-message-state; bh=HHRppftmfhveY+Kj3p/DgleLX1bMrqcp4uU/X52yT2c=; b=aPoc52okTNnSR6edpPrqm7drjBZTaM3ssaA932ZeD3pylQ/l6LReYQLcxoWC9YbwPc lE+9x3nIycwRlaHxJiNGI8HXLUmHI2mAFkCC82ibiVMYqbicR3zzmkYrWPSPrBODH/hC DE/XWq2OO1OEK19OwthR8FAY3Km95qkRRfntYGho4zF+efYcPKBZb6f5QTdomntiBnHo x5enLtHGRw8i26UvKNPSMIGUFHYb+/O5rSuftGfutTSKu3RqHW8fX/qtEpfVJgZC/G8v 8ZLV9C3JMaYuu6wiI/YCIF9wt/fArGQYW+f82D3wccZD8vm/bU3EeRnEs9nJD3tvoN8Z bcrg== Original-Received: by 10.50.170.97 with SMTP id al1mr3141299igc.33.1332344468841; Wed, 21 Mar 2012 08:41:08 -0700 (PDT) Original-Received: from ducky.fitzsim.org (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by mx.google.com with ESMTPS id vr4sm3213946igb.1.2012.03.21.08.40.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 08:41:02 -0700 (PDT) In-Reply-To: <87haxk3dce.fsf@lifelogs.com> (Ted Zlatanov's message of "Mon, 19 Mar 2012 09:54:57 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-Gm-Message-State: ALoCoQn176ygJ6QyTsWCOYLmTz/wIzxsMk5I91+nXawdM9Q/FxYgi0ROcgQD32Q+2nyUNheNJSsP X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:57921 Archived-At: Ted Zlatanov writes: > On Sat, 03 Mar 2012 15:56:59 +0100 Lars Magne Ingebrigtsen wrote: > > LMI> Thomas Fitzsimmons writes: > LMI> The error seems to be this? > >>> gnutls.c: [4] REC[0x90155c8]: Decrypted Packet[1] Handshake(22) with >>> length: 3404 >>> >>> gnutls.c: [3] HSK[0x90155c8]: CERTIFICATE was received. Length >>> 3400[3400], frag offset 0, frag length: 3400, sequence: 0 >>> >>> gnutls.c: [2] ASSERT: >>> /home/fitzsim/sources/gnutls-3.0.8/lib/gnutls_buffers.c:1037 >>> >>> gnutls.c: [1] Received unexpected handshake message 'CERTIFICATE' >>> (11). Expected 'SERVER HELLO' (2) >>> >>> gnutls.c: [2] ASSERT: >>> /home/fitzsim/sources/gnutls-3.0.8/lib/gnutls_handshake.c:1226 >>> >>> gnutls.c: [2] ASSERT: >>> /home/fitzsim/sources/gnutls-3.0.8/lib/gnutls_handshake.c:2432 >>> >>> gnutls.c: [0] (Emacs) fatal error: An unexpected TLS handshake packet >>> was received. > > LMI> That is, GnuTLS expects SERVER HELLO, but gets CERTIFICATE from the IMAP > LMI> server. > > LMI> Does anybody know what this might mean? > > (sorry for the late reply) > > It seems like a buggy server or something in GnuTLS itself. I have > never seen this problem before and the lockup is happening in the GnuTLS > internals, where Emacs doesn't play at all (we use the GnuTLS API in a > very straightforward way). > > Thomas, can you open a connection to this server with the GnuTLS > command-line tools (gnutls-cli)? That will reduce the problem to Emacs > vs. GnuTLS. I did some more investigation using the command line tools. It turned out that the IMAP server hostname was resolving to one of a set of Microsoft Exchange front-end servers. GnuTLS would fail to connect to some of the front-end servers but not to others. This explained why I would only see the issue sometimes (about half the time). By explicitly pointing in /etc/hosts at one or another front-end server I was able to make the GnuTLS connection either pass or fail consistently. Then I tried "openssl s_client" and it worked on both GnuTLS-passing and GnuTLS-failing servers. The servers Gnus failed to access reported: [...] --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DES-CBC3-SHA Session-ID: 56EFB2D45A0A7A15F173CE086AC0A754016BA00300602F30B47273E565792400 Session-ID-ctx: Master-Key: CD97CB5CB685B42815C8FB056032ABF03C890B42790A07B570E6ED93AEC70D81970EE344265C133100D84BB3789E6B5D Key-Arg : None Krb5 Principal: None Start Time: 1332336762 Timeout : 300 (sec) Verify return code: 0 (ok) --- * OK [...] and the ones it could access reported: [...] --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: Session-ID-ctx: Master-Key: B6A8BCC0224B72A00A34435DEA66580BD5BFA0FA5D1467471E8070968F206134B410715AE8808C754000B9F1BC1BBD84 Key-Arg : None Krb5 Principal: None Start Time: 1332271498 Timeout : 300 (sec) Verify return code: 0 (ok) --- * OK [...] All of the front-end Exchange servers reported the same version string but some (the failing set) were configured with the DES-CBC3-SHA cipher and others (the passing set) were configured with the RC4-MD5 cipher. Then I went back to gnutls-cli to experiment with its supported ciphers list. I discovered that adding the --priority "PERFORMANCE" option resulted in success for previously-passing and previously-failing server connections. The result from gnutls-cli for the previously-passing server configuration after I added --priority "PERFORMANCE" was: - The hostname in the certificate matches ''. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: ARCFOUR-128 - MAC: MD5 - Compression: NULL - Session ID: (null) - Channel binding 'tls-unique': c38c134cd89ef6f0ba9c51f9 - Handshake was completed - Simple Client Mode: [...] - Received[104]: * OK [...] which was the same as without the --priority option. However the result for the previously-failing server configuration after I added --priority "PERFORMANCE" was: - The hostname in the certificate matches ''. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: ARCFOUR-128 - MAC: SHA1 - Compression: NULL - Session ID: 35:B3:B2:CE:52:FF:00:D3:0F:DF:0C:25:E0:27:A8:CF:02:9D:17:03:00:14:1C:5B:F3:0F:46:86:02:69:49:64 - Channel binding 'tls-unique': 63b922f2b761712f1f25c40e - Handshake was completed - Simple Client Mode: [...] - Received[109]: * OK [...] so --priority "PERFORMANCE" worked around the handshake failure by selecting a cipher other than the failing DES-CBC3-SHA. In Emacs I worked around the issue by customizing gnutls-algorithm-priority to "performance". Now Gnus always connects successfully. But there are still two issues: 1) GnuTLS fails to handshake with a server that uses the DES-CBC3-SHA cipher, whereas OpenSSL succeeds 2) If gnutls.el fails to handshake with a server then Emacs enters an infinite loop retrying the handshake Thomas