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