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

[Martin Rex <[e-mail]>]

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