Re: [TLS] Next protocol negotiation

Adam Langley <agl@google.com> Thu, 21 January 2010 11:04 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1095F3A6804 for <tls@core3.amsl.com>; Thu, 21 Jan 2010 03:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.227
X-Spam-Level:
X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLsZgmWGdFKT for <tls@core3.amsl.com>; Thu, 21 Jan 2010 03:04:20 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id B0B233A67A1 for <tls@ietf.org>; Thu, 21 Jan 2010 03:04:19 -0800 (PST)
Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id o0LB4Eb5032426 for <tls@ietf.org>; Thu, 21 Jan 2010 11:04:14 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264071854; bh=Urys0tzXi/mTnNQNmp/pIIW6yqw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=afWL8P2vmaBUhD2ATjAWu5tA1TeGfJ6t2MM8n7KmwDDWolm4zdnVfUuIeGDlKXy4F PZFCeOCPdEUnpoH9hoalw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=FmVl6Po4VK9lDOqu3OT0tzIk95DxrNcazbv+loVo8VX80Alh0kMDhbhiIpvQXp8og 7bibrtpQgOslkCu6ZRGKQ==
Received: from pzk38 (pzk38.prod.google.com [10.243.19.166]) by spaceape10.eur.corp.google.com with ESMTP id o0LB4C3Z022035 for <tls@ietf.org>; Thu, 21 Jan 2010 03:04:13 -0800
Received: by pzk38 with SMTP id 38so4771846pzk.9 for <tls@ietf.org>; Thu, 21 Jan 2010 03:04:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.117.1 with SMTP id p1mr897985wfc.185.1264071851874; Thu, 21 Jan 2010 03:04:11 -0800 (PST)
In-Reply-To: <DFA6B810-F1BF-4113-8615-3DBD9875790A@checkpoint.com>
References: <a84d7bc61001200520t4e3be7d4sb0bb614abb0b5e4e@mail.gmail.com> <DFA6B810-F1BF-4113-8615-3DBD9875790A@checkpoint.com>
Date: Thu, 21 Jan 2010 03:04:11 -0800
Message-ID: <a84d7bc61001210304r39cb6718kc6ae5f87deb90131@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Next protocol negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 21 Jan 2010 11:04:21 -0000

On Thu, Jan 21, 2010 at 12:07 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> That HTTPS number is very surprising. It suggests that 5% of Chrome users can do regular HTTPS, but not WebSockets over HTTPS?
>
> Are SSL-inspecting proxies that prevalent?
>
> Maybe this suggests that Chrome's bias is FOR tightly-controlled environments rather than AGAINST.

As noted, this data is preliminary but I will make some guesses:

The nature of the test is that it proceeds in steps, each step testing
some behaviour of the WebSockets protocol. If the user closes the
browser during the process, this can appear the same as a protocol
failure.

The breakdown of the failure rates at each step with TLS looks very
different from the HTTP patterns. With HTTP we see clear jumps where
the network is opaque to some behaviour for a significant fraction of
our users. The TLS data increases nearly linearly in comparison. Thus
it might well be that we're just seeing noise in the TLS data as the
steps proceed over time. I don't believe that TLS intercepting proxies
are actually deployed in front of 5% of our users.

We obviously want to investigate this ourselves and we're continuing
with our analysis and data gathering.


AGL