Re: [ietf-smtp] TLS1.3

Viktor Dukhovni <> Tue, 05 May 2020 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A62943A0799 for <>; Tue, 5 May 2020 06:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oVJj0L_8EgKr for <>; Tue, 5 May 2020 06:50:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E99463A0798 for <>; Tue, 5 May 2020 06:50:22 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 047AA29D924; Tue, 5 May 2020 09:50:21 -0400 (EDT)
Date: Tue, 5 May 2020 09:50:20 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <>
Subject: Re: [ietf-smtp] TLS1.3
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 May 2020 13:50:25 -0000

On Wed, Apr 29, 2020 at 06:02:13PM -0400, Sam Varshavchik wrote:

> > It emits a fatal "unexpected message" alert.  Turn off the
> > client-cert request, and it works fine.
> >
> > Name withheld to protect the guilty.
> I wouldn't necessarily blame the operator. It's almost a sure bet that  
> they're using OpenSSL, and this developer's opinion is that OpenSSL is one  
> of the worst, most confusing, and the most poorly documented API libraries  
> in existence.

I are of course free to vent, but on this particular issue the
frustration is misdirected.  The OpenSSL TLS client silently ignores
solications for client certificates when none are configured at the
client.  It is up to the server to then accept or deny the handshake.
[ Rare applications that want to select certificates dynamically can
register for a callback, but then the decisions are theirs to make. ]

> Things  
> have reached the stage where it's been determined that the OpenSSL library  
> is reporting an error code that its own documentation describes thusly:
>           Some non-recoverable, fatal I/O error occurred. The OpenSSL error
>           queue may contain more information on the error. For socket I/O on
>           Unix systems, consult errno for details.
> And, immediately after that, the code in question does "consult errno", and  
> finds that it's zero. No error has occured, according to the operating  
> system.

This is likely TLS session termination without a TLS close notify, i.e.
potentially vulnerable to truncation attacks.  An empty read on EOF does
not set errno.  In OpenSSL 1.1.1e there was a fix for that, to make it
an SSL_ERROR_SSL, but that turned to have too many backwards compatibility
issues, so it got rolled back in 1.1.1f.