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

On Fri, Jan 07, 2005 at 06:26:24PM -0500, Charlie Brady wrote:
> On Fri, 7 Jan 2005, Gerrit Pape wrote:
> > On Wed, Jan 05, 2005 at 05:45:54PM -0500, Charlie Brady wrote:
> > > When started in this mode, sslio could create a pipe to share with its
> > > mail daemon peer. It could then block on a one byte read from the pipe.  
> > 
> > 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?

Yes, seems to be necessary.

> >  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.

sslio creates them.  Before replacing itself with the service program,
sslio can move the pipe filedescriptors to 6 and 7 instead of 0 and 1 in
tls mode, leaving 0 and 1 untouched.

> At any rate, if you'd like to send me any ipsvd patches I should be able 
> to do the other side and try to test it out. Bear in mind though that this 
> will still be a very limited solution until someone adds TLSv1 support to 
> matrixssl.

Do you know what's missing in matrixssl for tls?  Looks like some code
for it is already there.

On Sat, Jan 01, 2005 at 06:39:26PM -0500, Charlie Brady wrote:
> BTW, the imap clients I've tried aren't very user friendly here. All the
> one's I've tried refuse to talk to an SSLv3 server, demanding TLSv1.0
> (SSLv3.1).  But they're all happy to talk SSLv3 on the imaps port.

> Evolution was the worst. It sent an SSLv2 client hello (seemingly implying 
> that it would talk to SSLv2 servers, then dropped the connection when the 
> server replied with an SSLv3.0 server hello. No useful diagnostics 
> available at either end.

Can you say why exact tls clients fail the handshake, what's wrong with
the server hello matrixssl sends?, it seems it can understand sslv2
client hello.

Regards, Gerrit.