Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

[Marsh Ray <[e-mail]>]

On 11/08/2010 02:24 PM, Nicolas Williams wrote:
> On Mon, Nov 08, 2010 at 11:27:46AM -0600, Marsh Ray wrote:
>> On 11/08/2010 03:07 AM, Paul Hoffman wrote:
>>>
>>> "some security issues": See the long Security Considerations section
>>> on RFC 3207.
>>
>> Hmmm, yes, the little matter of the downgrade attack.
>
> You have that with the out-of-band negotiation case too though.

Right, I think I covered that in the blog post I linked. It always bears 
repeating. I suppose it depends on whether you define TCP port number as 
out-of-band or in-band so it's maybe relative to which RFC you're reading.

Regardless, the solution is to have the endpoints refuse to engage in 
risky behavior. Dynamically negotiating authentication parameters has 
proven to be inherently perilous.

> Every IM and e-mail client I've used has the option to not require TLS.

We have to be prepared to face the possibility that the status quo kinda 
sucks.

> That means they can be configured to fall back on not using TLS at all.
> Worse, there's usually a checkbox for using TLS as opposed to a checkbox
> for being insecure -- as a result, regardless of what the default is for
> that checkbox the user is likely to check it off if they run into any
> trouble.

Where there is an option, it really ought to be called "send all my 
bank^H^H^H^H naked Facebook photos to the bad guys."

>> * Developers don't have to code support for configuration
>
> When was the last time you saw a major IM or e-mail client that didn't
> let you toggle TLS?  I can't remember when I last saw such a thing.

It's awful, isn't it?

The only silver lining in this is that the existence of insecure 
connections may be keeping the bad guys busy enough that they never feel 
the need to attack our secure ones.

> If such an app gives you that toggle it's because the developers were
> willing to deal with the complexity of negotiation (whether starttls or
> not) and configuration (that toggle is it).

Right, there's still some configuration, so maybe this is by itself is 
not a huge win.

Looking at T-bird IMAP configuration I see:

A) Port number: [defaults according to other setting]

B) Connection security: three options
    None
    STARTTLS [default]
    SSL/TLS

C) Use secure authentication: [checkbox]

It seems like this configuration could be simplified a little bit.

(A) Looks simple and obvious.

(B) Doesn't say whether its STARTTLS is strict, or if it's vulnerable to 
a downgrade attack.

(C) Doesn't say what "secure authentication" means. I suppose I could 
look up some RFCs and guess that it might mean that. But what it doesn't 
say is whether or not non-forwardable auth can be used. If I select 
STARTTLS and check "Use secure authentication" it appears likely that an 
active attacker could still downgrade my connection to non-TLS and then 
do a forwarding attack taking my credentials to to some other server, 
perhaps not even mail related.

So the Thunderbird developers implemented some extra configuration (and 
I don't really know what it does) which would not be necessary if there 
were just an "requre port 993 TLS" checkbox.

>  Making sure
> that servers require TLS, whether StartTLS or otherwise, is not much
> harder.

Yeah, not much harder. But it seems like "just a little more work" can 
make a huge difference in real world uptake rates.

> You still have to be sure that the client and server will actually, you
> know, run TLS.

...and validate the certificates properly, and so on.

> The only benefit of a "secure-only port number" is that you don't have
> to make sure that the server requires TLS -- chances are near 100% it
> just won't work if it doesn't, in which case the problem is self-
> correcting (user files ticket, admins fix the problem).

I.e., the default failure mode is secure, rather than insecure.

This is a pretty big win IMHO.

- Marsh