TLS not working properly

[gucki]

I'm trying to build a ftps server and so far everything works, except encryption of the data channel (encryption of the control channel works fine). I'm using filezilla as ftp client and it always complains about a gnutls error. Here's the trace:

Trace:  CTransferSocket::OnAccept(0)
Trace:  CTransferSocket::OnConnect
Trace:  CTlsSocket::Handshake()
Trace:  gnutls_session_get_data on primary socket failed: -51
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnSend()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::Failure(-19, 103)
Error:  GnuTLS error -19: An unexpected TLS-Handshake-Paket was received.
Trace:  CTransferSocket::OnClose(103)
Error:  Transfer connection interrupted: ECONNABORTED - Connection aborted
Trace:  CTransferSocket::TransferEnd(3)
Trace:  CFtpControlSocket::TransferEnd()
Error:  Connection timed out
Trace:  CControlSocket::DoClose(2050)
Trace:  CFtpControlSocket::ResetOperation(2114)
Trace:  CControlSocket::ResetOperation(2114)
Trace:  CFtpControlSocket::ResetOperation(2114)
Trace:  CControlSocket::ResetOperation(2114)
Error:  Failed to retrieve directory listing
Trace:  CFileZillaEnginePrivate::ResetOperation(2114)

This is how I try to connect to the data channel (active mode, so the client is listening for an incomming connection):

EventMachine::run do
  c = EventMachine.connect("127.0.0.1", 52478)
  c.start_tls
end

When removing the call to start_tls the output in filezilla is only:

Trace:  CTransferSocket::OnAccept(0)
Trace:  CTransferSocket::OnConnect
Trace:  CTlsSocket::Handshake()
Trace:  gnutls_session_get_data on primary socket failed: -51
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnSend()
Trace:  CTlsSocket::OnSend()

I doubt that filezilla is buggy as I tried the version from ubuntu 12.10 and the official latest one for windows. Both fail with exactly the same error.

[gucki]

I also opened the bug report "upstream" https://github.com/eventmachine/eventmachine/issues/388

[cabo]

On Nov 24, 2012, at 20:51, Corin Langosch [email protected] wrote:

I also opened the bug report "upstream" eventmachine#388

— Reply to this email directly or view it on GitHub.

Hi corin,

what is c.starttls returning? Can you capture the packets being exchanged with tcpdump/wireshark?

Grüße, Carsten

[ibc]

In EventMachine-LE 1.1.4 there is an option :ssl_version for start_stls() in which you can choose whether to use SSL2.3, SSL3 or TLS1.0:

https://github.com/ibc/EventMachine-LE/blob/master/lib/em/connection.rb#L396

Default value is SSL2.3. Try others please.

[gucki]

@cabo Output of irb is here http://pastie.org/5428896 Output of tcpdump is here http://pastie.org/5428899 (if you need a different output, please let me know the cmd line)

@ibc I tried all other ssl versions but it's not working.

[gucki]

Ok, digging further shows the following:

1. When EM is acting as a server, start_tls seems to work properly for incomming connections. But it seems EM doesn't properly/ gracefully close the connection. This also explains why the control socket over tls works (never closed), but the data socket fails (last paket before connection closure is only partially received). I close the connection using close_connection_after_writing.
2. When EM is acting as a client, start_tls does not work at all. Probably EM is not smart enough to know that it should act as a client and not server?

[cabo]

On Nov 24, 2012, at 21:51, Corin Langosch [email protected] wrote:

• When EM is acting as a client, start_tls does not work at all. Probably EM is not smart enough to know that it should act as a client and not server?

WFM (below).

I'm too lazy to decipher your tcpdump output -- can you send me the pcap (or use wireshark/tshark to get a better decode)? It appears that 52623 is sending a ClientHello first, and I'd rather have the machine do the decoding.

Grüße, Carsten

require 'eventmachine-le'

module Handler def connection_completed puts "connection_completed" p start_tls end def ssl_handshake_completed puts "handshake completed" send_data("GET / HTTP/1.1\nHost: tzi.de\n\n") end def receive_data(s) p s end def unbind puts "unbind" EventMachine.stop end end

EventMachine::run do c = EventMachine.connect("tzi.de", 443, Handler) end

[cabo]

On Nov 24, 2012, at 22:18, Carsten Bormann [email protected] wrote:

It appears that 52623 is sending a ClientHello

Ha. Thank you for finally getting me to skim the abomination of a spec that FTPS is.

For i) and ii), the FTP client MUST be the TLS client and the FTP server MUST be the TLS server.

That is to say, it does not matter which side initiates the connection with a connect() call or which side reacts to the connection via the accept() call; the FTP client, as defined in [RFC-959], is always the TLS client, as defined in [RFC-2246].

So the TCP server that takes in the FTP data TLS connection (FTP client) also is the TLS client, and your code (the TCP client) must act as the TLS server. Indeed, I'm not sure EventMachine can be persuaded to partake in this charade.

You might have to write a patch that exposes SetServerMode to Ruby-land. Preferably write it in such a way that an FTP client can also be written based on that (i.e. do it both ways, exposing bIsServer).

Grüße, Carsten

[gucki]

@cabo Thank you for the information. I'll try my best to get a working patch for this tomorrow :)

So the only thing left is the improper/ non-graceful closure of the ssl connection. I googled a little and found some other guy had the same problem: http://stackoverflow.com/questions/12578935/does-eventmachine-issue-close-notify-on-close-connection-if-tls-start-was-run Do you have any idea on how to fix this? :)

[cabo]

On Nov 24, 2012, at 23:10, Corin Langosch [email protected] wrote:

@cabo Thank you for the information. I'll try my best to get a working patch for this tomorrow :)

Well, too late. I just checked it in.

Please do write a test, though.

So the only thing left is the improper/ non-graceful closure of the ssl connection. I googled a little and found some other guy had the same problem: http://stackoverflow.com/questions/12578935/does-eventmachine-issue-close-notify-on-close-connection-if-tls-start-was-run Do you have any idea on how to fix this? :)

Can you distill this into a small test case?

Grüße, Carsten

[cabo]

On Nov 25, 2012, at 07:20, Carsten Bormann [email protected] wrote:

Well, too late. I just checked it in.

I made a branch "ele", in case you don't find it. The new commit is: https://github.com/ibc/EventMachine-LE/commit/ad46cbf41be32bbcbe264d4155212126700ada84

Grüße, Carsten

[cabo]

On Nov 25, 2012, at 07:20, Carsten Bormann [email protected] wrote:

Can you distill this into a small test case?

Well, you'll need a big test case, as well as some new code, because I can't find any code in eventmachine today that would send out a TLS shutdown (close_notify alert) on close_connection. I believe this would need to be done in ScheduleClose (ed.cpp) (preferably only in the close_connection_after_writing case) as opposed in the SslBox_t destructor, where there already is some strange shutdown code (any TLS data from that is unlikely to ever actually get sent). It also needs a hook in ssl.cpp to actually call the SSL_shutdown, after which there needs to be another _DispatchCiphertext or so. Good luck.

Grüße, Carsten

[gucki]

Hi Carsten,

thank you very much for your really fast response and I'm very sorry for my long delay.

I finally had the change to give your commit a try, but it still fails with exactly the same error message. To make sure I'm really using your branch and correctly pass the :server => true setting to start_tls I added some debug code to eventmachine (https://github.com/gucki/EventMachine-LE/commit/f6099c1e70aeab271bb53dbf8b69452df889fb31). It outputs "Server: true", so my invocation should be ok. Do you have idea why it still fails?

I'm now tyring to fix the tls shutdown problem....

Corin

[gucki]

Here's my attempt on getting graceful shutdown of ssl connections working, but it doesn't work at all. Also a lot of tests fail/ hang now...any ideas? :) https://github.com/gucki/EventMachine-LE/commit/ee1570d7a19c9958eaaf7f6874506182f2c51bda

http://www.openssl.org/docs/ssl/SSL_shutdown.html# http://marc.info/?l=openssl-users&m=126838806919896

[gucki]

Ok, I just fixed all hanging/ failing tests. But still the sll connection isn't terminated gracefully. Here's the output of ftp server caused by the added debug ssl statements:

>> 230 OK, login correct
<< PBSZ 0
>> 200 OK, protection buffer size set to 0
<< PROT P
>> 200 OK, using private data connection
<< PWD
>> 257 "/" is the current directory
<< TYPE I
>> 200 Type set to binary
<< PASV
>> 227 Entering Passive Mode (127,0,0,1,209,8)
<< LIST
TLS Server: true
>> 150 Data transfer starting
>> 226 Transfer complete, sent 463 bytes
SslBox_t::Shutdown called
SSL_shutdown: 1
return completed

So it seems ssl shutdown is called and it returns 1. According to the docs of openssl this should indicate the connection was gracefully shutdown?! :(

[gucki]

I give up on this, and really hope someone else gets it fixed somehow...

[harssh]

Any solutions yet I also have same issue

[gucki]

@harsshhfs Sorry, I don't have any solution yet. As I also don't have much time to invest in this I'm thinking about moving to jruby and using the foxbat gem. I didn't try it yet, but hope it works better. If you give it a try I'd be happy about some feedback if it worked for you :)

[harssh]

@gucki: Oh k Thanx for reply...........

[ibc]

I'm sorry. The EventMachine SSL internals are not very good.

[mmamoonkhan]

hi i get this error and i'm the beginner that's why idk how to solve this would you people like to guide me how to remove this error guide me as soon as possible thank you

[paradisaeidae]

Are you sure you are using EM-LE? As I think it's differences to EM have been reduced. To the point it's better to be using EM.