[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
