[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Mar 2020 09:59:39 -0400
From: Rich Felker <dalias@...c.org>
To: tlsify@...ts.openwall.com
Subject: Re: Interface design considerations
On Tue, Mar 24, 2020 at 02:07:17PM +0100, Solar Designer wrote:
> On Mon, Mar 23, 2020 at 12:42:31PM -0400, Rich Felker wrote:
> > On Mon, Mar 23, 2020 at 03:43:19PM +0100, Joakim Sindholt wrote:
> > > > 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.
> >
> > Yes, this works, but it does reveal quite a bit about the types of
> > certificate validation schemes that might be required.
>
> Reveal from where to where? Do you mean in terms of complicating the
> API or in terms of information disclosure?
Sorry, I don't mean "reveal" in the sense of a weakness. Just in the
sense of demonstrating to us as designers some design requirements
that I don't think were previously apparent (at least they weren't to
me).
> > The present renewed interest in tlsify actually arose out of my
> > implementation of the same concept internally in mxclient[1], doing
> > starttls via replacing the original socket with one end of a
> > socketpair to a thread doing the tls session, but without the "public
> > API" aspect of tlsify, which is really the valuable/important part
> > that's still an open problem.
> >
> > Rich
> >
> >
> > [1]: https://github.com/richfelker/mxclient/
>
> Oh, so once we have tlsify mxclient should become one its example uses?
Yes. I wouldn't mind also keeping support for direct use of bearssl is
long as it's comparable in functionality, but I'd favor tlsify and if
it gets to the point where important functionality only works with
tlsify I think I'd drop the existing code.
Rich
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.
