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

On Sun, 9 Jan 2005, Gerrit Pape wrote:

> On Fri, Jan 07, 2005 at 06:26:24PM -0500, Charlie Brady wrote:
> 
> > >  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.

Ah. The file descriptors exist, and aren't fd 6 and 7 in the existing 
code. That's what I thought.

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

I haven't found a concise description of differences. We're left with 
comparing the specs:

http://wp.netscape.com/eng/ssl3/draft302.txt

and

http://www.faqs.org/rfcs/rfc2246.html

I'm part way through browsing the two, and the only difference I've found 
so far is that SSL supports fortezza keying where TLS only supports RSA 
and DH. 

Wait, the "finished" messages are also different. Here's a pure python 
implementation of the different "finished" messages (from 
http://trevp.net/tlslite/):

    def _calcFinished(self, send=True):
        if self.version == (3,0):
            if (self._client and send) or (not self._client and not send):
                senderStr = "\x43\x4C\x4E\x54"
            else:
                senderStr = "\x53\x52\x56\x52"

            verifyData = self._calcSSLHandshakeHash(self.session.masterSecret,
                                                   senderStr)
            return verifyData

        elif self.version in ((3,1), (3,2)):
            if (self._client and send) or (not self._client and not send):
                label = "client finished"
            else:
                label = "server finished"

            handshakeHashes = stringToBytes(self._handshake_md5.digest() + \
                                            self._handshake_sha.digest())
            verifyData = PRF(self.session.masterSecret, label, handshakeHashes,
                             12)
            return verifyData
        else:
            raise AssertionError()

There's other differences, mostly to do with MAC creation and
verification. See TLSConnection.py and TLSRecordLayer.py.

> Looks like some code for it is already there.

Anything other than 3.0 is thrown out early in sslDecode.c:

/*
                First two bytes are the highest supported major and minor SSL versions
                We support only 3.0 (other options are 2.0 or 3.1)
*/
                if (end - c < 2) {
                        ssl->err = SSL_ALERT_ILLEGAL_PARAMETER;
                        matrixStrDebugMsg("Invalid ssl header version length\n", NULL);
                        return SSL_ERROR;
                }
                ssl->reqMajVer = *c; c++;
                ssl->reqMinVer = *c; c++;

                if (ssl->reqMajVer == SSL3_MAJ_VER) {
                        ssl->majVer = SSL3_MAJ_VER;
                        ssl->minVer = SSL3_MIN_VER;

                } else {
                        ssl->err = SSL_ALERT_HANDSHAKE_FAILURE;
                        matrixIntDebugMsg("Unsupported ssl version: %d\n", ssl->reqMajVer);
                        return SSL_ERROR;
                }


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

I'd need to look at Evolution's code. It doesn't report anything useful in 
its GUI, and it doesn't send anything over the wire - it just drops the 
connection. The only obvious difference between sslio and stunnel (which 
Evolution was happy to talk to) was version 3.0 rather than 3.1 in the 
server hello.

> what's wrong with
> the server hello matrixssl sends?

Version, I guess.

>, it seems it can understand sslv2 client hello.

Yep.