Date: Mon, 23 Mar 2020 14:34:37 +0100 From: Solar Designer <solar@...nwall.com> To: tlsify@...ts.openwall.com Subject: Re: Interface design considerations Hi, On Mon, Mar 23, 2020 at 12:54:52PM +0100, Joakim Sindholt wrote: > Yesterday we (Rich and I) had a discussion about the public interface of > tlsify, taking the first step towards a working, deployable product. > Rich suggested taking it to the list and I agree, so here are the notes: > > Foreword: > > Priority 1 should be designing a solid API that will allow new, as well > as existing software to adopt tlsify instead of linking in a library. > > As a note to this I, if there are no objections, will be working on an > actual implementation of what's being discussed as I fear we will > otherwise devolve into one of those "we just publish a spec so other > people can implement it" groups. > > I also believe we must eventually publish a high quality implementation > or the project will not be taken seriously as it is a significant > departure from what's normally considered high performance. Sounds great. Thank you for volunteering! > My own needs are mostly JSON over HTTPS based Will your own uses be in Open Source code - that is, will they also serve as authoritative example uses of your implementation of tlsify? What languages will they be in? > * Having tlsify do the connecting for you. > - I disagree with this. IMO it's unrelated to TLS and a > feature-creep springboard for even more TLS-unrelated > functionality. On one hand, yes, this would be feature creep. On the other hand, people will need to test their tlsify builds and settings somehow, ideally first separately from the service that will use tlsify (quicker to see where the problem is, less downtime to the service if tlsify settings are tested before being brought in production and no full duplicate service+tlsify+addresses staging setup exists). "openssl s_client" can connect, but can't accept an fd (there was a patch adding the "-fd" option submitted as OpenSSL RT ticket 2878, but apparently not merged?) It is primarily a debugging tool not meant for production use. tlsify could be the other way around. Or it could be both. Or maybe we could have a wrapper program around tlsify for debugging? Or just a different build of tlsify (with an extra source+object file, producing a slightly larger binary) including also this functionality? It does feel ridiculous not to include it as a standard tlsify feature if we have it in the source tree anyway and it's tiny, though. Then there are things like STARTTLS. Even "openssl s_client" includes a "-starttls" option. If we don't want this sort of feature creep, what do we propose instead? That programs adding tlsify also implement their own support for STARTTLS or such, and perhaps swap fd's with dup2() after having invoked tlsify? Will we provide an example? Maybe it could be in the form of much smaller patches for (net)qmail than these: https://inoa.net/qmail-tls/ These implement both client and server. And there's "openssl s_server". Will tlsify be usable to implement both, too? Newer SMTP clients/servers already have TLS support in their upstream implementations. (net)qmail being abandoned upstream yet still widely used might be good for us to illustrate addition of tlsify to a program implementing a protocol requiring STARTTLS, and the concept of tlsify fits in well with qmail already being many separate programs invoking one another. (I'd possibly actually use this, with the alternatives being those larger patches or deploying separate SMTP+STARTTLS proxies or moving away from qmail or not supporting TLS. Indeed, there are other good reasons not to use qmail these days, but it's tricky.) Alexander
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.