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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> On 11/11/2010 10:41 AM, t.petch wrote:
> >
> > To return to (what I see as) the main purpose of the thread, I too
> > think that StartTLS is a good, if not an excellent idea; I see no
> > difference in the vulnerabilities (although my cryptanalysis is weak).
> 
> Well, that's the thing. In theory there is no difference, in practice 
> however...

The good thing about STARTTLS is that you can distinguish and
seperately analyze network connectivity from protocol interop issues.

For "upgrading/enhancing" an existing usage scenario in an installed
base, where connectivity is a solved problem, it offers
a smoother upgrade.

Distinguishing network connectivity issues from protocol interop
issues can be a royal PITA if you think of the complete absence
of TLS alerts from TLS peers running on top of Microsoft SChannel
or apps that produce utterly useless error messages like MSIE 6/7/8.

(the latter looks somewhat like an inbreed problem -- when ones
 implementation fails to implement part of the spec, then
 black-box testing with oneself can not possibly cover
 a sensible interop with that part of the spec.)

> 
> On the other hand, my email program gives me an option to use 
> "STARTTLS". Even after I took packet captures of the connection process 
> and observed it correctly negotiating the use of encryption, I still 
> cannot tell if my email is vulnerable to a downgrade attack. The only 
> way to find out is by performing exhaustive testing with an attack tool, 
> or by direct inspection of the source code!

Black-box testing of security protocols with shelved has never produced
any meaningful information about protocol compliance or security and
never will.  Unless a protocol uses a fail-safe design by itself,
you will always need specialized interop tests with test tools that
can produce all sorts of very security-relevant deviations from
the communication between ordinary applications.


When I built GSSTEST to test GSS-API interoperability ~10 years ago,
I added test cases for common usage/configuration errors and typos
as well as test for various modifications of the stream of protected
messages to get an idea how implementations react (replay, reflection,
duplication, loss, reordering, truncation, extension, corruption)
and whether implementations detect the modifications, how they report it,
and whether they can get back in sync with the peer after a detected
modification (as GSS-API allows to make these errors non-fatal for the
underlying security context).

While most of the implementations were relatively well-behaved
for usage/configuration errors and typos, the results for modified
message streams were somewhat disappointing, so that we excluded
that part from the interoperability certification with our app.

When testing modified message streams, leaking memory was a pretty
common "mild" reaction.


-Martin