[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1453919017.13374.44.camel@zhasha.com>
Date: Wed, 27 Jan 2016 19:23:37 +0100
From: Joakim Sindholt <opensource@...sha.com>
To: tlsify@...ts.openwall.com
Subject: Concerns about buggy software
I've been experimenting with a similar concept that runs in a thread in
the same process. It's a tiny shim using mbedtls and it actually works
quite well. I've attached it if anyone wants to play around with it (or
possibly find bugs). It has raised a few concerns though.
Buggy clients:
Consider a client that wants to reuse connections. In broad terms it
would pull an old connection, see if it's still alive, and then if it's
not, start a new connection.
But how do you check if a connection is still alive? I would wager that
a lot of applications (and I caught myself doing this) tries to write()
the socket and if it succeeds then it's up. This is of course wrong.
write() can easily send the data and have it never be received on the
other end. The real answer is protocol specific, however most of the
time this will work exactly as expected.
So now we layer on tlsify, which may well always swallow your write
depending on the implementation. This will give the illusion of a
completely different set of semantics between regular and tlsified
sockets.
Not really a problem in tlsify but it will probably reveal some really
nasty bugs.
Awful servers:
Some servers[1] require that TLS acts like a datagram protocol. Not
DTLS, regular TLS. This is suuuper nasty but I have a real world use
case that broke when mbedtls introduced record splitting by default. A
case, mind you, that I would love to use tlsify on. I can also guarantee
that they will not change.
The problem is that we can't guarantee write() in the tlsify user will
be read() in one go. To a lesser extent, we also can't guarantee that
the process won't receive a signal during write() that interrupts it.
The last one might be solvable application-side.
I have to reiterate that this is super nasty and so I'm not sure it's
even worth trying to support it, but it is a real world concern
apparently.
[1] http://sourceforge.net/p/openvpn/mailman/message/34082675/
View attachment "mbedify.c" of type "text/x-csrc" (8006 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
