Re: [TLS] Suspicious behaviour of TLS server implementations

Ilari Liusvaara <> Thu, 22 September 2016 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C9C412B137 for <>; Wed, 21 Sep 2016 23:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LEYZFbfbTCaw for <>; Wed, 21 Sep 2016 23:54:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE64712B927 for <>; Wed, 21 Sep 2016 23:54:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 679E011020 for <>; Thu, 22 Sep 2016 09:54:45 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id EHLuitbT62w6 for <>; Thu, 22 Sep 2016 09:54:45 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2459727B for <>; Thu, 22 Sep 2016 09:54:45 +0300 (EEST)
Date: Thu, 22 Sep 2016 09:54:41 +0300
From: Ilari Liusvaara <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Sep 2016 06:54:53 -0000

On Thu, Sep 22, 2016 at 05:11:39AM +0000, Peter Gutmann wrote:
> Martin Thomson <> writes:
> >The advantage with deploying a new protocol is that you can be strict. If, 
> >for example, all of the browsers implement TLS 1.3 and are strict, then 
> >Amazon won't be able to deploy a buggy 1.3 implementation without noticing 
> >pretty quickly.  You might suggest that that's aspiration to the point of 
> >delusion, but in fact it worked out pretty well with HTTP/2 deployment.  We 
> >didn't squash ALL of the nasty bugs, but we got most of them.
> It also means you're going to be in for a rude shock when you encounter the
> ocean of embedded/SCADA/IoT devices with non-mainstream TLS implementations.

That did not check for interop with any mainstream TLS library?

Also, code to "recover" tends to introduce security issues if used in
security protocols. Just because I don't have to deal with simple bugs
like buffer overflows leading to RCE or data races does not mean I can
do whatever I want and expect the code to have low number of security
issues. The existing stuff is way more than enough.

(Just fixed a bug where NotBefore/NotAfter of dedicated OCSP responder
certificate were not validated... Not related to recovery in any way,
but still some special code).

> The reason why HTTP/2 "works" is that it essentially forked HTTP, HTTP/2 for
> Google, Amazon, etc, and the browser vendors, and HTTP 1.1 for everything 
> else that uses HTTP as its universal substrate.  As a result there will be 
> two versions of HTTP in perpetuity, HTTP 1.1 and HTTP-whatever-the-current-
> version-is.

Well, the problem you encounter first with HTTP/2 is that it really
dislikes unencrypted operation. Which impiles you pretty much need 
encryption. Which impiles you pretty much need the WebPKI certificate
model... Which tends to be poor match for anything except named servers
on the internet, which tends not be suitable for IoT stuff...

> (Should I mention TLS-LTS here? :-).