Re: [TLS] ESNI interoperability questions

Rob Sayre <sayrer@gmail.com> Sun, 27 October 2019 21:34 UTC

Return-Path: <sayrer@gmail.com>
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 38F2E12006B for <tls@ietfa.amsl.com>; Sun, 27 Oct 2019 14:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 K78VK6jtjt_R for <tls@ietfa.amsl.com>; Sun, 27 Oct 2019 14:34:00 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23064120052 for <tls@ietf.org>; Sun, 27 Oct 2019 14:34:00 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id s6so2884802iln.0 for <tls@ietf.org>; Sun, 27 Oct 2019 14:34:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xRV1dyrf08ac74Rszq/gN7xdvRDyoi+nPXoCA7N1KeY=; b=Jo8QW2/iRxdasgCLMbiDpMBC4ZrPKhuHfP4nnjIhY+wg+Xc7f62lKuvUCu2+cpF6MB w5qMO+3kUcnquW/8THvD69i0mPETgnNsu750xWeVsAUZtecAAOQGRNHkJ0508NCwhMxw Q1BSaYCIqjIZNkFEbawFuBGHpz0s99PLdtEiazbBl/L84x7oF5gAHZr1EC1CRcvmi7OH 0ItgPjb4Zc1ajAhnbnenWqMVYUx7wxaObrVt2oI/tGvMoJUE3X1960aFwWR4skKL5Wrz 2yUUJvv4+pGXY9BDzmXTYlZA8+fdeZa3QjblWwpJ8eIJHZUyecw3e2JuBPVk26i8Y0ep D1vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xRV1dyrf08ac74Rszq/gN7xdvRDyoi+nPXoCA7N1KeY=; b=A5en5uqDubT9XSrnIB7rCQOQoinBMyiSVnBe2IOfASzkwGyxrbaGQTKlNkAOGwyHEG YaATIC8eDoFoDQyYchQcDwMidYm/4hKtZMJsAi924ZpU71CcwKDU2fX8xn89HWW7npze 88HOvcBmhjTLNyQcVEV97U/j7ZEJS2OTBXdJLNuf8/78y+eBwwr+ejBcCSnaJvmdYivv BVu3on8Ak7OYrnCfVuzdkPtIgP0C3cVyuDWSmt3Ww7AFtpHYfKWTeu6RP4O+udfmMYLa 2grj6ZhAM3AOSBkp7YUOB36TXqHg2iaXYOwYTaCtGiIP6UDNhmAvgv+i2GrlcETGtlGh mqsg==
X-Gm-Message-State: APjAAAUfBhZp0VYGIisym3GGM8mbukbYMOEZnREIK8FgrUlArEMTnl4r 8DVAFX4iKQUY/pK1TwjfqhuaYh4ppC+Ahod6w6ybc0MrGXOs6Q==
X-Google-Smtp-Source: APXvYqzimOPVPdejK9xYb5opkq1FP8iR7LlxOZAch8W4U0+qAl79E1/UjKPqdkSyYfan3aJfU2x+W7kK0jt2aC999tI=
X-Received: by 2002:a92:8394:: with SMTP id p20mr17362486ilk.73.1572212038850; Sun, 27 Oct 2019 14:33:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6SxUN5o+SXKGVoFGD_hkhprjnqj4RtzsS0+fFKFWJZOnBg@mail.gmail.com> <CAChr6SysjJJ2VXmqRjauMsTUoDSZU0yAH7Z3KV0A8BUhPTEFrA@mail.gmail.com>
In-Reply-To: <CAChr6SysjJJ2VXmqRjauMsTUoDSZU0yAH7Z3KV0A8BUhPTEFrA@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Sun, 27 Oct 2019 14:33:45 -0700
Message-ID: <CAChr6Swrh3aaAyoewphNQwRRcHPsPfbp5wFkUn80cE2jG-tOLA@mail.gmail.com>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000165f1d0595eb244f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qM45jVBXu4g6oWkOwIei9CX8C6Q>
Subject: Re: [TLS] ESNI interoperability questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 27 Oct 2019 21:34:03 -0000

Hi,

This code works with medium.com (hosted by Cloudflare). I was previously
testing with a parked domain. Maybe there's some signaling needed when the
handshake fails based on Split Mode / Shared Mode configuration.

thanks,
Rob


On Sat, Oct 26, 2019 at 7:43 PM Rob Sayre <sayrer@gmail.com> wrote:

> As an update,
>
> I seem to be able to negotiate a handshake with "only.esni.defo.ie", but
> I must be making a mistake in my ClientHello. Wireshark sees Firefox's
> ClientHello as TLS 1.3, but mine only shows up as TLS 1.0, although the "
> only.esni.defo.ie" ServerHello does show up as TLS 1.3. You check out the
> details on that host at https://defo.ie/ .
>
> My client fails to read application data after that, although the server
> does seem to send it.
>
> You can check out my fork of Rustls here:
> https://github.com/grafica/rustls
>
> If you then do something like:
> $ cd rustls/rustls-mio/
> $ cargo run --example esniclient
>
> you should see some ESNI traffic. Some of the code in the fork is a little
> messy so far, but it's still in the "make it work" phase. :)
>
> thanks,
> Rob
>
>
> On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>> Hi,
>>
>> I think I have a working ESNI client, but I'm encountering a strange
>> error testing with Cloudflare.
>>
>> I initially tested with "cloudflare.com", but found this was a bad idea,
>> because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI
>> triggered no errors.
>>
>> When my client sends an ESNI to a Cloudfront-fronted domain, I get a
>> handshake_failure error (40). According to the -02 draft, this should only
>> happen if the server fails to negotiate TLS 1.3. I've got my client
>> configured for TLS 1.3 only, so this shouldn't be an issue. When I add an
>> unencrypted SNI to an otherwise identical ClientHello, everything works
>> over TLS 1.3. If there are problems with my ESNI encryption, I should see
>> other errors. Things like "illegal_parameter" or "decrypt_error", right?
>>
>> In Wireshark, I can at least see that my encrypted_server_name extension
>> matches Firefox's cipher and key share entries, and the lengths of
>> record_digest and encrypted_sni are the same. Firefox does send some
>> extensions I don't, like ALPN. Does the absence of unencrypted SNI imply
>> the presence of other extensions?
>>
>> I also wondered about extension order. Since the ClientHello.key_share is
>> part of the ESNI calculation, does it need to appear first in the
>> extensions list?
>>
>> thanks,
>> Rob
>>
>