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

Sorry Nico, this is not so much a reply to you specifically as I started 
thinking and writing about the SSH leap-of-faith/trust-on-first-use model.

On 11/08/2010 04:10 PM, Nicolas Williams wrote:
>
> It's not always the case that you have a trust path to a
> server,

Why not? Or, rather, isn't that a reasonable prerequisite for security?

Shouldn't the discussion of a secure protocol be able to presume it, 
much like RFCs tend to assume the existence of electrical power or 
non-backdoored computer hardware to run on?

> so if we force TLS on all the time then we're also training
> users to do SSH leap-of-faith (or worse, if the client isn't very good).
> Now, SSH leap-of-faith is actually a pretty good solution, so maybe
> that's OK.  But we'd still be training users to keep clicking "OK [give
> all my money to the bad guy]".

The old "Click 'OK' to fail or click 'Cancel' to not succeed." dialog.

The merits and limitations of leap-of-faith or trust-on-first-use (ToFU) 
have gotten a lot of discussion over the years, but I don't think 
there's an agreed-upon set of principles for deciding when it's 
appropriate for use in any given design. Most of us probably feel that 
it seems to work acceptably well in practice for administering servers 
via SSH, but is no good for general e-commerce web connections. Hard to 
say why.

With ToFU, an unknown server to which the client has never previously 
attempted to connect is trusted implicitly, even with a higher level of 
privilege than an authenticated trusted server. Unauthenticated server X 
is allowed to permanently set the auth credentials of any arbitrary new 
target server T, whereas the fully authenticated and trusted server A is 
not.

Aside from that, I think the thing that bugs me about ToFU is the 
definition of the term "first use".

This subtly introduces state into the client side where it did not exist 
previously. For every possible target server, the client must be able to 
answer "Have I ever connected to this server before?".

It's easy enough to think that the client doesn't need state on "every 
possible" target server and that he can just store the list of those 
that he has seen. But it's not so simple. When the question is posed of 
the data "have I seen this server before?" now a false negative outcome 
translates into vulnerability.

But for most systems, it's usually action based on a false positive 
result that is the more costly to remediate. Many systems experience 
little consequence from false negatives (e.g., a missed cache opportunity).

This relates to the concept that "it's very hard to prove a negative". 
In this case, the negative being accepted is "I have not used this 
server before". From a security design perspective, if there's something 
that's famously hard to do, you don't want your success at it to be a 
necessary condition for rejecting auth attempts from attackers.

It really seems to go against a fundamental principle of cryptography: 
the legitimate parties can succeed with relatively easy computations 
whereas the attacker finds impractically hard logic problems stacked 
against him.

But maintaining a mapping of servers to credentials on the client seems 
like a straightforward implementation task, something that we could 
implement reliably. But is it really? Many a developer has figured it 
would be simple to look for a server names in an x509 cert, but look how 
many issues that has raised. Why should looking up a server name in the 
client's ToFU history be different? (Except that, again, the failure 
mode is insecure in this case.)

There's the one-shot timing attack: if MitM can be in a position to 
intercept a client's actual "first use" of a server, then he can supply 
fake credentials which allow him to impersonate the server indefinitely.

There's a cookie-jar-overflow attack, too. No client can store an 
unlimited amount of server entries, so an attacker may be able to stuff 
entries in until the client software (or the user) is forced to discard 
some in order to make room for new ones.

These attacks would likely be very practical for protocols involving 
HTTP or HTML because they allow an unauthenticated server to cause the 
client to initiate requests at arbitrary other servers. Frequently this 
capacity is used for things like precaching images on a web site, but an 
attacker could equivalently use it to preload one or more entries into 
the client's ToFU state.

Even if a client presents a confirmation prompt to the user before 
adding an entry to the ToFU state (like SSH does), it could represent an 
information leak. An attacker could trigger requests to arbitrary 
servers and find out which ones the client had _ever_ accessed by the 
clients behavior when he goes to access those servers. Again, some other 
attackers could possibly preload false positive results which the first 
might misinterpret as evidence against the client.

Also, the idea of "first use" is tied to the client system. Or to the 
user. Or to a specific user on the client system. Or something. The list 
of every web server your client system had ever connected to would 
obviously be confidential data.

Yet, insofar as a client's loss of "first use" state represents a 
regression in its security, it needs to be continuously available too. 
What happens when the user transfers to another device? Aren't they 
obligated to back up that state and use it to initialize their new 
client system?

What if you're the kind to get a new smartphone every few months. Do end 
up with less security than the person who's been running the same IE6 
for the past 5 years?

What if a server needs to revoke and start using new credentials for 
whatever reason? It's one thing to convince a single CA of a legitimate 
change in the server's credientials, but how would a popular site 
convince every client independently?

Consider SSH's known_hosts files. If you're like me, you have used many 
SSH systems as clients over the years. I usually have filesystem 
permission bits protecting that file, but I don't consider it to contain 
anything interesting enough to think of as confidential either. When you 
have changed systems in the past, how often have you gone to the trouble 
of copying over your known_hosts file? I admit that I usually just 
accept a new first use of every server I access from the new client. Now 
consider the security of SSH if every random web page on the net were 
allowed to (or cause a prompt for) adding arbitrary entries to that file.

>> I.e., the default failure mode is secure, rather than insecure.
>
> Only on the server side.  If the firewall is not close to the client
> then the client can still fallback on insecure connections.  In many
> cases it's the client that matters most.

Good point.

In that sense, egress rules on client-based firewalls could be as 
important as the inbound connections on the server side.

- Marsh

P.S. Just for the record, I do really like tofu (the curd) and eat it on 
a regular basis.