Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Mar 2020 12:42:31 -0400
From: Rich Felker <>
Subject: Re: Interface design considerations

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 ESMTP service ready
> S: offers a warm hug of welcome
> 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.

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.



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.