Re: [TLS] Security concerns around co-locating TLS and non-secure

Martin Rex <mrex@sap.com> Tue, 09 November 2010 21:31 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E7A3A686D; Tue, 9 Nov 2010 13:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.906
X-Spam-Level:
X-Spam-Status: No, score=-9.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8]
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 yEL3o7Gv4VTK; Tue, 9 Nov 2010 13:31:26 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id AB8E93A68B1; Tue, 9 Nov 2010 13:31:25 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oA9LVlYe026250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Nov 2010 22:31:47 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201011092131.oA9LVj4U000789@fs4113.wdf.sap.corp>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure
To: marsh@extendedsubset.com (Marsh Ray)
Date: Tue, 9 Nov 2010 22:31:45 +0100 (MET)
In-Reply-To: <4CD872C5.2010007@extendedsubset.com> from "Marsh Ray" at Nov 8, 10 03:59:33 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
X-Mailman-Approved-At: Fri, 12 Nov 2010 08:06:55 -0800
Cc: paul.hoffman@vpnc.org, tls@ietf.org, tsvwg@ietf.org, Nicolas.Williams@oracle.com
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2010 21:31:27 -0000

Marsh Ray wrote:
> 
> Does it have implications for session resumption I wonder?

I really do not think so.   For a sensible implementation of
client-side TLS session caching, it is always necessary to
know the original target hostname&protocol/port, and not the
naked target IP address & port on the connected socket.

> 
> Not so much for the protocol itself, but for what you get with the 
> straightforward use of a normal TLS library.

I don't know what you mean by "normal TLS library".  In the abstraction
that I provide to our application callers,  I do not offer a connect
capability -- it is the task of the application to provide a fully
connected socket that is ready for starting the SSL/TLS handshake.


If there is any plain text communication necessary prior to starting
the TLS handshake on a socket (such as a proxy CONNECT method or
probably in a STARTTLS scenario), preparing the connection is entirely
up to the application.

I do require the application caller to provide a target hostname&port
for the handshake to be started, so that my abstraction layer can
transparently provide client-side TLS session caching.  By default,
that target hostname is going to be used for server endpoint identification,
but the application can specify this to be ignored, retrieve the
server certificates or DNames from it and perform other kinds of
server endpoint identifications it considers adequate.

>
> In cases where the app code is just passing buffers to the TLS library,
> the TLS stack may not even know the hostname at the time of the Hello 
> message exchange.

It is the duty of the application caller to either provide the
TLS implementation that hostname&port of the destination prior to
starting the handshake, or to perform client-side TLS session
cache management itself or live without client-side TLS session caching.


> 
> For example, if a developer let the TLS library handle the socket 
> connections it seems like it could be smart enough to support 
> resumption, but a STARTTLS-based protocol would seem to prevent this.

Letting a TLS library do network reads and writes directly is a
completely seperate issue from how is a communication channel
established (and closed) and how to get to the exact point in
the communication where the TLS handshake can be started.


Since the application will usually implement/provide things like
HTTP proxy-traversal (with optional proxy password) and
STARTTLS-enabled protocols without TLS, I would never try to duplicate 
that part of the non-TLS communication within TLS.

Same goes for most part of the IPv6 support by the application.
By leaving the connect entirely up to the application (which needs
to implement it for all non-TLS protocols anyways), the amount
of changes that my SSL abstraction needed for IPv6 was very minor.


Calling SSL_connect() and SSL_accept() does not imply that the
TLS library calls socket()+connect()s or socket()+listen()s.

Since a lot of applications includes support for non-TLS protocols,
it is much easier to have the application perform all select()/poll() 
operations, including connect() and listen(), and in particular
when doing the latter asynchronously.  This also facilitates
consistent error handling&visualizations for network errors.


-Martin