Re: Error listing empty directory over SSL (was "MINA teaser")

[Clinton Foster <cf...@us.axway.com>]

Yes, this agrees with what I am seeing. I'm not sure if this is a clean
solution, but adding the following code near the bottom of
FtpDataConnection.getDataSocket() is one way to resolve the problem:

            if (dataSoc instanceof SSLSocket) {
                ((SSLSocket)dataSoc).startHandshake();
            }
        }
        catch(Exception ex) {

I need to read up a bit on SSL sockets in Java to be sure, but it would
appear the handshake is triggered automatically when the first byte of data
is written to the socket. The above code forces the handshake to occur
immediately after the connection is completed. Thus, even if the server
closes the connection without writing anything to the socket, the client
does not complain of a handshake error.

On 1/18/07 2:08 AM, "Dave Roberts" <da...@saaconsultants.com> wrote:

> It was 18/01/2007 00:27, when Clinton Foster wrote:
> 
>> However, when the server tries to send
>> anything to the client on the data connection, as soon as the server closes
>> the data connection the client gets an SSL handshaking error.  My theory is
>> that the handshake is not happening immediately when the client makes the
>> data connection to the server, so when the server sends the data the client
>> mistakes it for the initiation of the handshake.
> 
> I've seen this behaviour, but only when the directory being listed
> is empty.  When not using SSL, an empty directory listing will
> result in the data connection being opened, and then closed without
> any information being sent.
> 
> In SSL mode, then connection is closed before the SSL is negotiated
> and any client will report a handshake error.
> 
> The RFC is ambiguous as to what should happen in this situation, and
> although some UNIX FTP servers send a 550 response instead, I
> believe this specifically breaks the RFC.
> 
> Does this tie up with what you are seeing?

Re: Error listing empty directory over SSL (was "MINA teaser")

[Niklas Gustavsson <ni...@protocol7.com>]

Dave Roberts wrote:
> It was 18/01/2007 21:36, when Clinton Foster wrote:
> 
>> Yes, this agrees with what I am seeing. I'm not sure if this is a clean
>> solution, but adding the following code near the bottom of
>> FtpDataConnection.getDataSocket() is one way to resolve the problem:
>>
>>             if (dataSoc instanceof SSLSocket) {
>>                 ((SSLSocket)dataSoc).startHandshake();
>>             }
> 
> Thanks Clinton.  This certainly works for me with other SSL aware
> clients.  I was hoping that the clients would behave better and cope
> with a closing of the connection.  After all, setting up the SSL is
> relatively time consuming and in the case of an empty directory,
> unnecessary.
> 
> However this would appear to be a fix that would work with any
> client and therefore has much appeal.

Thanks guys! Fix has been commited with tests to reproduce in rev 498139.

/niklas

Re: Error listing empty directory over SSL (was "MINA teaser")

[Dave Roberts <da...@saaconsultants.com>]

It was 18/01/2007 21:36, when Clinton Foster wrote:

> Yes, this agrees with what I am seeing. I'm not sure if this is a clean
> solution, but adding the following code near the bottom of
> FtpDataConnection.getDataSocket() is one way to resolve the problem:
> 
>             if (dataSoc instanceof SSLSocket) {
>                 ((SSLSocket)dataSoc).startHandshake();
>             }

Thanks Clinton.  This certainly works for me with other SSL aware
clients.  I was hoping that the clients would behave better and cope
with a closing of the connection.  After all, setting up the SSL is
relatively time consuming and in the case of an empty directory,
unnecessary.

However this would appear to be a fix that would work with any
client and therefore has much appeal.

Re: Error listing empty directory over SSL (was "MINA teaser")

[Niklas Gustavsson <ni...@protocol7.com>]

Clinton Foster wrote:
> Yes, this agrees with what I am seeing. I'm not sure if this is a clean
> solution, but adding the following code near the bottom of
> FtpDataConnection.getDataSocket() is one way to resolve the problem:
> 
>             if (dataSoc instanceof SSLSocket) {
>                 ((SSLSocket)dataSoc).startHandshake();
>             }
>         }
>         catch(Exception ex) {
> 
> I need to read up a bit on SSL sockets in Java to be sure, but it would
> appear the handshake is triggered automatically when the first byte of data
> is written to the socket. The above code forces the handshake to occur
> immediately after the connection is completed. Thus, even if the server
> closes the connection without writing anything to the socket, the client
> does not complain of a handshake error.

The JavaDoc for SSLSocket says you're right:

The initial handshake on this connection can be initiated in one of 
three ways:

     * calling startHandshake which explicitly begins handshakes, or
     * any attempt to read or write application data on this socket 
causes an implicit handshake, or
     * a call to getSession tries to set up a session if there is no 
currently valid session, and an implicit handshake is done.

http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/SSLSocket.html

The above fix looks reasonable, I'll get it in there as soon as I can 
(got some other changes I want to commit first). Thanks for the feedback!

/niklas