Re: [TLS] Update on TLS 1.3 Middlebox Issues

Matt Caswell <matt@openssl.org> Mon, 06 November 2017 14:37 UTC

Return-Path: <matt@openssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5113FC2B for <tls@ietfa.amsl.com>; Mon, 6 Nov 2017 06:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xky9FyTP8L2Z for <tls@ietfa.amsl.com>; Mon, 6 Nov 2017 06:37:56 -0800 (PST)
Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C7B13FC28 for <tls@ietf.org>; Mon, 6 Nov 2017 06:37:55 -0800 (PST)
Received: from [10.33.10.6] (unknown [104.238.169.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id EEB83E65C5 for <tls@ietf.org>; Mon, 6 Nov 2017 14:37:53 +0000 (UTC)
To: tls@ietf.org
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com> <CAOp4FwSJ_pufvazekzndKVX_=uf3rUWZYBBC6wpQL0AdCjGvOw@mail.gmail.com>
From: Matt Caswell <matt@openssl.org>
Message-ID: <10e57e9d-af2a-0d6c-9e43-95afb5604e37@openssl.org>
Date: Mon, 6 Nov 2017 14:37:53 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAOp4FwSJ_pufvazekzndKVX_=uf3rUWZYBBC6wpQL0AdCjGvOw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2cgUJtOYL2z8xv1tNezd4ffrA48>
Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 14:37:58 -0000


On 06/11/17 14:31, Loganaden Velvindron wrote:
> On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla <ekr@rtfm.com>; wrote:
>> Hi folks,
>>
>> In Prague I mentioned that we were seeing evidence of increased
>> failures with TLS 1.3 which we believed were due to middleboxes. In
>> the meantime, several of us have done experiments on this, and I
>> wanted to provide an update.
>>
>> The high-order bit is that *negotiating* TLS 1.3 seems to cause
>> increased failures with a variety of middleboxes (it’s generally safe
>> to offer TLS 1.3 to servers which don’t support it). The measured
>> incremental error rates vary quite a bit, ranging from minimal
>> (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using
>> a slightly different methodology (organic versus forced traffic) and
>> different populations (mobile, desktop, enterprise, etc), but it does
>> seem like there is a nontrivial failure rate. At this point, we have
>> two options:
>>
>> - Fall back to TLS 1.2 (as we have unfortunately done for previous releases)
>> - Try to make small adaptations to TLS 1.3 to make it work better with
>> middleboxes.
>>
> 
> We (hackers.mu) ran tests across different Mobile & FTTH providers,
> and large wifi hotspot vendors across the island of Mauritius:
> 
> Mauritius Telecom FTTH: no issues with TLS 1.3
> Emtel (mobile): no issues with TLS 1.3
> Mauritius Telecom (mobile): no issues with TLS 1.3
> AlwaysOn: Gateway has issues with TLS 1.3 (draft-18), when forcing all
> HTTPS traffic to their HTTPS web-based portal.
> 
> Before authentication via SSL/TLS:
> 
> 
> ./bin/openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3
> -CApath=/etc/ssl/certs/

Note that the "-tls1_3" option to s_client forces *only* TLSv1.3 to be
negotiated. Therefore, if the web based portal doesn't also support
TLSv1.3 then this will fail.

Matt


> CONNECTED(00000003)
> 140130750743872:error:14094410:SSL routines:ssl3_read_bytes:sslv3
> alert handshake failure:ssl/record/rec_layer_s3.c:1471:SSL alert
> number 40
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 184 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> SSL-Session:
> Protocol : TLSv1.3
> Cipher : 0000
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1509976305
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> Extended master secret: no
> ---
> 
> I'm reaching out to the AlwaysOn service, which appears to be quite
> well popular in South Africa as well.
> 
> //Logan
> C-x-C-c
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>