Skip Menu |

This queue is for tickets about the Net-FTPSSL CPAN distribution.


Subject: Reuse of SSL session for Data connection
Date: Wed, 28 Mar 2012 00:00:47 +0200
To: bug-Net-FTPSSL [...] rt.cpan.org
From: Benjamin Börngen-Schmidt <benjamin [...] boerngen-schmidt.de>
Hi there, I don't know if it is a bug or a limitation but I'm not able to connect to a proftpd server ver. 1.3.3 until I set "TLSOptions NoSessionReuseRequired". Log from proftpd: mod_tls/2.4.2[22028]: Protection set to Private mod_tls/2.4.2[22028]: starting TLS negotiation on data connection mod_tls/2.4.2[22028]: TLSv1/SSLv3 renegotiation accepted, using cipher DHE-RSA-AES256-SHA (256 bits) mod_tls/2.4.2[22028]: client did not reuse SSL session, rejecting data connection (see TLSOption NoSessionReuseRequired) Regards Benjamin
Hi Benjamin, This is a known limitation I hit while I was trying to get certificates to work at all for the data channel last year. I was never quite sure if I was configuring my server incorrectly or I had issues with my client code or if it was a problem with IO::Socket::SSL or if I was just using the wrong IO::Socket::SSL options with SSL_Client_Certificate. So I just gave up on it in order to get v0.18 out. The person asking for this feature didn't need the session reuse option. And I haven't had the opportunity to revisit the issue since then. But I'll be glad to look into it again if you can return the log files generated by my code. And since we'll be dealing with very low level functionality on my end, I'm going to give you some extra instructions to get more detailed client logs than I usually ask for. use IO::Socket::SSL qw(debug3); # Turn on verbose SSL logging open (STDERR, "> myLogfile.txt"); # Redirect STDERR to a log file. # Turns logging on to STDERR for Net::FTPSSL ... my $ftps = Net::FTPSSL->new (server, ..., Debug=>1); This will make sure I have all possible client side logging available. Let me know what options you are using for the SSL_Client_Certificate option. Since that's more than likely part of the issue. When I create the data channel, I use just the SSL_reuse_ctx option, which re-uses the context of the command channel. So I'll have to look into what else is needed to reuse the session. Also please let me know what version of IO::Socket::SSL you are using. That will probably be critical. I look forward to hearing back from you. Curtis On Tue Mar 27 18:01:05 2012, benjamin@boerngen-schmidt.de wrote: Show quoted text
> Hi there, > > I don't know if it is a bug or a limitation but I'm not able to connect > to a proftpd server ver. 1.3.3 until I set "TLSOptions > NoSessionReuseRequired". > > Log from proftpd: > mod_tls/2.4.2[22028]: Protection set to Private > mod_tls/2.4.2[22028]: starting TLS negotiation on data connection > mod_tls/2.4.2[22028]: TLSv1/SSLv3 renegotiation accepted, using cipher > DHE-RSA-AES256-SHA (256 bits) > mod_tls/2.4.2[22028]: client did not reuse SSL session, rejecting data > connection (see TLSOption NoSessionReuseRequired) > > Regards > Benjamin
From: j.gruber [...] primacom.net
Hi Curtis, just chiming in as I hit the wall with this bug as well. Attached you will find the logfile as requested. It was created as per your instructions. Let me know if you need more. Show quoted text
> Let me know what options you are using for the SSL_Client_Certificate > option.
None so far Show quoted text
> I use just the SSL_reuse_ctx option, which re-uses the > context of the command channel. So I'll have to look into what else > is needed to reuse the session.
I am already using this option (Session reuse didn't work before, so I tried to get it to work by myself): <snip> $context = new IO::Socket::SSL::SSL_Context( SSL_version => 'tlsv1', SSL_verify_mode => Net::SSLeay::VERIFY_NONE(), SSL_session_cache_size => 10 ); $handle = Net::FTPSSL->new( $server, Encryption => IMP_CRYPT, Debug => $debugTransfer, OverridePASV => $server, SSL_reuse_ctx => $context, ); </snip> No luck so far, I am preparing to dive into FTPSSL.pm as I type this. Show quoted text
> Also please let me know what version of IO::Socket::SSL you are using. > That will probably be critical.
IO::Socket::SSL Version is 1.33 (Debian Squeeze System) PS: I tried all previous versions down to 0.17. They all exhibited the same behavior (session reuse didn't work). Best regards, Jan
Subject: sslLog.txt
DEBUG: .../IO/Socket/SSL.pm:1464: new ctx 43430256 Net-FTPSSL Version: 0.22 Perl: 5.010001 [5.10.1], OS: linux Server (port): 81.210.128.101 (990) Keys: (OverridePASV), (SSL_reuse_ctx), (Debug), (Encryption) Values: (xx.xxx.xxx.xxx), (IO::Socket::SSL::SSL_Context=HASH(0x2a71258)), (2), (I) DEBUG: .../IO/Socket/SSL.pm:1464: new ctx 45063840 DEBUG: .../IO/Socket/SSL.pm:938: start handshake DEBUG: .../IO/Socket/SSL.pm:347: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:378: set socket to non-blocking to enforce timeout=120 DEBUG: .../IO/Socket/SSL.pm:390: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:400: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:410: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:430: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:390: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:400: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:410: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:430: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:390: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:445: ssl handshake done <<< 220 Welcome to xxxxxxxxxxx >>> USER +++++++ <<< 331 Please specify the password. >>> PASS ******* <<< 230 Login successful. DEBUG: .../IO/Socket/SSL.pm:1500: free ctx 43430256 open=45063840 43430256 DEBUG: .../IO/Socket/SSL.pm:1508: OK free ctx 43430256 >>> PWD <<< 257 "/" >>> CWD /Transmit/Content <<< 250 Directory successfully changed. >>> PBSZ 0 <<< 200 PBSZ set to 0. >>> PROT P <<< 200 PROT now Private. >>> PASV <<< 227 Entering Passive Mode (172,21,2,70,47,53). --- Overriding PASV IP Address 172.21.2.70 with 81.210.128.101 --- Host (81.210.128.101) Port (12085) >>> LIST <<< 150 Here comes the directory listing. <<< 522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page >>> CWD / <<< 250 Directory successfully changed. >>> MKD /Transmit/Content/SILV20121000000018 <<< 550 Create directory operation failed. DEBUG: .../IO/Socket/SSL.pm:1500: free ctx 45063840 open=45063840 DEBUG: .../IO/Socket/SSL.pm:1508: OK free ctx 45063840 ########################################### Manual addition of cmdline output got 0:0 bytes (VM=vm_unknown). at blib/lib/Net/SSLeay.pm (autosplit into blib/lib/auto/Net/SSLeay/debug_read.al) line 1836 Net::SSLeay::debug_read('SCALAR(0x2aa1960)', 'SCALAR(0x2aa1870)') called at blib/lib/Net/SSLeay.pm (autosplit into blib/lib/auto/Net/SSLeay/ssl_read_all.al) line 1854 Net::SSLeay::ssl_read_all(44269888, 10240) called at /usr/lib/perl5/Net/SSLeay/Handle.pm line 128 Net::SSLeay::Handle::READ('Net::SSLeay::Handle=HASH(0x2aa0c48)', undef, 10240) called at /usr/local/share/perl/5.10.1/Net/FTPSSL.pm line 591 Net::FTPSSL::list('Net::FTPSSL=GLOB(0x29f9f30)') called at /usr/local/lib/site_perl/..... <snip>
From: j.gruber [...] primacom.net
Addendum: A brief excursion into FTPSSL.pm showed that session_reuse is triggered only when SSL_Client_Certificate or SSL_Advanced Hashes are present in the constructor. Since this is not the case with my code I patched FTPSSL.pm at line 291 to get it to work. + (exists ($arg->{SSL_reuse_ctx})) || The resulting logfile is attached. Best regards, Jan
Subject: sslLog.txt-with-own-context
Download sslLog.txt-with-own-context
application/octet-stream 3.6k

Message body not shown because it is not plain text.

Hi Jan, Sorry to take so long to respond. Your issue was slightly different than the original issue. Sessions & context are different things. Context was the easy one to solve. Based on your comments & logs, you were trying to re-use context without using certificates. And from your comments below that you only modified one line of code, you could have gotten the exact same results without modifying the code at all by doing the following in your call to new. my %emptyHash; my $ftps = Net::FTPSSL->new ($server, SSL_Client_Certificate => \%emptyHash, ...); It's the presence of this option, whether there is anything in the hash or not, that triggers the use of the reuse context for the data channel. While the main purpose of SSL_Client_Certificate is to allow you to use certificates, it's not it's only possible use. I'll rework the POD text for this option to make that clearer and to make sure this trick is mentioned in future releases. Curtis On Fri Aug 24 09:16:03 2012, htuttle wrote: Show quoted text
> Addendum: > > A brief excursion into FTPSSL.pm showed that session_reuse is triggered > only when SSL_Client_Certificate or SSL_Advanced Hashes are present in > the constructor. Since this is not the case with my code I patched > FTPSSL.pm at line 291 to get it to work. > > + (exists ($arg->{SSL_reuse_ctx})) || > > The resulting logfile is attached. > > Best regards, > Jan
From: j.gruber [...] primacom.net
Hi Curtis, On Tue Aug 28 13:06:00 2012, CLEACH wrote: Show quoted text
> Hi Jan, > > Sorry to take so long to respond.
Don't worry, it's your spare time ... Show quoted text
> Your issue was slightly different than the original issue. Sessions & > context are different things. Context was the easy one to solve. > > Based on your comments & logs, you were trying to re-use context > without using certificates.
Maybe I have context and session reuse mixed up. I have got bitten by the ssl session reuse bug (I have to connect to a FTPS Server who requires session reuse for data channels). The only thing in the documentation that had the word "reuse" in it was the context thing, so I went to try it out. If that is the wrong route I apologize for causing confusion. What can I do to help to solve the session reuse problem? I will try the failed upload from a different server with another linux distro to exclude the possibility of problems with the GNUTLS/OpenSSL libraries on Debian.
From: j.gruber [...] primacom.net
The OpenSSL/GNUTLS libraries seem not to be the problem. I uploaded the data from the same system to the same target as previously tried with the "lftp" client and succeeded. This means that session reuse works in principle (at least with GNUTLS). Which libraries is FTPSSL using?
Hi Jan, Glad to see that you were still looking into it. My test server has crashed and I've had no chance lately to look into whats wrong with it. It's beginning to look like I'll have to reinstall everything from scratch. Net::FTPSSL inherits from IO::Socket::SSL and I'm guessing that I'm missing an option there to reuse sessions. But I currently don't know what those option(s) may be. I have a sneaking suspicion that reuse context isn't enough even if we add more options using SSL_Client_Certificate. My best guess is it's a combination of the following 3 options: SSL_session_cache_size, SSL_session_cache or SSL_session_id_context. If you can provide me a command trace from your successful test with the "lftp" client, that might help me a lot. Curtis On Wed Sep 05 02:44:13 2012, htuttle wrote: Show quoted text
> The OpenSSL/GNUTLS libraries seem not to be the problem. I uploaded the > data from the same system to the same target as previously tried with the > "lftp" client and succeeded. This means that session reuse works in > principle (at least with GNUTLS). Which libraries is FTPSSL using?
From: j.gruber [...] primacom.net
Hi Curtis, Show quoted text
> If you can provide me a command trace from your successful test with
the Show quoted text
> "lftp" client, that might help me a lot.
unfortunately lftp doesn't provide a debug log/cmd trace wrt to SSL activities. I will continue to look for a way to provide you with the necessary information.
Subject: [rt.cpan.org #76108]
Date: Wed, 13 May 2015 11:57:57 -0400
To: <bug-Net-FTPSSL [...] rt.cpan.org>
From: "Forrest Tiffany" <forrestt [...] usa.net>
I know this is an old bug, but I needed to support session reuse in a project I'm working on.  I have it working (although a bit of a kludge).  Here is a diff of FTPSSL.pm:

269a270,271
>      my $cache = IO::Socket::SSL::Session_Cache->new(10);
>
282a285,286
>      $ssl_args{SSL_session_cache} = $cache;
>      $ssl_args{SSL_session_key} = 'abcd1234';
657a662
>      $ssl_opts{SSL_session_key} = 'abcd1234';


I used 'abcd1234' as the session key because I couldn't quickly figure out how to access the original host/port to give the line at #662 the original values to reuse (i.e. "$commandChannelHost:$commandChannelPort").  This should point you in the right direction though.

Forrest

Subject: [rt.cpan.org #76108]
Date: Thu, 28 May 2015 11:29:22 -0400
To: <bug-Net-FTPSSL [...] rt.cpan.org>
From: "Forrest Tiffany" <forrestt [...] usa.net>

Message body is not shown because it is too large.

Subject: [rt.cpan.org #76108]
Date: Thu, 28 May 2015 11:56:01 -0400
To: <bug-Net-FTPSSL [...] rt.cpan.org>
From: "Forrest Tiffany" <forrestt [...] usa.net>
Show quoted text
> Hi Forrest, > > Thank you for using my module and taking the time to open a new CPAN bug
report and submitting Show quoted text
> a patch. > > I'll look into it as soon as I can. In the meantime, can you please give
me a trace using your Show quoted text
> patch so that I can follow your logs on what is happening? > > This will give me some needed information on implementing it. Including
the version of my software Show quoted text
> you are using. Also can you please let me know what version of
IO::Socket::SSL you are using? Show quoted text
> My logs don't currently tell me that. > > Try doing this in your sample program: > > use IO::Socket::SSL qw (debug3): # Turns on verbose SSL loging. > use Net::FTPSSL; > > open (STDERR, "> myLogfile.txt"); # Redirects STDERR to this file. > $ftps = Net::FTPSSL->new ($server, ..., Debug=>1); > $ftps->trapWarn (); > $ftps->login (user,pwd); > $ftps->nlst(); > $ftps->quit(); > > The above code snippet should be enough to demonstrate your patch in
action & the logs should help Show quoted text
> me out a lot. > > Thanks > > Curtis
Sorry it has taken so long to get back to you. Life gets in the way of progress at times. Here is the short program that I used along with the contents of the log. Note, Met::FTPSSL is a modified Net::FTPSSL 0.27 module with the four lines changed as indicated in the previous post. If there is any other information I can provide, please let me know. (Resending in plain text as the last post wasn't readable). Forrest ---------------------- test.pl ------------------------------------ #!/usr/bin/perl use lib "./lib"; use IO::Socket::SSL qw (debug3); # Turns on verbose SSL loging. use Met::FTPSSL; open (STDERR, "> myLogfile.txt"); # Redirects STDERR to this file. my %connectionHash = ( Port => 21, Encryption => 'E', Debug => 1, OverridePASV => '192.168.0.200', Croak => 0, PreserveTimestamp => 0, ); %sslHash = ( SSL_cert_file => 'C:\Users\ftiffany\Documents\ssl\forrest.pem', SSL_reuse_ctx => '', SSL_key_file => 'C:\Users\ftiffany\Documents\ssl\forrest.key', SSL_ca_file => 'C:\Users\ftiffany\Documents\ssl\CA.crt', SSL_use_cert => 1, ); $connectionHash{SSL_Client_Certificate} = \%sslHash; my $ftps = Met::FTPSSL->new( '192.168.0.200', %connectionHash, ); $ftps->trapWarn (); $ftps->login ('forrest', '********'); $ftps->nlst(); $ftps->quit(); ------------------------------------------------ End test.pl --------------------------------- Here are the contents of the log: Net-FTPSSL Version: 0.27 Perl: 5.018004 [5.18.4], OS: MSWin32 Server (port): 192.168.0.200 (21) Keys: (SSL_Client_Certificate), (Debug), (PreserveTimestamp), (OverridePASV), (Croak), (Port), (Encryption) Values: (HASH(0x3527798)), (1), (0), (192.168.0.200), (0), (21), (E) SKT <<< 220 (vsFTPd 3.0.2) SKT >>> AUTH TLS SKT <<< 234 Proceed with negotiation. DEBUG: .../IO/Socket/SSL.pm:2634: new ctx 53008208 DEBUG: .../IO/Socket/SSL.pm:1376: start handshake DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is unknown DEBUG: .../IO/Socket/SSL.pm:660: set socket to non-blocking to enforce timeout=120 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=3726976 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=58351280 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=58351104 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=58350928 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done Object HASH Details ... (SSL_Client_Certificate:options - E) SSL_ca_file ==> C:\Users\ftiffany\Documents\ssl\CA.crt SSL_cert_file ==> C:\Users\ftiffany\Documents\ssl\forrest.pem SSL_key_file ==> C:\Users\ftiffany\Documents\ssl\forrest.key SSL_reuse_ctx ==> SSL_use_cert ==> 1 Object Met::FTPSSL Details ... (192.168.0.200:21 - E) Croak ==> (undef) Crypt ==> E FixGetTs ==> 0 FixPutTs ==> 0 Host ==> 192.168.0.200 OverridePASV ==> 192.168.0.200 Pret ==> 0 Timeout ==> 120 _SSL_arguments ==> HASH(0x36c9f50) -- PeerAddr ===> 192.168.0.200 -- PeerPort ===> 21 -- Proto ===> tcp -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt -- SSL_cert_file ===> C:\Users\ftiffany\Documents\ssl\forrest.pem -- SSL_check_crl ===> 0 -- SSL_cipher_list ===> ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA DHE-DSS-AES128-SHA256 DHE-DSS-AES128-SHA DHE-DSS-AES256-SHA256 DHE-DSS-AES256-SHA AES128-SHA256 AES128-SHA AES256-SHA256 AES256-SHA EDH-DSS-DES-CBC3-SHA DES-CBC3-SHA RC4-SHA !EXP !LOW !eNULL !aNULL !DES !MD5 !PSK !SRP -- SSL_key_file ===> C:\Users\ftiffany\Documents\ssl\forrest.key -- SSL_reuse_ctx ===> -- SSL_server ===> 0 -- SSL_session_cache ===> IO::Socket::SSL::Session_Cache=HASH(0x3acd40) -- _head ----> HASH(0x36cbb98) -- _maxsize ----> 10 -- abcd1234:1 ----> HASH(0x36cbb98) -- SSL_session_key ===> abcd1234 -- SSL_use_cert ===> 1 -- SSL_verify_callback ===> CODE(0x36ca0e8) -- SSL_verify_mode ===> 1 -- SSL_version ===> TLSv1 _SSL_ctx ==> IO::Socket::SSL::SSL_Context=HASH(0x36ca0d0) -- context ===> 53008208 -- ocsp_mode ===> 16 -- session_cache ===> IO::Socket::SSL::Session_Cache=HASH(0x3acd40) -- _head ----> HASH(0x36cbb98) -- _maxsize ----> 10 -- abcd1234:1 ----> HASH(0x36cbb98) -- verify_mode ===> 1 -- verify_name_ref ===> SCALAR(0x323f3e0) [192.168.0.200] _SSL_fileno ==> 3 _SSL_ioclass_upgraded ==> IO::Socket::INET _SSL_last_err ==> ARRAY(0x36cbc10) _SSL_object ==> 58358768 _SSL_opened ==> 1 buf_size ==> 10240 data_prot ==> P dcsc_mode ==> 1 debug ==> 1 debug_extra ==> 0 io_sock_nonblocking ==> 0 io_socket_domain ==> 2 io_socket_proto ==> 6 io_socket_timeout ==> 120 io_socket_type ==> 1 last_ftp_msg ==> 234 Proceed with negotiation. myContext ==> HASH(0x352d6a8) -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt -- SSL_reuse_ctx ===> IO::Socket::SSL::SSL_Context=HASH(0x36ca0d0) -- context ----> 53008208 -- ocsp_mode ----> 16 -- session_cache ----> IO::Socket::SSL::Session_Cache=HASH(0x3acd40) -- verify_mode ----> 1 -- verify_name_ref ----> SCALAR(0x323f3e0) [192.168.0.200] mySocketOpts ==> HASH(0x352cba8) -- PeerAddr ===> 192.168.0.200 -- PeerPort ===> 21 -- Proto ===> tcp -- Timeout ===> 120 trace ==> 0 type ==> A Show quoted text
>>> USER +++++++
<<< 331 Please specify the password. Show quoted text
>>> PASS *******
<<< 230 Login successful. Show quoted text
>>> HELP
<<< 214-The following commands are recognized. <<< ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD <<< MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR <<< RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD <<< XPWD XRMD <<< 214 Help OK. Show quoted text
>>> FEAT
<<< 211-Features: <<< AUTH TLS <<< EPRT <<< EPSV <<< MDTM <<< PASV <<< PBSZ <<< PROT <<< REST STREAM <<< SIZE <<< TVFS <<< UTF8 <<< 211 End <<+ 214 The HELP command is supported. Show quoted text
>>> PBSZ 0
<<< 200 PBSZ set to 0. Show quoted text
>>> PROT P
<<< 200 PROT now Private. Show quoted text
>>> PASV
<<< 227 Entering Passive Mode (192,168,0,200,233,30). --- Overriding PASV IP Address 192.168.0.200 with 192.168.0.200 --- Host (192.168.0.200) Port (59678) Show quoted text
>>> NLST
<<< 150 Here comes the directory listing. DEBUG: .../IO/Socket/SSL.pm:1376: start handshake DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is unknown DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done <<< 226 Directory send OK. Show quoted text
>>> QUIT
<<< 221 Goodbye. DEBUG: .../IO/Socket/SSL.pm:2667: free ctx 53008208 open=53008208 DEBUG: .../IO/Socket/SSL.pm:2672: free ctx 53008208 callback DEBUG: .../IO/Socket/SSL.pm:2679: OK free ctx 53008208
Hi Forrest, Attached is a beta with a variation of your patch included. I've also improved on the logging a bit to help me see what's going on. My logs didn't go deep enough to follow everything. If I see what I expect to see, I'll have a better way to assign the SSL_session_key. Can you please rerun your test against this beta of Net::FTPSSL ?? Also when you send the logs back to me, can you please send it back as an attachment? Sending it as text in the body of a message tends to merge things together in the final email. When I implement a final release, I plan on adding a new option called "ReuseSession=>1" so that this logic is conditional. Since not everyone will need it. Curtis On Thu May 28 11:56:20 2015, forrestt@usa.net wrote: Show quoted text
> >
> > Hi Forrest, > > > > Thank you for using my module and taking the time to open a new CPAN > > bug
> report and submitting
> > a patch. > > > > I'll look into it as soon as I can. In the meantime, can you please > > give
> me a trace using your
> > patch so that I can follow your logs on what is happening? > > > > This will give me some needed information on implementing it. > > Including
> the version of my software
> > you are using. Also can you please let me know what version of
> IO::Socket::SSL you are using?
> > My logs don't currently tell me that. > > > > Try doing this in your sample program: > > > > use IO::Socket::SSL qw (debug3): # Turns on verbose SSL loging. > > use Net::FTPSSL; > > > > open (STDERR, "> myLogfile.txt"); # Redirects STDERR to this file. > > $ftps = Net::FTPSSL->new ($server, ..., Debug=>1); > > $ftps->trapWarn (); > > $ftps->login (user,pwd); > > $ftps->nlst(); > > $ftps->quit(); > > > > The above code snippet should be enough to demonstrate your patch in
> action & the logs should help
> > me out a lot. > > > > Thanks > > > > Curtis
> > > Sorry it has taken so long to get back to you. Life gets in the way > of > progress at times. Here is the short program that I used along with > the > contents of the log. Note, Met::FTPSSL is a modified Net::FTPSSL 0.27 > module > with the four lines changed as indicated in the previous post. If > there is > any other information I can provide, please let me know. (Resending > in plain > text as the last post wasn't readable). > > Forrest > > ---------------------- test.pl ------------------------------------ > #!/usr/bin/perl > use lib "./lib"; > use IO::Socket::SSL qw (debug3); # Turns on verbose SSL loging. > use Met::FTPSSL; > > open (STDERR, "> myLogfile.txt"); # Redirects STDERR to this file. > my %connectionHash = ( > Port => 21, > Encryption => 'E', > Debug => 1, > OverridePASV => '192.168.0.200', > Croak => 0, > PreserveTimestamp => 0, > ); > > %sslHash = ( > SSL_cert_file => 'C:\Users\ftiffany\Documents\ssl\forrest.pem', > SSL_reuse_ctx => '', > SSL_key_file => 'C:\Users\ftiffany\Documents\ssl\forrest.key', > SSL_ca_file => 'C:\Users\ftiffany\Documents\ssl\CA.crt', > SSL_use_cert => 1, > ); > $connectionHash{SSL_Client_Certificate} = \%sslHash; > > my $ftps = Met::FTPSSL->new( > '192.168.0.200', > %connectionHash, > ); > > $ftps->trapWarn (); > $ftps->login ('forrest', '********'); > $ftps->nlst(); > $ftps->quit(); > ------------------------------------------------ End test.pl > --------------------------------- > Here are the contents of the log: > > > Net-FTPSSL Version: 0.27 > > Perl: 5.018004 [5.18.4], OS: MSWin32 > > Server (port): 192.168.0.200 (21) > > Keys: (SSL_Client_Certificate), (Debug), (PreserveTimestamp), > (OverridePASV), > (Croak), (Port), (Encryption) > Values: (HASH(0x3527798)), (1), (0), (192.168.0.200), (0), (21), (E) > > SKT <<< 220 (vsFTPd 3.0.2) > SKT >>> AUTH TLS > SKT <<< 234 Proceed with negotiation. > DEBUG: .../IO/Socket/SSL.pm:2634: new ctx 53008208 > DEBUG: .../IO/Socket/SSL.pm:1376: start handshake > DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started > DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is > unknown > DEBUG: .../IO/Socket/SSL.pm:660: set socket to non-blocking to enforce > timeout=120 > DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 > DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress > DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL > wants a > read first > DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect > DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=3726976 > DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=58351280 > DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=58351104 > DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=58350928 > DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 > DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress > DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL > wants a > read first > DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect > DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 > DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done > > Object HASH Details ... (SSL_Client_Certificate:options - E) > SSL_ca_file ==> C:\Users\ftiffany\Documents\ssl\CA.crt > SSL_cert_file ==> C:\Users\ftiffany\Documents\ssl\forrest.pem > SSL_key_file ==> C:\Users\ftiffany\Documents\ssl\forrest.key > SSL_reuse_ctx ==> > SSL_use_cert ==> 1 > > > Object Met::FTPSSL Details ... (192.168.0.200:21 - E) > Croak ==> (undef) > Crypt ==> E > FixGetTs ==> 0 > FixPutTs ==> 0 > Host ==> 192.168.0.200 > OverridePASV ==> 192.168.0.200 > Pret ==> 0 > Timeout ==> 120 > _SSL_arguments ==> HASH(0x36c9f50) > -- PeerAddr ===> 192.168.0.200 > -- PeerPort ===> 21 > -- Proto ===> tcp > -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt > -- SSL_cert_file ===> > C:\Users\ftiffany\Documents\ssl\forrest.pem > -- SSL_check_crl ===> 0 > -- SSL_cipher_list ===> ECDHE-ECDSA-AES128-GCM-SHA256 > ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 > ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256- > SHA > ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA > DHE-DSS-AES128-SHA256 DHE-DSS-AES128-SHA DHE-DSS-AES256-SHA256 > DHE-DSS-AES256-SHA AES128-SHA256 AES128-SHA AES256-SHA256 AES256-SHA > EDH-DSS-DES-CBC3-SHA DES-CBC3-SHA RC4-SHA !EXP !LOW !eNULL !aNULL !DES > !MD5 > !PSK !SRP > -- SSL_key_file ===> > C:\Users\ftiffany\Documents\ssl\forrest.key > -- SSL_reuse_ctx ===> > -- SSL_server ===> 0 > -- SSL_session_cache ===> > IO::Socket::SSL::Session_Cache=HASH(0x3acd40) > -- _head ----> HASH(0x36cbb98) > -- _maxsize ----> 10 > -- abcd1234:1 ----> HASH(0x36cbb98) > -- SSL_session_key ===> abcd1234 > -- SSL_use_cert ===> 1 > -- SSL_verify_callback ===> CODE(0x36ca0e8) > -- SSL_verify_mode ===> 1 > -- SSL_version ===> TLSv1 > _SSL_ctx ==> IO::Socket::SSL::SSL_Context=HASH(0x36ca0d0) > -- context ===> 53008208 > -- ocsp_mode ===> 16 > -- session_cache ===> > IO::Socket::SSL::Session_Cache=HASH(0x3acd40) > -- _head ----> HASH(0x36cbb98) > -- _maxsize ----> 10 > -- abcd1234:1 ----> HASH(0x36cbb98) > -- verify_mode ===> 1 > -- verify_name_ref ===> SCALAR(0x323f3e0) [192.168.0.200] > _SSL_fileno ==> 3 > _SSL_ioclass_upgraded ==> IO::Socket::INET > _SSL_last_err ==> ARRAY(0x36cbc10) > _SSL_object ==> 58358768 > _SSL_opened ==> 1 > buf_size ==> 10240 > data_prot ==> P > dcsc_mode ==> 1 > debug ==> 1 > debug_extra ==> 0 > io_sock_nonblocking ==> 0 > io_socket_domain ==> 2 > io_socket_proto ==> 6 > io_socket_timeout ==> 120 > io_socket_type ==> 1 > last_ftp_msg ==> 234 Proceed with negotiation. > myContext ==> HASH(0x352d6a8) > -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt > -- SSL_reuse_ctx ===> > IO::Socket::SSL::SSL_Context=HASH(0x36ca0d0) > -- context ----> 53008208 > -- ocsp_mode ----> 16 > -- session_cache ----> > IO::Socket::SSL::Session_Cache=HASH(0x3acd40) > -- verify_mode ----> 1 > -- verify_name_ref ----> SCALAR(0x323f3e0) > [192.168.0.200] > mySocketOpts ==> HASH(0x352cba8) > -- PeerAddr ===> 192.168.0.200 > -- PeerPort ===> 21 > -- Proto ===> tcp > -- Timeout ===> 120 > trace ==> 0 > type ==> A >
> >>> USER +++++++
> <<< 331 Please specify the password.
> >>> PASS *******
> <<< 230 Login successful.
> >>> HELP
> <<< 214-The following commands are recognized. > <<< ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM > MKD > <<< MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD > RNFR > <<< RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD > XMKD > <<< XPWD XRMD > <<< 214 Help OK.
> >>> FEAT
> <<< 211-Features: > <<< AUTH TLS > <<< EPRT > <<< EPSV > <<< MDTM > <<< PASV > <<< PBSZ > <<< PROT > <<< REST STREAM > <<< SIZE > <<< TVFS > <<< UTF8 > <<< 211 End > <<+ 214 The HELP command is supported.
> >>> PBSZ 0
> <<< 200 PBSZ set to 0.
> >>> PROT P
> <<< 200 PROT now Private.
> >>> PASV
> <<< 227 Entering Passive Mode (192,168,0,200,233,30). > --- Overriding PASV IP Address 192.168.0.200 with 192.168.0.200 > --- Host (192.168.0.200) Port (59678)
> >>> NLST
> <<< 150 Here comes the directory listing. > DEBUG: .../IO/Socket/SSL.pm:1376: start handshake > DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started > DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is > unknown > DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 > DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done > <<< 226 Directory send OK.
> >>> QUIT
> <<< 221 Goodbye. > DEBUG: .../IO/Socket/SSL.pm:2667: free ctx 53008208 open=53008208 > DEBUG: .../IO/Socket/SSL.pm:2672: free ctx 53008208 callback > DEBUG: .../IO/Socket/SSL.pm:2679: OK free ctx 53008208 >
Subject: FTPSSL.pm

Message body is not shown because it is too large.

Subject: [rt.cpan.org #76108]
Date: Fri, 05 Jun 2015 11:05:22 -0400
To: <bug-Net-FTPSSL [...] rt.cpan.org>
From: "Forrest Tiffany" <forrestt [...] usa.net>
Here is the output from the script. Also, I used 10 for the cache size just arbitrarily. I believe it only needs to be 1 (the number of connections to cache), but I wasn't 100% sure, so I padded it to 10. I'm also pretty sure the session key is "IP:commandPort" of the server you are connecting to by default. I would have used that when I assigned the key for the command channel, but I couldn't find where you were storing those values and figured what would take me hours to find you would know off the top of your head. So, instead of using the default key when the data channel needed a key, I set the command channel key to "abcd1234" so I would know what it was when it needed to be set for the data channel. I'd suggest you just remove the setting of the key for the command channel and use the default key value when you set the data channel's key. Forrest
Net-FTPSSL Version: 0.27_01 IO-Socket-SSL Version: 2.015 Perl: 5.018004 [5.18.4], OS: MSWin32 Server (port): 192.168.0.200 (21) Keys: (Encryption), (OverridePASV), (Croak), (Debug), (PreserveTimestamp), (SSL_Client_Certificate), (Port) Values: (E), (192.168.0.200), (0), (1), (0), (HASH(0x3735778)), (21) Object HASH Details ... (Before start_SSL() call:initialization - E) SSL_ca_file ==> C:\Users\ftiffany\Documents\ssl\CA.crt SSL_cert_file ==> C:\Users\ftiffany\Documents\ssl\forrest.pem SSL_key_file ==> C:\Users\ftiffany\Documents\ssl\forrest.key SSL_reuse_ctx ==> SSL_session_cache ==> IO::Socket::SSL::Session_Cache=HASH(0x2dd8730) -- _maxsize ===> 10 SSL_session_key ==> abcd1234 SSL_use_cert ==> 1 SSL_version ==> TLSv1 Timeout ==> 120 <<< 220 (vsFTPd 3.0.2) >>> AUTH TLS <<< 234 Proceed with negotiation. DEBUG: .../IO/Socket/SSL.pm:2634: new ctx 52737264 DEBUG: .../IO/Socket/SSL.pm:1376: start handshake DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is unknown DEBUG: .../IO/Socket/SSL.pm:660: set socket to non-blocking to enforce timeout=120 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=47156032 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=51354800 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=51354624 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=51354448 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done *** Adding: SSL_session_key --> abcd1234 *** Object HASH Details ... (SSL_Client_Certificate:options - E) SSL_ca_file ==> C:\Users\ftiffany\Documents\ssl\CA.crt SSL_cert_file ==> C:\Users\ftiffany\Documents\ssl\forrest.pem SSL_key_file ==> C:\Users\ftiffany\Documents\ssl\forrest.key SSL_reuse_ctx ==> SSL_use_cert ==> 1 Object Met::FTPSSL Details ... (192.168.0.200:21 - E) Croak ==> (undef) Crypt ==> E FixGetTs ==> 0 FixPutTs ==> 0 Host ==> 192.168.0.200 OverridePASV ==> 192.168.0.200 Pret ==> 0 Timeout ==> 120 _SSL_arguments ==> HASH(0x38cf7f0) -- PeerAddr ===> 192.168.0.200 -- PeerPort ===> 21 -- Proto ===> tcp -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt -- SSL_cert_file ===> C:\Users\ftiffany\Documents\ssl\forrest.pem -- SSL_check_crl ===> 0 -- SSL_cipher_list ===> ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA DHE-DSS-AES128-SHA256 DHE-DSS-AES128-SHA DHE-DSS-AES256-SHA256 DHE-DSS-AES256-SHA AES128-SHA256 AES128-SHA AES256-SHA256 AES256-SHA EDH-DSS-DES-CBC3-SHA DES-CBC3-SHA RC4-SHA !EXP !LOW !eNULL !aNULL !DES !MD5 !PSK !SRP -- SSL_key_file ===> C:\Users\ftiffany\Documents\ssl\forrest.key -- SSL_reuse_ctx ===> -- SSL_server ===> 0 -- SSL_session_cache ===> IO::Socket::SSL::Session_Cache=HASH(0x2dd8730) -- _head ----> HASH(0x38d3db8) -- key ++++> abcd1234:1 -- next ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- session ++++> 56757056 -- _maxsize ----> 10 -- abcd1234:1 ----> HASH(0x38d3db8) -- key ++++> abcd1234:1 -- next ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- session ++++> 56757056 -- SSL_session_key ===> abcd1234 -- SSL_use_cert ===> 1 -- SSL_verify_callback ===> CODE(0x38d2368) -- SSL_verify_mode ===> 1 -- SSL_version ===> TLSv1 _SSL_ctx ==> IO::Socket::SSL::SSL_Context=HASH(0x38d2350) -- context ===> 52737264 -- ocsp_mode ===> 16 -- session_cache ===> IO::Socket::SSL::Session_Cache=HASH(0x2dd8730) -- _head ----> HASH(0x38d3db8) -- key ++++> abcd1234:1 -- next ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- session ++++> 56757056 -- _maxsize ----> 10 -- abcd1234:1 ----> HASH(0x38d3db8) -- key ++++> abcd1234:1 -- next ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- session ++++> 56757056 -- verify_mode ===> 1 -- verify_name_ref ===> SCALAR(0x324e1a0) [192.168.0.200] _SSL_fileno ==> 3 _SSL_last_err ==> ARRAY(0x38d3e00) [SSL wants a read first, 4] _SSL_object ==> 59788848 _SSL_opened ==> 1 buf_size ==> 10240 data_prot ==> P dcsc_mode ==> 1 debug ==> 1 debug_extra ==> 0 io_sock_nonblocking ==> 0 io_socket_domain ==> 2 io_socket_proto ==> 6 io_socket_timeout ==> 120 io_socket_type ==> 1 last_ftp_msg ==> 234 Proceed with negotiation. myContext ==> HASH(0x373b7d8) -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt -- SSL_reuse_ctx ===> IO::Socket::SSL::SSL_Context=HASH(0x38d2350) -- context ----> 52737264 -- ocsp_mode ----> 16 -- session_cache ----> IO::Socket::SSL::Session_Cache=HASH(0x2dd8730) -- _head ++++> HASH(0x38d3db8) -- key ====> abcd1234:1 -- next ====> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- prev ====> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- session ====> 56757056 -- _maxsize ++++> 10 -- abcd1234:1 ++++> HASH(0x38d3db8) -- key ====> abcd1234:1 -- next ====> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- prev ====> HASH(0x38d3db8) ... Infinite Hash Loop Detected! -- session ====> 56757056 -- verify_mode ----> 1 -- verify_name_ref ----> SCALAR(0x324e1a0) [192.168.0.200] -- SSL_session_key ===> abcd1234 mySocketOpts ==> HASH(0x373acb0) -- PeerAddr ===> 192.168.0.200 -- PeerPort ===> 21 -- Proto ===> tcp -- Timeout ===> 120 trace ==> 0 type ==> A >>> USER +++++++ <<< 331 Please specify the password. >>> PASS ******* <<< 230 Login successful. >>> HELP <<< 214-The following commands are recognized. <<< ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD <<< MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR <<< RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD <<< XPWD XRMD <<< 214 Help OK. >>> FEAT <<< 211-Features: <<< AUTH TLS <<< EPRT <<< EPSV <<< MDTM <<< PASV <<< PBSZ <<< PROT <<< REST STREAM <<< SIZE <<< TVFS <<< UTF8 <<< 211 End <<+ 214 The HELP command is supported. >>> PBSZ 0 <<< 200 PBSZ set to 0. >>> PROT P <<< 200 PROT now Private. >>> PASV <<< 227 Entering Passive Mode (192,168,0,200,130,156). --- Overriding PASV IP Address 192.168.0.200 with 192.168.0.200 --- Host (192.168.0.200) Port (33436) >>> NLST <<< 150 Here comes the directory listing. DEBUG: .../IO/Socket/SSL.pm:1376: start handshake DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is unknown DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done <<< 226 Directory send OK. >>> QUIT <<< 221 Goodbye. DEBUG: .../IO/Socket/SSL.pm:2667: free ctx 52737264 open=52737264 DEBUG: .../IO/Socket/SSL.pm:2672: free ctx 52737264 callback DEBUG: .../IO/Socket/SSL.pm:2679: OK free ctx 52737264
RT-Send-CC: forrestt [...] usa.net
Hi Forest, I figured as much. But since our FTPS servers are behaving slightly differently, I wanted my 1st Beta to be as close to your code as possible. If you can test out the new beta attached to this email & return the logs, I'd appreciate it. The main problem with setting the SSL_session_key is that I don't usually have the IP Address to use until after the call to start_SSL. Usually the server name is passed to Net::FTPSSL. Which is why I moved the setting of the key value until after that call in this 2nd beta. If this works for you, I'll be ready to release a final v0.28 version that uses a new key to turn this functionality on. (ReuseSession => 1). For backwards compatibility, I can't have this turned on by default. Also why are you using the OverridePASV option? You shouldn't need it since you are using the same value as the host. And the PASV command is returning the correct value according to the logs. This option was added to help you work with misconfigured servers. Curtis On Fri Jun 05 11:05:47 2015, forrestt@usa.net wrote: Show quoted text
> Here is the output from the script. Also, I used 10 for the cache > size just > arbitrarily. I believe it only needs to be 1 (the number of > connections to > cache), but I wasn't 100% sure, so I padded it to 10. I'm also pretty > sure > the session key is "IP:commandPort" of the server you are connecting > to by > default. I would have used that when I assigned the key for the > command > channel, but I couldn't find where you were storing those values and > figured > what would take me hours to find you would know off the top of your > head. So, > instead of using the default key when the data channel needed a key, I > set the > command channel key to "abcd1234" so I would know what it was when it > needed > to be set for the data channel. I'd suggest you just remove the > setting of > the key for the command channel and use the default key value when you > set the > data channel's key. > > Forrest
Subject: FTPSSL.pm

Message body is not shown because it is too large.

Subject: [rt.cpan.org #76108]
Date: Fri, 05 Jun 2015 15:31:38 -0400
To: <bug-Net-FTPSSL [...] rt.cpan.org>
From: "Forrest Tiffany" <forrestt [...] usa.net>
Here is the log. As you can see from the log, that didn't work. I guess I'm not being clear. You shouldn't need to set a key for the command channel. Here are the steps that I think need to be done: 1. Create command channel connection with a cache object 2. Store IP address 3. Store Command Port 4. Create data channel connection using "IP:Command Port" for SSLcache key The reason I'm using OverridePASV is because the real script I wrote (the sample from 28 May, test.pl, is a snippet of it with hard-coded values) connects to servers from thousands of different companies with new ones added all of the time. I don't want to have to have another parameter that the operations staff needs to worry about to determine if PASV needs to be overridden, so I simply set OverridePASV for the new connection. This seemed like the more likely scenario between it and a FTPS server behind a load-balancer for this particular scenario. If it turns out that this isn't the right decision, then I'll modify my code to have that option (although, IMHO it would be better to remove that option in FTPSSL and simply ignore the returned IP value if it is a non-routeable IP and use the origin IP under that case. Forrest
Net-FTPSSL Version: 0.27_02 IO-Socket-SSL Version: 2.015 Perl: 5.018004 [5.18.4], OS: MSWin32 Server (port): 192.168.0.200 (21) Keys: (Encryption), (OverridePASV), (PreserveTimestamp), (Croak), (Debug), (SSL_Client_Certificate), (Port) Values: (E), (192.168.0.200), (0), (0), (1), (HASH(0x3605778)), (21) Object HASH Details ... (Before start_SSL() call:initialization - E) SSL_ca_file ==> C:\Users\ftiffany\Documents\ssl\CA.crt SSL_cert_file ==> C:\Users\ftiffany\Documents\ssl\forrest.pem SSL_key_file ==> C:\Users\ftiffany\Documents\ssl\forrest.key SSL_reuse_ctx ==> SSL_session_cache ==> IO::Socket::SSL::Session_Cache=HASH(0x336930) -- _maxsize ===> 4 SSL_use_cert ==> 1 SSL_version ==> TLSv1 Timeout ==> 120 <<< 220 (vsFTPd 3.0.2) >>> AUTH TLS <<< 234 Proceed with negotiation. DEBUG: .../IO/Socket/SSL.pm:2634: new ctx 51426544 DEBUG: .../IO/Socket/SSL.pm:1376: start handshake DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is unknown DEBUG: .../IO/Socket/SSL.pm:660: set socket to non-blocking to enforce timeout=120 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=50042672 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=50044256 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=50044080 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=50043904 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:686: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:696: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:716: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done *** Adding: SSL_session_key --> 192.168.0.200:21 *** Object HASH Details ... (SSL_Client_Certificate:options - E) SSL_ca_file ==> C:\Users\ftiffany\Documents\ssl\CA.crt SSL_cert_file ==> C:\Users\ftiffany\Documents\ssl\forrest.pem SSL_key_file ==> C:\Users\ftiffany\Documents\ssl\forrest.key SSL_reuse_ctx ==> SSL_use_cert ==> 1 Object Met::FTPSSL Details ... (192.168.0.200:21 - E) Croak ==> (undef) Crypt ==> E FixGetTs ==> 0 FixPutTs ==> 0 Host ==> 192.168.0.200 OverridePASV ==> 192.168.0.200 Pret ==> 0 Timeout ==> 120 _SSL_arguments ==> HASH(0x2c7f330) -- PeerAddr ===> 192.168.0.200 -- PeerPort ===> 21 -- Proto ===> tcp -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt -- SSL_cert_file ===> C:\Users\ftiffany\Documents\ssl\forrest.pem -- SSL_check_crl ===> 0 -- SSL_cipher_list ===> ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA DHE-DSS-AES128-SHA256 DHE-DSS-AES128-SHA DHE-DSS-AES256-SHA256 DHE-DSS-AES256-SHA AES128-SHA256 AES128-SHA AES256-SHA256 AES256-SHA EDH-DSS-DES-CBC3-SHA DES-CBC3-SHA RC4-SHA !EXP !LOW !eNULL !aNULL !DES !MD5 !PSK !SRP -- SSL_key_file ===> C:\Users\ftiffany\Documents\ssl\forrest.key -- SSL_reuse_ctx ===> -- SSL_server ===> 0 -- SSL_session_cache ===> IO::Socket::SSL::Session_Cache=HASH(0x336930) -- 192.168.0.200:21 ----> HASH(0x37a3aa8) -- key ++++> 192.168.0.200:21 -- next ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- session ++++> 55511872 -- _head ----> HASH(0x37a3aa8) -- key ++++> 192.168.0.200:21 -- next ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- session ++++> 55511872 -- _maxsize ----> 4 -- SSL_session_key ===> 192.168.0.200:21 -- SSL_use_cert ===> 1 -- SSL_verify_callback ===> CODE(0x37a2058) -- SSL_verify_mode ===> 1 -- SSL_version ===> TLSv1 _SSL_ctx ==> IO::Socket::SSL::SSL_Context=HASH(0x37a2040) -- context ===> 51426544 -- ocsp_mode ===> 16 -- session_cache ===> IO::Socket::SSL::Session_Cache=HASH(0x336930) -- 192.168.0.200:21 ----> HASH(0x37a3aa8) -- key ++++> 192.168.0.200:21 -- next ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- session ++++> 55511872 -- _head ----> HASH(0x37a3aa8) -- key ++++> 192.168.0.200:21 -- next ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- prev ++++> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- session ++++> 55511872 -- _maxsize ----> 4 -- verify_mode ===> 1 -- verify_name_ref ===> SCALAR(0x310e1a0) [192.168.0.200] _SSL_fileno ==> 3 _SSL_last_err ==> ARRAY(0x37a3af0) [SSL wants a read first, 4] _SSL_object ==> 58541296 _SSL_opened ==> 1 buf_size ==> 10240 data_prot ==> P dcsc_mode ==> 1 debug ==> 1 debug_extra ==> 0 io_sock_nonblocking ==> 0 io_socket_domain ==> 2 io_socket_proto ==> 6 io_socket_timeout ==> 120 io_socket_type ==> 1 last_ftp_msg ==> 234 Proceed with negotiation. myContext ==> HASH(0x360b8e0) -- SSL_ca_file ===> C:\Users\ftiffany\Documents\ssl\CA.crt -- SSL_reuse_ctx ===> IO::Socket::SSL::SSL_Context=HASH(0x37a2040) -- context ----> 51426544 -- ocsp_mode ----> 16 -- session_cache ----> IO::Socket::SSL::Session_Cache=HASH(0x336930) -- 192.168.0.200:21 ++++> HASH(0x37a3aa8) -- key ====> 192.168.0.200:21 -- next ====> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- prev ====> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- session ====> 55511872 -- _head ++++> HASH(0x37a3aa8) -- key ====> 192.168.0.200:21 -- next ====> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- prev ====> HASH(0x37a3aa8) ... Infinite Hash Loop Detected! -- session ====> 55511872 -- _maxsize ++++> 4 -- verify_mode ----> 1 -- verify_name_ref ----> SCALAR(0x310e1a0) [192.168.0.200] -- SSL_session_key ===> 192.168.0.200:21 mySocketOpts ==> HASH(0x360acb0) -- PeerAddr ===> 192.168.0.200 -- PeerPort ===> 21 -- Proto ===> tcp -- Timeout ===> 120 trace ==> 0 type ==> A >>> USER +++++++ <<< 331 Please specify the password. >>> PASS ******* <<< 230 Login successful. >>> HELP <<< 214-The following commands are recognized. <<< ABOR ACCT ALLO APPE CDUP CWD DELE EPRT EPSV FEAT HELP LIST MDTM MKD <<< MODE NLST NOOP OPTS PASS PASV PORT PWD QUIT REIN REST RETR RMD RNFR <<< RNTO SITE SIZE SMNT STAT STOR STOU STRU SYST TYPE USER XCUP XCWD XMKD <<< XPWD XRMD <<< 214 Help OK. >>> FEAT <<< 211-Features: <<< AUTH TLS <<< EPRT <<< EPSV <<< MDTM <<< PASV <<< PBSZ <<< PROT <<< REST STREAM <<< SIZE <<< TVFS <<< UTF8 <<< 211 End <<+ 214 The HELP command is supported. >>> PBSZ 0 <<< 200 PBSZ set to 0. >>> PROT P <<< 200 PROT now Private. >>> PASV <<< 227 Entering Passive Mode (192,168,0,200,92,93). --- Overriding PASV IP Address 192.168.0.200 with 192.168.0.200 --- Host (192.168.0.200) Port (23645) >>> NLST <<< 150 Here comes the directory listing. DEBUG: .../IO/Socket/SSL.pm:1376: start handshake DEBUG: .../IO/Socket/SSL.pm:573: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:609: not using SNI because hostname is unknown DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=50042672 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=59392416 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=59392240 DEBUG: .../IO/Socket/SSL.pm:2490: ok=1 cert=59392064 DEBUG: .../IO/Socket/SSL.pm:676: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:731: ssl handshake done <<< 522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page >>> QUIT <<< 221 Goodbye. DEBUG: .../IO/Socket/SSL.pm:2667: free ctx 51426544 open=51426544 DEBUG: .../IO/Socket/SSL.pm:2672: free ctx 51426544 callback DEBUG: .../IO/Socket/SSL.pm:2679: OK free ctx 51426544
RT-Send-CC: forrestt [...] usa.net
Drat, I was really hoping that I didn't need to get the IP Address before the call to start_SSL. I usually won't have it until after the call to start_SSL. I'll have to drill down the socket object to see if I can get the IP Address from it when I'm passed a server's name instead of an IP Address. (I have the port, that's a given.) From the error message, it's not recognizing the SSL_sesion_key for the data channel as going with the command channel. See the myContext settings in the log. I use everything in that Hash to create the data channel with. So the SSL_session_key is already set to <IP Address>:<port> for the data channel! So I was already doing what you suggested, except that I also set it on the command channel as well. Which didn't seem to harm the command channel at all. So I'm thinking the SSL_session_key must be set before the call to start_SSL instead of after it. I'm betting whatever is in SSL_session_key is sent to your FTPS server during the handshake establishing the connection for the command channel. That if it's not there, your FTPS server assumes there is no session key to reuse. So the server doesn't recognize the key passed with the data channel as a valid session key. And if that's the case, that explains why the original beta worked for you & this one didn't. That using <IP Address>:<port> was more a suggestion than a requirement. I'm going to get you another beta to try out soon. Also I'd like you to modify your test program to call nlst() 6 times. That's bigger than the cache will be in my next beta. I just want to rule out that setting the cache size to 4 isn't too small for when you are requesting a lot of data from the FTPS server. By the way, I understand your OverridePASV explanation. And as long as you don't attempt to talk to a server using Load Balancing it should work. Using it will break things for a load balancing server since each data request will return a different IP Address. Hopefully hitting misconfigured FTPS servers will be fairly rare. But a test case I use is to login in without OverridePASV & try nlst(). If it fails, then create a new connection using OverridePASV. If it works great, if not there's some other issue involved. This way you get the best of both worlds. But I understand if you don't want the overhead of multiple tries. Curtis On Fri Jun 05 15:31:58 2015, forrestt@usa.net wrote: Show quoted text
> > Here is the log. As you can see from the log, that didn't work. > > I guess I'm not being clear. You shouldn't need to set a key for the > command > channel. Here are the steps that I think need to be done: > > 1. Create command channel connection with a cache object > 2. Store IP address > 3. Store Command Port > 4. Create data channel connection using "IP:Command Port" for > SSLcache key > > The reason I'm using OverridePASV is because the real script I wrote > (the > sample from 28 May, test.pl, is a snippet of it with hard-coded > values) > connects to servers from thousands of different companies with new > ones added > all of the time. I don't want to have to have another parameter that > the > operations staff needs to worry about to determine if PASV needs to be > overridden, so I simply set OverridePASV for the new connection. This > seemed > like the more likely scenario between it and a FTPS server behind a > load-balancer for this particular scenario. > > If it turns out that this isn't the right decision, then I'll modify > my code > to have that option (although, IMHO it would be better to remove that > option > in FTPSSL and simply ignore the returned IP value if it is a non- > routeable IP > and use the origin IP under that case. > > Forrest
RT-Send-CC: forrestt [...] usa.net
Hi Forrest, Here's the beta that should work. Turns out I don't have access to the IP Address before the call to start_SSL() if passed a host name instead of an IP Address. So I'm not going to jump through hoops to try to convert it to one if this beta works. Especially if the (IP Address):(port} for the key seems to be more a suggestion than a requirement. The SSL_session_key it will use is "Net-FTPSSL-(version)-(pid):(port)" Which will result in a fairly unique key, though I also think isn't a requirement. I just need a few things checked out against your server to say this is it. So could you please run your test program against this new beta again? Any feedback would be appreciated as well. Things to test out: 1) Adding the port to the key isn't a problem 2) The key isn't too long for your server. 3) Run the nlst() command at least 6 times. (makes sure we don't attempt to expand our session cache.) Curtis On Fri Jun 05 22:33:50 2015, CLEACH wrote: Show quoted text
> Drat, I was really hoping that I didn't need to get the IP Address > before the call to start_SSL. I usually won't have it until after the > call to start_SSL. I'll have to drill down the socket object to see > if I can get the IP Address from it when I'm passed a server's name > instead of an IP Address. (I have the port, that's a given.) > > From the error message, it's not recognizing the SSL_sesion_key for > the data channel as going with the command channel. See the myContext > settings in the log. I use everything in that Hash to create the data > channel with. So the SSL_session_key is already set to <IP
> Address>:<port> for the data channel! So I was already doing what you
> suggested, except that I also set it on the command channel as well. > Which didn't seem to harm the command channel at all. > > So I'm thinking the SSL_session_key must be set before the call to > start_SSL instead of after it. I'm betting whatever is in > SSL_session_key is sent to your FTPS server during the handshake > establishing the connection for the command channel. That if it's not > there, your FTPS server assumes there is no session key to reuse. So > the server doesn't recognize the key passed with the data channel as a > valid session key. > > And if that's the case, that explains why the original beta worked for > you & this one didn't. That using <IP Address>:<port> was more a > suggestion than a requirement. > > I'm going to get you another beta to try out soon. Also I'd like you > to modify your test program to call nlst() 6 times. That's bigger > than the cache will be in my next beta. I just want to rule out that > setting the cache size to 4 isn't too small for when you are > requesting a lot of data from the FTPS server. > > By the way, I understand your OverridePASV explanation. And as long > as you don't attempt to talk to a server using Load Balancing it > should work. Using it will break things for a load balancing server > since each data request will return a different IP Address. Hopefully > hitting misconfigured FTPS servers will be fairly rare. > > But a test case I use is to login in without OverridePASV & try > nlst(). If it fails, then create a new connection using OverridePASV. > If it works great, if not there's some other issue involved. This way > you get the best of both worlds. But I understand if you don't want > the overhead of multiple tries. > > Curtis > > > On Fri Jun 05 15:31:58 2015, forrestt@usa.net wrote:
> > > > Here is the log. As you can see from the log, that didn't work. > > > > I guess I'm not being clear. You shouldn't need to set a key for the > > command > > channel. Here are the steps that I think need to be done: > > > > 1. Create command channel connection with a cache object > > 2. Store IP address > > 3. Store Command Port > > 4. Create data channel connection using "IP:Command Port" for > > SSLcache key > > > > The reason I'm using OverridePASV is because the real script I wrote > > (the > > sample from 28 May, test.pl, is a snippet of it with hard-coded > > values) > > connects to servers from thousands of different companies with new > > ones added > > all of the time. I don't want to have to have another parameter that > > the > > operations staff needs to worry about to determine if PASV needs to > > be > > overridden, so I simply set OverridePASV for the new connection. > > This > > seemed > > like the more likely scenario between it and a FTPS server behind a > > load-balancer for this particular scenario. > > > > If it turns out that this isn't the right decision, then I'll modify > > my code > > to have that option (although, IMHO it would be better to remove that > > option > > in FTPSSL and simply ignore the returned IP value if it is a non- > > routeable IP > > and use the origin IP under that case. > > > > Forrest
Subject: FTPSSL.pm

Message body is not shown because it is too large.

RT-Send-CC: forrestt [...] usa.net
Hi Forrest, I never heard back from you about the last beta. So I'm assuming all was OK. Attached is my last beta before I upload it to CPAN next week in case you missed my email. The only difference between this beta & my planned release is to comment out a lot of debug statements. If I don't hear back from you by then, I'm going to assume all is OK and close these tickets. This beta now uses option "ReuseSession=>1" to turn things on. It's turned off by default. It will be the same way in the final release. Curtis On Mon Jun 08 17:41:55 2015, CLEACH wrote: Show quoted text
> Hi Forrest, > > Here's the beta that should work. Turns out I don't have access to > the IP Address before the call to start_SSL() if passed a host name > instead of an IP Address. So I'm not going to jump through hoops to > try to convert it to one if this beta works. Especially if the (IP > Address):(port} for the key seems to be more a suggestion than a > requirement. > > The SSL_session_key it will use is "Net-FTPSSL-(version)-(pid):(port)" > Which will result in a fairly unique key, though I also think isn't a > requirement. > > I just need a few things checked out against your server to say this > is it. So could you please run your test program against this new > beta again? Any feedback would be appreciated as well. > > Things to test out: > 1) Adding the port to the key isn't a problem > 2) The key isn't too long for your server. > 3) Run the nlst() command at least 6 times. (makes sure we don't > attempt to expand our session cache.) > > Curtis > > > On Fri Jun 05 22:33:50 2015, CLEACH wrote:
> > Drat, I was really hoping that I didn't need to get the IP Address > > before the call to start_SSL. I usually won't have it until after > > the > > call to start_SSL. I'll have to drill down the socket object to see > > if I can get the IP Address from it when I'm passed a server's name > > instead of an IP Address. (I have the port, that's a given.) > > > > From the error message, it's not recognizing the SSL_sesion_key for > > the data channel as going with the command channel. See the > > myContext > > settings in the log. I use everything in that Hash to create the > > data > > channel with. So the SSL_session_key is already set to <IP
> > Address> :<port> for the data channel! So I was already doing what > > Address> you
> > suggested, except that I also set it on the command channel as well. > > Which didn't seem to harm the command channel at all. > > > > So I'm thinking the SSL_session_key must be set before the call to > > start_SSL instead of after it. I'm betting whatever is in > > SSL_session_key is sent to your FTPS server during the handshake > > establishing the connection for the command channel. That if it's > > not > > there, your FTPS server assumes there is no session key to reuse. So > > the server doesn't recognize the key passed with the data channel as > > a > > valid session key. > > > > And if that's the case, that explains why the original beta worked > > for > > you & this one didn't. That using <IP Address>:<port> was more a > > suggestion than a requirement. > > > > I'm going to get you another beta to try out soon. Also I'd like you > > to modify your test program to call nlst() 6 times. That's bigger > > than the cache will be in my next beta. I just want to rule out that > > setting the cache size to 4 isn't too small for when you are > > requesting a lot of data from the FTPS server. > > > > By the way, I understand your OverridePASV explanation. And as long > > as you don't attempt to talk to a server using Load Balancing it > > should work. Using it will break things for a load balancing server > > since each data request will return a different IP Address. > > Hopefully > > hitting misconfigured FTPS servers will be fairly rare. > > > > But a test case I use is to login in without OverridePASV & try > > nlst(). If it fails, then create a new connection using > > OverridePASV. > > If it works great, if not there's some other issue involved. This > > way > > you get the best of both worlds. But I understand if you don't want > > the overhead of multiple tries. > > > > Curtis > > > > > > On Fri Jun 05 15:31:58 2015, forrestt@usa.net wrote:
> > > > > > Here is the log. As you can see from the log, that didn't work. > > > > > > I guess I'm not being clear. You shouldn't need to set a key for > > > the > > > command > > > channel. Here are the steps that I think need to be done: > > > > > > 1. Create command channel connection with a cache object > > > 2. Store IP address > > > 3. Store Command Port > > > 4. Create data channel connection using "IP:Command Port" for > > > SSLcache key > > > > > > The reason I'm using OverridePASV is because the real script I > > > wrote > > > (the > > > sample from 28 May, test.pl, is a snippet of it with hard-coded > > > values) > > > connects to servers from thousands of different companies with new > > > ones added > > > all of the time. I don't want to have to have another parameter > > > that > > > the > > > operations staff needs to worry about to determine if PASV needs to > > > be > > > overridden, so I simply set OverridePASV for the new connection. > > > This > > > seemed > > > like the more likely scenario between it and a FTPS server behind a > > > load-balancer for this particular scenario. > > > > > > If it turns out that this isn't the right decision, then I'll > > > modify > > > my code > > > to have that option (although, IMHO it would be better to remove > > > that > > > option > > > in FTPSSL and simply ignore the returned IP value if it is a non- > > > routeable IP > > > and use the origin IP under that case. > > > > > > Forrest
Subject: FTPSSL.pm

Message body is not shown because it is too large.

RT-Send-CC: forrestt [...] usa.net
Hi Forrest, This is to let you know that the last beta I sent to you had a bug in it. So if you are still interested in my fix, download v0.29 when it becomes available. I had missed deleting a few lines of code from the 1st broken beta. Once this release is available on CPAN, I'll be closing this ticket. If it's still causing you issues, let me know via a new ticket & I'll be glad to continue working on this until you are happy with the solution. Curtis On Thu Jun 25 14:04:51 2015, CLEACH wrote: Show quoted text
> Hi Forrest, > > I never heard back from you about the last beta. So I'm assuming all > was OK. Attached is my last beta before I upload it to CPAN next week > in case you missed my email. The only difference between this beta & > my planned release is to comment out a lot of debug statements. > > If I don't hear back from you by then, I'm going to assume all is OK > and close these tickets. > > This beta now uses option "ReuseSession=>1" to turn things on. It's > turned off by default. It will be the same way in the final release. > > Curtis > > On Mon Jun 08 17:41:55 2015, CLEACH wrote:
> > Hi Forrest, > > > > Here's the beta that should work. Turns out I don't have access to > > the IP Address before the call to start_SSL() if passed a host name > > instead of an IP Address. So I'm not going to jump through hoops to > > try to convert it to one if this beta works. Especially if the (IP > > Address):(port} for the key seems to be more a suggestion than a > > requirement. > > > > The SSL_session_key it will use is "Net-FTPSSL-(version)- > > (pid):(port)" > > Which will result in a fairly unique key, though I also think isn't a > > requirement. > > > > I just need a few things checked out against your server to say this > > is it. So could you please run your test program against this new > > beta again? Any feedback would be appreciated as well. > > > > Things to test out: > > 1) Adding the port to the key isn't a problem > > 2) The key isn't too long for your server. > > 3) Run the nlst() command at least 6 times. (makes sure we don't > > attempt to expand our session cache.) > > > > Curtis > > > > > > On Fri Jun 05 22:33:50 2015, CLEACH wrote:
> > > Drat, I was really hoping that I didn't need to get the IP Address > > > before the call to start_SSL. I usually won't have it until after > > > the > > > call to start_SSL. I'll have to drill down the socket object to > > > see > > > if I can get the IP Address from it when I'm passed a server's name > > > instead of an IP Address. (I have the port, that's a given.) > > > > > > From the error message, it's not recognizing the SSL_sesion_key for > > > the data channel as going with the command channel. See the > > > myContext > > > settings in the log. I use everything in that Hash to create the > > > data > > > channel with. So the SSL_session_key is already set to <IP
> > > Address> :<port> for the data channel! So I was already doing what > > > Address> you
> > > suggested, except that I also set it on the command channel as > > > well. > > > Which didn't seem to harm the command channel at all. > > > > > > So I'm thinking the SSL_session_key must be set before the call to > > > start_SSL instead of after it. I'm betting whatever is in > > > SSL_session_key is sent to your FTPS server during the handshake > > > establishing the connection for the command channel. That if it's > > > not > > > there, your FTPS server assumes there is no session key to reuse. > > > So > > > the server doesn't recognize the key passed with the data channel > > > as > > > a > > > valid session key. > > > > > > And if that's the case, that explains why the original beta worked > > > for > > > you & this one didn't. That using <IP Address>:<port> was more a > > > suggestion than a requirement. > > > > > > I'm going to get you another beta to try out soon. Also I'd like > > > you > > > to modify your test program to call nlst() 6 times. That's bigger > > > than the cache will be in my next beta. I just want to rule out > > > that > > > setting the cache size to 4 isn't too small for when you are > > > requesting a lot of data from the FTPS server. > > > > > > By the way, I understand your OverridePASV explanation. And as > > > long > > > as you don't attempt to talk to a server using Load Balancing it > > > should work. Using it will break things for a load balancing > > > server > > > since each data request will return a different IP Address. > > > Hopefully > > > hitting misconfigured FTPS servers will be fairly rare. > > > > > > But a test case I use is to login in without OverridePASV & try > > > nlst(). If it fails, then create a new connection using > > > OverridePASV. > > > If it works great, if not there's some other issue involved. This > > > way > > > you get the best of both worlds. But I understand if you don't > > > want > > > the overhead of multiple tries. > > > > > > Curtis > > > > > > > > > On Fri Jun 05 15:31:58 2015, forrestt@usa.net wrote:
> > > > > > > > Here is the log. As you can see from the log, that didn't work. > > > > > > > > I guess I'm not being clear. You shouldn't need to set a key for > > > > the > > > > command > > > > channel. Here are the steps that I think need to be done: > > > > > > > > 1. Create command channel connection with a cache object > > > > 2. Store IP address > > > > 3. Store Command Port > > > > 4. Create data channel connection using "IP:Command Port" for > > > > SSLcache key > > > > > > > > The reason I'm using OverridePASV is because the real script I > > > > wrote > > > > (the > > > > sample from 28 May, test.pl, is a snippet of it with hard-coded > > > > values) > > > > connects to servers from thousands of different companies with > > > > new > > > > ones added > > > > all of the time. I don't want to have to have another parameter > > > > that > > > > the > > > > operations staff needs to worry about to determine if PASV needs > > > > to > > > > be > > > > overridden, so I simply set OverridePASV for the new connection. > > > > This > > > > seemed > > > > like the more likely scenario between it and a FTPS server behind > > > > a > > > > load-balancer for this particular scenario. > > > > > > > > If it turns out that this isn't the right decision, then I'll > > > > modify > > > > my code > > > > to have that option (although, IMHO it would be better to remove > > > > that > > > > option > > > > in FTPSSL and simply ignore the returned IP value if it is a non- > > > > routeable IP > > > > and use the origin IP under that case. > > > > > > > > Forrest