Home Forums .NET libraries Xceed SFTP/FTP for .NET SSL Connection Problem

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #20863 |

    Hi,
    I was trying to use some of the samples as well as a couple of the snippets posted here on the forum but I can’t figure out for the life of me how to get the SSL part to work.

    It appears that Authenticate sends PROT before the credentials are actually being sent which causes the server to return 530.

    Has anyone else seen this problem or better yet any idea how to solve it?

    Thanks,
    Paul

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Paul (had 6398 views)

    User (Old forums)
    Member
    Post count: 23064

    The PROT command needs to be sent so the server and the client synchronize there encryption level on the data channel.

    Are you sure your server support SSL/TLS and not SSH? Our component does not support SSH.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 289 views)

    User (Old forums)
    Member
    Post count: 23064

    Hi,
    Yes I’m sure it supports both SSL / TLS as that’s what I use with my regular client. RushFtp for instance sends PROT after the user has logged in.

    Any suggestions?

    Thanks

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Paul (had 231 views)

    User (Old forums)
    Member
    Post count: 23064

    Can you post the log of the communication with the server? Use the TraceWriter property.

    e.g.:

    FtpClient.TraceWriter = new StreamWriter( @”D:\ftp.log”, true );

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 381 views)

    User (Old forums)
    Member
    Post count: 23064

    Sure, here is the trace:

    <b>Connected to xxx.xxx.xxx.xxx:5001 on 4/16/2007 @ 2:45:47 AM
    Connected!
    > AUTH TLS
    < 234 AUTH TLS successful
    > PBSZ 0
    The server certificate is invalid: UntrustedRoot
    CERTIFICATE:
    Format: X509
    Name: ftpd
    Issuing CA: ftpd
    Key Algorithm: 2.4.730.143445.3.3.6
    Serial Number: 3344254A
    Key Alogrithm Parameters: 0500
    Public Key: [key]
    < 200 Command okay
    > PROT E
    < 530 Not logged in.</b>

    And here is the log from rushftp:
    <b>
    (12:51:10) [1] Connecting xxx.xxx.xxx.xxx:5001
    (12:51:11) [1] AUTH TLS
    (12:51:11) [1] 234 AUTH TLS successful
    (12:51:12) [1] Encryption algorithm: TLSv1 [encryption]
    (12:51:12) [1] PBSZ 0
    (12:51:12) [1] 200 Command okay
    (12:51:12) [1] USER username
    (12:51:14) [1] 331 Password required for username.
    (12:51:14) [1] PASS (hidden)
    (12:51:14) [1] 230 username logged in successfully.
    (12:51:14) [1] SYST
    (12:51:14) [1] 215 UNIX system type.
    (12:51:14) [1] PROT P
    </b>

    As you can see the only difference between the two is that one sends PROT before the credentials which makes the server throw the 530 error.

    Paul

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Paul (had 373 views)

    User (Old forums)
    Member
    Post count: 23064

    With rushftp, you set the data channel protection level to Private (PROT P), whereas with our component, you set it to Confidential (PROT E). Try setting it to Private with our component, and it should resolve the issue.

    To set it to private, you need to use the Authenticate(AuthenticationMethod,VerificationFlags,Certificate,DataChannelProtection) method, and set the last parameter to DataChannelProtection.Private.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 325 views)

    User (Old forums)
    Member
    Post count: 23064

    I changed the DataChannelProtection to Private and the same thing happens: PROT is being sent before the credentials.

    Any other suggestions? (What ftp daemons did you guys tested the library on?)

    Paul

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Paul (had 307 views)

    User (Old forums)
    Member
    Post count: 23064

    One server on which it works is Serv-U.

    This is the normal sequence of command. Here is an excerpt taken from the following <a href=”ftp://ftp.rfc-editor.org/in-notes/rfc2228.txt”>RFC</a&gt;, called “FTP Security Extensions” :

    “Once the client and server have negotiated with the PBSZ command an acceptable buffer size for encapsulating protected data over the data channel, the security mechanism may also be used to protect data channel transfers.”

    This refers to the PROT command. Therefore, the server should support this sequence of commands.

    I noted that the certificate is stated as invalid. Do you handle the CertificateReceived event, and do you accept the certificate in it?

    e.g.:

    <code>
    private void OnCertificateReceived( object sender, CertificateReceivedEventArgs e )
    {
    // The Status argument property tells you if the server certificate was accepted
    // based on the VerificationFlags you provided.
    if( e.Status != VerificationStatus.ValidCertificate )
    {
    Console.WriteLine( “The server certificate is invalid: {0}”, e.Status.ToString() );
    Console.WriteLine( e.ServerCertificate.ToString() );

    // You have three choices here.
    // 1) Refuse the certificate by setting e.Action to VerificationAction.Reject,
    // thus making the authentication fail. This is e.Action’s default value
    // when the server certificate isn’t valid
    // 2) Set e.Flags to less restrictive criteria and ask the library to
    // validate the certificate again by setting e.Action to
    // VerificationAction.VerifyAgain.
    // 3) Force the library to accept this certificate by setting e.Action to
    // VerificationAction.Accept.

    // We’ll do #1 or #3, depending on the user’s answer.
    Console.WriteLine( “Do you want to accept this certificate anyway? [Y/N]” );
    int answer = Console.Read();

    if( ( answer == ‘y’ ) || ( answer == ‘Y’ ) )
    {
    e.Action = VerificationAction.Accept;
    }
    }
    else
    {
    Console.WriteLine( “Valid certificate received from server.” );
    // e.Action’s default value is VerificationAction.Accept
    }
    }
    </code>

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by André (had 356 views)

    User (Old forums)
    Member
    Post count: 23064

    Yes I’m accepting the certificate regardless of whether is valid or not. I can’t really see anywhere in that RFC where it specifies the exact order of the commands.

    In any case thanks for your help, we found another API that appears to work so we’ll give that a go.

    Paul

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Paul (had 7100 views)

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.