Re: [TLS] SCSVs and SSLv3 fallback

mrex@sap.com (Martin Rex) Mon, 08 April 2013 19:49 UTC

Return-Path: <mrex@sap.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 CE68A21F8E63 for <tls@ietfa.amsl.com>; Mon, 8 Apr 2013 12:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.202
X-Spam-Level:
X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSzX2tI-s4nv for <tls@ietfa.amsl.com>; Mon, 8 Apr 2013 12:49:34 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F076F21F86C1 for <tls@ietf.org>; Mon, 8 Apr 2013 12:49:33 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r38JnToM011939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Apr 2013 21:49:29 +0200 (MEST)
In-Reply-To: <20130408194008.ED6D71A698@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Mon, 08 Apr 2013 21:49:29 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130408194929.7D02E1A698@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: Geoffrey Keating <geoffk@geoffk.org>, tls@ietf.org
Subject: Re: [TLS] SCSVs and SSLv3 fallback
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: <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: Mon, 08 Apr 2013 19:49:34 -0000

Following up to myself.

That middlebox vendors knowledgebase article says
"Cannot access some HTTPS sites in Internet Explorer with Windows 7",
so it seems to affect connections established with TLSv1.2, not just
initial TLSv1.2 ClientHellos with TLSv1.2 at the record layer.

Sorry for the confusion.

-Martin

Martin Rex wrote:
> Geoffrey Keating wrote:
> > 
> > > I've heard (anecdotally) that HTTPS between browsers and webservers
> > > who are both TLS-capable sometimes results in SSLv3 connections.
> > > Presumably this is due to firewall interference with the TLS
> > > handshake, causing browsers to retry an SSLv3 handshake.
> > 
> > The name of one firewall which is confirmed to do this would make it a
> > lot more convincing...  It's likely that some TLS connections failed
> > due to packet loss or a busy server and so the 'fallback' was a
> > mistake.
> 
> In a different discussion I heard the name of one such middleboxes,
> one that seems to be popular in enterprises:
> 
>   https://kb.bluecoat.com/index?page=content&id=KB5493
> 
> that appears to be incompatible with _at_least_ the silly Windows SChannel
> and (former?) iPhone behaviour to use TLSv1.2 at the record layer.
> 
> I don't know whether this affected middlebox will is hostile towards
> TLSv1.2 in general, or would let pass a more reasonable record version
> "{03,01}" for a "{03,03}" ClientHello, such as is used by openssl-1.0.1.