Re: sslio error description incomplete/wrong

On Sat, Jan 01, 2005 at 06:39:26PM -0500, Charlie Brady wrote:
> I've been dabbling with using sslio to add STARTTLS functionality to Bruce
> Guenter's imapfront-auth and have encountered some problems with SSL
> negotiation, which took me a little too long to track down due to
> misreporting by sslio.  Here's what I see in my log:
[...]
> @4000000041d7236526ef4edc sslio[1412]: info: read bytes: 88
> @4000000041d7236526f9e9b4 sslio[1412]: info: sending ssl handshake response
> @4000000041d7236526fb1294 sslio[1412]: info: write bytes: 1122
> @4000000041d7236527035f94 sslio[1412]: info: read bytes: 7
> @4000000041d723652704a3cc sslio[1412]: fatal: ssl alert from peer: no error
> @4000000041d7236527055b64 sslio[1412]: warning: matrixSslEncodeClosureAlert returns ssl error: no error
> @4000000041d723652709b4ac sslio[1412]: info: bytes in: 95
> @4000000041d72365270ac234 sslio[1412]: info: bytes ou: 1122
> 
> However, once I sniff the traffic, I see that the client sent an SSL alert 
> message to the server:
> 
>  Level: Fatal (2)
>  Description: Protocol Version (70)
> 
> I'm thinking that sslio shouldn't have reported this as "no error". I 
> guess this is a martixSsl library problem, but I thought i should report 
> anywhere.

Yes, makes no sense to report through errno here, I'll take a look at
it.  The code also can be optimized, no need to try to send a closure
alert in this case.  Thanks for the notice.

> 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.
> Here's some of what the RFC says about compatibility:
> 
>    TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
>    is easy. TLS clients who wish to negotiate with SSL 3.0 servers
>    should send client hello messages using the SSL 3.0 record format and
>    client hello structure, sending {3, 1} for the version field to note
>    that they support TLS 1.0. If the server supports only SSL 3.0, it
>    will respond with an SSL 3.0 server hello; if it supports TLS, with a
>    TLS server hello. The negotiation then proceeds as appropriate for
>    the negotiated protocol.
> ...
> 
>    TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
>    Version 2.0 client hello messages [SSL2]. TLS servers should accept
>    either client hello format if they wish to support SSL 2.0 clients on
>    the same connection port. The only deviations from the Version 2.0
>    specification are the ability to specify a version with a value of
>    three and the support for more ciphering types in the CipherSpec.
> 
> 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.

Hmm, what's the reason you need tls, and don't run a separate service on
the imap/ssl or smtp/ssl port?

> BTW2, only the commercial version of martixSsl includes TLSv1 support. 
> Unless someone has hacked it into the GPL version.

I don't know about a patch; client support would also be nice I think.

Regards, Gerrit.