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

[Marsh Ray <[e-mail]>]

On 11/09/2010 03:31 PM, Martin Rex wrote:
> 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

Yeah, that's not normal. :-)

> -- it is the task of the application to provide a fully
> connected socket that is ready for starting the SSL/TLS handshake.
...
> 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.

In theory.

In practice, most app developers seem to use an HTTP/HTTPS client library.

Client apps making plain TLS connections seem to fall in to two classes:

1. Those that pass a hostname and port into the library and have the 
library handle DNS lookup and sockets.

2. Those that are vulnerable because nobody checks the CN on the cert.

At this point, everybody in this group thinks to themselves: "well I've 
written a client or three that does it correctly". You are the 
exceptions to the rule. We would not let any of our friends make that 
mistake either, so we also end up not knowing anyone who writes class 2 
apps.

But look around online. There are far more SSL client apps than there 
are apps which parse names out of x509 certificates.

For example searching for "openssl connect" vs "openssl x509":

http://www.google.com/codesearch?hl=en&lr=&q=openssl+connect&sbtn=Search
Results 1 - 10 of about 99,800

http://www.google.com/codesearch?hl=en&lr=&q=%22openssl%2Fx509%22&sbtn=Search
Results 1 - 10 of 6,970.

There are probably more accurate ways to search that, but they all 
indicated that calling SSL/TLS functions was significantly more popular 
than parsing x509.

It's not their fault. Read the OpenSSL docs, there's hardly any 
explanation about the need to check x509 fields in the server's cert and 
your client still runs fine if you don't do it.

> Since the application will usually implement/provide things like
> HTTP proxy-traversal (with optional proxy password)

Most apps use HTTPS libraries for that, or don't implement it at all.

> 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.

Right, these are the "class 2" apps. More often than not, they don't 
properly check the name on the server's cert. Don't even ask about cert 
revocation handling and such.

Higher level APIs like to present SSL sockets and connection methods 
with the same interface as the plain sockets. This might work OK as long 
as the API sees the host and port names. Once the app grows a little in 
complexity, say by doing its own DNS resolution, then it may silently 
become vulnerable.

This might make another argument against starttls, albeit a weak one.

A raw TLS client app written by an non-TLS-expert developer that does 
everything perfectly is a rare bird indeed.

- Marsh