[ 
https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029790#comment-13029790
 ] 

Leif John Korshavn commented on NET-354:
----------------------------------------

Ok, so I have reached the same conclusion as Erick: The EFT Server has a 
problem with the close_notify alert that terminates the TLS session.

According to RFC 2246 section 7.2.1 
(http://www.rfc-editor.org/in-notes/rfc2246.txt) this alert is mandatory, 
especially when data is supposed to be exchanged after TLS termination, which 
of course is the whole reason for using CCC.

Hence, skipping the close operation on SSLSocket is not ok; this was the reason 
for me to add the close in the first place, as I had problems with FTPS to IBM 
Mainframe. Also backed up by this bug report 
http://www-01.ibm.com/support/docview.wss?uid=isg1PK77240

I will submit this as a bug to GlobalScape with a reference to this Jira issue.


> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
>                 Key: NET-354
>                 URL: https://issues.apache.org/jira/browse/NET-354
>             Project: Commons Net
>          Issue Type: Bug
>          Components: FTP
>    Affects Versions: 2.2
>         Environment: Applies to all environments
>            Reporter: Leif John Korshavn
>             Fix For: 3.0
>
>         Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command 
> Channel). Proper behaviour is to close SSLSocket, but keep underlying 
> connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on 
> line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting 
> _socket = _plainsocket on line 493:
>    _socket.close();
>    _socket = _plainsocket;
>    ...
> And finally, it is wrong to set socket factory to null on line 500 of the 
> same method; this is set properly in exexPROT and should not be reset on CCC.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to