SSL_ERROR_ZERO_RETURN for no reason

Complete crap that I wrote. Sorry. It does not work after downgrading to 1.4.4! However on a debian-machine with 1.4.4 it works fine.

ssldump shows the following.
working library (debian):
[...]
1 5 0.2804 (0.0000) S>C Handshake
      CertificateRequest
        certificate_types rsa_fixed_dh
        certificate_types dss_fixed_dh
        certificate_types rsa_sign
        certificate_types dss_sign
        certificate_types unknown value
      ServerHelloDone
1 6 0.3393 (0.0588) C>S Handshake
      Certificate
1 7 0.5232 (0.1839) C>S Handshake
      ClientKeyExchange
[...]

maybe broken library:
[...]
1 5 13.3543 (0.0000) S>C Handshake
      CertificateRequest
        certificate_types rsa_fixed_dh
        certificate_types dss_fixed_dh
        certificate_types rsa_sign
        certificate_types dss_sign
        certificate_types unknown value
      ServerHelloDone
Unknown SSL content type 85
1 6 13.4411 (0.0868) S>C Alert
    level fatal
    value protocol_version
Unknown SSL content type 53
1 7 13.4421 (0.0010) C>SShort record
1 8 13.5264 (0.0843) S>CShort record
Unknown SSL content type 53
[...]

The initial is the same for both. However after the ServerHelloDone SSL_connect() returns the error, which in this example causes the client to continue in plain-text. I don't now if the S>C message about the wrong protocol-version is related to the certificate or just because the client sent plaintext.

However since both welcome each-other with Version 3.1 this should not be the problem.
1 1 13.2530 (13.2530) C>S Handshake
      ClientHello
        Version 3.1
1 2 13.3543 (0.1012) S>C Handshake
      ServerHello
        Version 3.1

Hi,

It's interesting that this worked in Debian, but not Ubuntu, as the only
difference was a rebuild.

I am having trouble trying to look in to this issue though, could you
tell me a few things that would help me please?

You are referring to the OpenSSL compatibility stuff in gnutls when
talking about the errors, but wput does not seem to use that.

Also you say that "SSL_connect returns in the new version with
SSL_ERROR_ZERO_RETURN", however I can only see that
function returning 0 or 1.

The only function that seems to return this value is SSL_get_error.

Thanks,

James

That's true, sorry for being unclear on that. SSL_connect returns 0 and SSL_get_error gives SSL_ERROR_ZERO_RETURN.

The corresponding code in wput is here:
http://wput.svn.sourceforge.net/viewvc/wput/trunk/wput/src/socketlib.c?view=markup#l_168

Wput includes <gnutls/openssl.h> for TLS-operation and is linked against gnutls-openssl, so it uses the gnutls-compatibility-wrapper for OpenSSL.

On Mon, 2008-02-25 at 12:10 +0000, Rumpeltux wrote:
> That's true, sorry for being unclear on that. SSL_connect returns 0 and
> SSL_get_error gives SSL_ERROR_ZERO_RETURN.
>
> The corresponding code in wput is here:
> http://wput.svn.sourceforge.net/viewvc/wput/trunk/wput/src/socketlib.c?view=markup#l_168
>
> Wput includes <gnutls/openssl.h> for TLS-operation and is linked against
> gnutls-openssl, so it uses the gnutls-compatibility-wrapper for OpenSSL.
>

My apologies, I grepped for SSL_get_error, which was how
I assumed that you knew what the error was, but it is not
used.

I see in the source you linked to there is a comment
referring to this issue. I'm surprised it hasn't been
brought up upstream (though I may have missed it, I'm
not going to make any claims about my sharpness after the
mistake above.)

I'll try and investigate what is going on.

Thanks,

James

On Mon, 2008-02-25 at 18:11 +0000, James Westby wrote:
> I'll try and investigate what is going on.

Ok, I tried to set up vsftpd to do this, but I don't get
a certificate request. Are you using a different server?
If not how do you get the server to request client certificates.

Thanks for pointing me to ssldump, I've always used
wireshark before, but this is easier for quick jobs.

Thanks,

James

I'm using a proftpd-server, but only with a server-certificate and no validation on client-side at all (which I know is bad, but still better than having plain-text ftp ;)).

Don't wonder about the comment in the source, this is just what I put there after unsuccesfully trying to track down the problem.

Thank you for looking into this issue.

On Tue, 2008-02-26 at 10:29 +0000, Rumpeltux wrote:
> I'm using a proftpd-server, but only with a server-certificate and no
> validation on client-side at all (which I know is bad, but still better
> than having plain-text ftp ;)).
>

I switched to proftpd and have made some progress, but I can't
reproduce the problem yet. I am running hardy, and I can remember if
you said what you were running, so that may be a difference. I am
going to attach my proftpd config files that I have changed from the
defaults, and if you could tell me if anything differs to yours
that would be great.

I am running wput as

wput --force-tls file ftp://jw2328@localhost/
--20:13:20-- `no_att'
    => ftp://jw2328:xxxxx@127.0.0.1:21/no_att
Connecting to 127.0.0.1:21... connected! encrypted!
Logging in as jw2328 ... Error: Login-Sequence failed (Login incorrect.)
Skipping all files from this account...
FINISHED --20:13:23--
Transmission of 1 file failed.

is that correct?

> Don't wonder about the comment in the source, this is just what I put
> there after unsuccesfully trying to track down the problem.

Are you the author of wput? You might like to approach the upstream
gnutls yourself if you are, they are friendly and helpful.

I am happy to work with you trying to find out what the issue is
and take it to them myself.

Another possibility, rather than you waiting for me to set up a
server is to do what I do when I have one. I was going to run
wput under gdb and break on SSL_connect (or rather gnutls_handshake
that this thunks through to) and step through to find what returns
the error. I realise you may have better things to do with your
time though.

Thanks,

James

#
# /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration file.
# To really apply changes reload proftpd after modifications.
#

# Includes DSO modules
Include /etc/proftpd/modules.conf

# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6 on

ServerName "Debian"
ServerType standalone
DeferWelcome off

MultilineRFC2228 on
DefaultServer on
ShowSymlinks on

TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200

DisplayLogin welcome.msg
DisplayChdir .message true
ListOptions "-l"

DenyFilter \*.*/

# Use this to jail all users in their homes
# DefaultRoot ~

# Users require a valid shell listed in /etc/shells to login.
# Use this directive to release that constrain.
# RequireValidShell off

# Port 21 is the standard FTP port.
Port 21

# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
# PassivePorts 49152 65534

# If your host was NATted, this option is useful in order to
# allow passive tranfers to work. You have to use your public
# address and opening the passive ports used on your firewall as well.
# MasqueradeAddress 1.2.3.4

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone...

I just rerun the tests after reinstalling the gnutls-library and all of a sudden I cannot reproduce this problem anymore. I don't know if the library was fixed again (but i'm still with 1.6.3-1build1) or if the error was the result of some other library in use, however not it works just as in your example.
I ran tests on several other machines, all of them work. So I apologize for eating your time with a bug that doesn't exist any more and consider this one done.

On Wed, 2008-02-27 at 10:53 +0000, Rumpeltux wrote:
> I just rerun the tests after reinstalling the gnutls-library and all of a sudden I cannot reproduce this problem anymore. I don't know if the library was fixed again (but i'm still with 1.6.3-1build1) or if the error was the result of some other library in use, however not it works just as in your example.
> I ran tests on several other machines, all of them work. So I apologize for eating your time with a bug that doesn't exist any more and consider this one done.

Thanks for testing again, it's good to know that it
works for you now, though it's a shame we don't
know what was broken.

If you encounter this again please don't hesitate
to open the bug again so that we can debug it.

Thanks,

James