Date: Mon, 23 Mar 2020 12:42:31 -0400 From: Rich Felker <dalias@...c.org> To: tlsify@...ts.openwall.com 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 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. The present renewed interest in tlsify actually arose out of my implementation of the same concept internally in mxclient, 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 : https://github.com/richfelker/mxclient/
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.