[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Mar 2020 15:43:19 +0100
From: Joakim Sindholt <opensource@...sha.com>
To: tlsify@...ts.openwall.com
Subject: Re: Interface design considerations
On Mon, Mar 23, 2020 at 02:34:37PM +0100, Solar Designer wrote:
> > 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?
Unfortunately no. I currently only need this for my company's software.
We're currently using something similar that runs as a thread in the
host process. It's all in C though and I have no problem publishing bits
and pieces.
> > * 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).
Tlsify is just an API, much like any TLS library. If you want a way to
test it you should use an external tool. I have attached a program that
will connect to a host and optional port and then have tlsify take over
with the proposed argument scheme.
> "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.
Tlsify should definitely not be a debugging tool. There should however
ideally be a debugging tool that uses tlsify as its API.
> 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.
Let's not GNU this up with tonnes of neat little options built in.
Tlsify just transparently layers TLS. Nothing else. No conditional
functionality. There might even be multiple implementations of the
interface in the future. What we need is a solid spec so people DON'T
end up embracing, extending and extinguishing us with some bloated
rube-goldberg nightmare machine.
> 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:
I'm no expert in STARTTLS but it looks to me like it can be done by the
application. If at all possible it should not be the job of tlsify to
implement your protocol for you. It just does TLS.
To steal an example from Wikipedia:
S: 220 mail.example.org ESMTP service ready
C: EHLO client.example.org
S: 250-mail.example.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
At this point the client posix_spawns a tlsify instance, giving it the
fd and continuing communication on the newly created cleartext fd. If
you need it to be the same fd, just dup2 over the one you handed to
tlsify.
> 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?
Tlsify will also be capable of being a TLS server. For now I've focused
exclusively on using it as a client but that will change.
I hope that clarifies my position.
View attachment "nctls.c" of type "text/x-c" (1700 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.
