Re: sslio as a STARTTLS wrapper (was Re: sslio error description incomplete/wrong)

Charlie Brady <[email protected]> writes:

> On Fri, 7 Jan 2005, Gerrit Pape wrote:
>
>> On Wed, Jan 05, 2005 at 05:45:54PM -0500, Charlie Brady wrote:

[...]

>> I think you can use a communication channel that's already there.  Give
>> sslio a new command line option for starttls.  With this option, it
>> leaves filedescriptors 0 and 1 untouched for the service program (here
>> smtpfront-qmail), and provides filedescriptors 6 an 7 for ssl encrypted
>> data.  It sleeps until it sees fd 7 readable.
>> 
>> smtpfront-qmail talks to the client through stdin and stdout in plain
>> text.  If tls is requested, it switches stdout to fd 7 and wakes up
>> sslio.
>
> By writing a byte, correct?

I tried this in a small test script, and I had to write a byte to get
the parent to wake up.

If we have to write a byte, we're essentially using this pipe for two
purposes; first as a signal, and then as the SSL layer.

My feeling is that we might as well just use 3 pipes, one for control,
one for read, and one for write.  It keeps everything to a single
purpose, and leaves the possibility of adding to the protocol, to
allow things like reading SSL settings over the pipe, or turning SSL
on and off at various times.

Once we've gone to the trouble of setting up two FDs for this, it
doesn't add much more complexity or consume many more resources to add
one more.

>>  stdin is switched to fd 6, and smtpfront-qmail now talks to the
>> client through ssl.  If smtpfront-qmail knows that tls no longer can be
>> requested in this session, it closes fd 6 and 7, and sslio exits.
>> 
>> Can this work?
>
> I don't see where you are getting the fd 6 and 7 from. I see how they are 
> defined for use by UCSPI clients, but we don't have one of those here.

I think it's a bad idea to hardcode file descriptor numbers.  That
makes things difficult if a similar protocol adapter is released
adding different functionality, and file descriptor numbers have to be
coordinated between any projects adding layers on top of an UCSPI
server.

Instead, we can simply put the file descriptor number into an
environment variable, then get it back out in the client.

Also, regarding the performance of a persistent copy of sslio
vs. starting up a new copy every time: it's possible that with
matrixssl new sessions are much cheaper, and it's not worth worrying
about.

----ScottG.