Re: [TLS] Inter-protocol attacks

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 13 August 2014 16:07 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AB81A0426 for <tls@ietfa.amsl.com>; Wed, 13 Aug 2014 09:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 LXWmvEGMrcVD for <tls@ietfa.amsl.com>; Wed, 13 Aug 2014 09:07:01 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636D41A08CB for <tls@ietf.org>; Wed, 13 Aug 2014 09:06:57 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 1DA051A2637; Wed, 13 Aug 2014 19:06:54 +0300 (EEST)
Date: Wed, 13 Aug 2014 19:06:53 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Martin Rex <mrex@sap.com>
Message-ID: <20140813160653.GA32598@LK-Perkele-VII>
References: <53EB6180.2030006@delignat-lavaud.fr> <20140813140028.BE4351AE06@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20140813140028.BE4351AE06@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IltZ0ZSYoHxlkVe3pcJuVHT-g7M
Cc: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Inter-protocol attacks
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Wed, 13 Aug 2014 16:07:03 -0000

On Wed, Aug 13, 2014 at 04:00:28PM +0200, Martin Rex wrote:
> 
> But with your description I somehow still fail to see a problem.
> If the server certificate of such resumptions will *pass* the
> "server endpoint identification", then why would re-doing the
> server endpoint identification make a difference?

As far as I understand, the actual issue is HTTP servers issuing
false responses to HTTP reqeusts if sent to wrong server (but
that server may still have valid certificate). And clients
interpretting those false responses as proper ones then leads
to all sorts of unpleasant problems.

Usually those false responses are because of misconfiguration
(usually default virtual host is something unintended, or the
default vhost is issuing redirects to "main site" even when
such redirect must not be sent (the vhost being handled else-
where)).

HTTP/2 even defines error code specifically for responding to
such requests (421). That code would also apply to HTTP/1.1
(in pinch, 400 would do while waiting for 421).


Where session resumption comes in is that it is more vulernable
than full handshake to attacker interference, resulting in it
being easier to make user connect to wrong server.


-Ilari