using Rebex.Net;

Color schemes is one of the features of our terminal emulator control (part of Rebex SSH Shell and Rebex Telnet) that was added few months ago after one of our users requested it. What is it for? If your application communicates with a monochrome terminal, you can define a custom color scheme to assign some colors to different visual styles to make them more readable. Doing this for a colors-capable terminal application usually doesn’t make much sense (although it is possible as well), but for a monochrome application, it can be a nice visual enhancement.

Check out the results below – a monochrome “man” command output is on the left and the output of the same command using a custom color scheme is on the right:

Defining a color scheme is very simple:

C#:

console.Options.ColorScheme = ColorScheme.Custom;
console.Options.SetColorIndex(SchemeColorName.Background, 0);
console.Options.SetColorIndex(SchemeColorName.Foreground, 7); //= normal text
console.Options.SetColorIndex(SchemeColorName.Bold, 11); //= highlighted text
console.Options.SetColorIndex(SchemeColorName.SingleUnderline, 9);
console.Options.SetColorIndex(SchemeColorName.DoubleUnderline, 9);

console.Options.ColorScheme = ColorScheme.Custom
console.Options.SetColorIndex(SchemeColorName.Background, 0)
console.Options.SetColorIndex(SchemeColorName.Foreground, 7) ' = normal text
console.Options.SetColorIndex(SchemeColorName.Bold, 11) ' = highlighted
console.Options.SetColorIndex(SchemeColorName.SingleUnderline, 9)
console.Options.SetColorIndex(SchemeColorName.DoubleUnderline, 9)

Quick & dirty (yet a bit naive) directory download code

To download all files in a specified remote folder seems to be a trivial task at first. Calling Ftp.GetList(), iterating through the returned collection and caling Ftp.GetFile() on each item looks like a no brainer. It would work in simple cases. However, there are some caveats in this approach. Consider the following situations:

• Remote directory has both files and folder with other files. Should we download the content of subdirectories too?
• What if some of the remote files already exist on the local computer? Should they be overwritten? Skipped? Should we overwrite older files only?
• What if the local file is not writable? Should the whole transfer fail? Should we skip the file and continue to the next?
• How to handle files on a remote disk which are unreadable because we don’t have sufficient access rights?
• How are the symlinks, hard links and junction points handled? Links can easily be used to create an infinite recursive directory tree structure. Consider folder A with subfolder B which in fact is not the real folder but the *nix hard link pointing back to folder A. The naive approach will end in an application which never ends (at least if nobody manage to pull the plug).

Download the directory – resolve the conflicts automatically

public static void DownloadFolderSimple()
{
    using (Ftp client = new Ftp())
    {
        // connect and login to the FTP site
        client.Connect("mirror.aarnet.edu.au");
        client.Login("anonymous", "my@password");

        // download all files
        client.GetFiles(
            "/pub/fedora/linux/development/i386/os/EFI/*",
            "c:\\temp\\download",
            FtpBatchTransferOptions.Recursive,
            FtpActionOnExistingFiles.OverwriteAll
            );

            client.Disconnect();
    }
}

What if the user needs to choose which local files should be overwritten and which not? What if we want to skip files with certain type of problem? Let’s check another scenario and give this power to the hands of the user.

Download the directory – let the user resolve the conflicts

public static void DownloadFolderWithUserInteraction()
{
    using (Ftp client = new Ftp())
    {
        // connect and login to the FTP site
        client.Connect("mirror.aarnet.edu.au");
        client.Login("anonymous", "my@password");

        // subscribe to the event which occurs when transfer conflict 
        // or problem occures
        client.BatchTransferProblemDetected += 
            new FtpBatchTransferProblemDetectedEventHandler
                (client_BatchTransferProblemDetected);

        // download all files
        client.GetFiles(
            "/pub/fedora/linux/development/i386/os/EFI/*",
            "c:\\temp\\download",
            FtpBatchTransferOptions.Recursive
        );

        client.Disconnect();
    }
}

 

static void client_BatchTransferProblemDetected(
    object sender, 
    FtpBatchTransferProblemDetectedEventArgs e)
{
    // Problem type can be found in e.ProblemType
    // 
    // Actions usable for solving the specific problem
    // can be retrieved by checking flags in e.PossibleActions or 
    // by calling e.IsActionPossible method.
    // 
    // e.Action = MyTransferrProblemDetecttedDialog.ShowModal(e);
    //
    // See http://www.rebex.net/ftp.net/sample-batch-transfer.aspx 
    // for sample implementation.
}

To see this approach implemented in a fully functional application download the component and check the FTP Batch Transfer Sample. Both C# and VB.NET code available.

Faster uploads and downloads in SFTP

We are now using a new approach in file download and upload methods that take advantage of the SFTP protocol's ability to queue multiple commands. By keeping the server's command queue full all the time, a better transfer speed can be achieved. Also, several other changes that further enhance the transfer speed were included, making the SFTP component faster than ever.

FIPS 140-2 mode in SFTP

• SFTP: Upload and download speed enhanced a lot using the pipelining approach.
• SFTP: Upload and download buffer size changed from 32K to 28K because the original size resulted in two packets being sent.
• SFTP: Added support for transfer compression through a plugged-in library.
• SFTP: UTF-8 encoding is used by default for WS_FTP server.
• SFTP: Fixed a misleading error message that occurs when both password and public key authentication is required by the server but the clients only supply one of the credentials.
• SFTP: Added several workarounds for CoreFTP server's SFTP implementation that suffers from numerous bugs such as missing file attributes or half-working SSH_FXP_REALPATH command.
• SFTP: Fixed a bug in GetFiles and PutFiles method that caused a wrong path to be used when a filename only was specified or when a root path was specified.
• SCP: Compatibility enhancements in Scp object's PutFile method.
• SCP: Added a workaround for Bitvise's SCP that closes the SCP channel too early.
• FTP: Disposing Ftp object from another thread while an operation is in progress no longer causes NullReferenceException and other similar errors to occur in the operation thread.
• FTP: Better URL handling in the Connect method (although it is hostname-only by design, lot of users actually pass URLs to it).
• FTP: Enhanced logging of incoming connection in active mode.
• FTP: Added a workaround for WS_FTP that requires MLST/MLSD arguments to be quoted if they contain spaces.
• FTP: Added FtpException.Transferred property as a replacement for the misspelled FtpException.Transfered property.
• FTP: Fixed a bug in GetRemoteChecksum method that caused it not to work for filenames that contain space characters.
• FTP: Fixed a bug that caused FtpException's BytesTransferred property not to be set for exceptions thrown by asynchronous methods.
• FTP: Fixed a bug in MODE B transfer mode that might cause an improper block length to be received in rare circumstances.
• FTP: Fixed a bug in GetFiles and PutFiles method that caused a wrong path to be used when a filename only was specified or when a root path was specified.
• MIME: Added a workaround for broken Date headers to MailMessage class - when an unparsable Date header is encountered, the date value from the topmost Received header is used instead.
• MIME: Fixed a bug in the TNEF parser that caused an exception to be thrown when parsing rich text bodies that contain zero characters (which are perfectly legal for RTF, unfortunately).
• MIME: MailDateTime class now supports implicit conversion from DateTime.
• MIME: Long file name support for attachments added to TNEF (winmail.dat) parser.
• POP3: GetMessageList no longer fails on duplicate unique IDs because RFC 1939 actually allows them.
• POP3: Disposing Pop3 object from another thread while an operation is in progress no longer causes NullReferenceException and other similar errors to occur in the operation thread.
• POP3: GetMessageList or GetMessageInfo methods enhanced to make them compatible with servers that return the first message line as well when retrieving headers. In previous versions, this might have occasionally lead to parsing errors.
• POP3: Enhanced GetMessageHeaders to always retrieve the headers only - on some servers, it used to retrieve the first line of the message as well.
• IMAP: Fixed a bug in Imap.SelectFolder method that threw ArgumentOutOfRangeExceptions on some servers.
• IMAP: Imap.SelectFolder now accepts an empty folder name because some servers (Zarafa) use it for the root folder.
• IMAP: Added ImapMessageInfo.GetRawHeaders method.
• IMAP: Fixed a bug in Imap.GetMessageHeaders method that caused it to download the whole message.
• IMAP: SelecteFolder, UnselectFolder and Disconnect methods no longer purge messages marked as Deleted in the currently selected folder. New overload of UnselectFolder method was added that makes it possible to purge the messages when needed.
• IMAP: Headers are now fetched using BODY.PEEK[HEADER] instead of RFC822.HEADER to improve IMAP server compatibility.
• IMAP: Added a new ImapOptions.UsePeekForGetMessage option to make it possible to avoid automatically marking downloaded messages as read.
• IMAP: StoreRawMessage method added to make it possible to upload a raw message from a stream without parsing it.
• IMAP: Gmail's XLIST command is used instead of LIST by default and a new property ImapFolder.Purpose was added to make it possible to detect which folder is which regardless their national name.
• IMAP: Added workaround for IMAP servers that return NIL as a folder delimiter (slash is used instead).
• IMAP: Added workaround for servers that return the same folder name twice for unknown reasons.
• IMAP: Invalid IMAP response lines such as "* AVK-VIRUS-CHECK: 1" are now ignored.
• IMAP: Added workaround for broken IMAP servers that use their default charset where modified UTF-7 is required.
• IMAP: Disposing Imap object from another thread while an operation is in progress no longer causes NullReferenceException and other similar errors to occur in the operation thread.
• IMAP: Added ImapMessageIfo.GetRawHeaders method.
• IMAP: Added MimeHeader.DecodeMimeHeader method.
• IMAP: Added workaround for Exchange 2007's IMAP server that is unable to return the proper structure of multipart/signed messages.
• SMTP: Added support for RFC 1870 - message size declaration.
• SMTP: Added SmtpConfiguration class that makes it possible to read SMTP settings from application configuration file's /configuration/system.net/mailSettings/smtp node.
• SMTP: Fixed a bug that caused an exception when sending a message with embedded message entity using an 8bit content transfer encoding through a server that doesn't support 8bit MIME.
• SMTP: Disposing Smtp object from another thread while an operation is in progress no longer causes NullReferenceException and other similar errors to occur in the operation thread.
• Terminal: Poll method added into IShellChannel.
• Terminal: Fixed a bug that caused the Enter key not to be echoed when local echo is on.
  
• TLS/SSL: Exception thrown by the certificate verifier because of certificate hostname mismatch is more descriptive.
• TLS/SSL: Added a workaround for vsftpd that occasionally leaks unencrypted error messages while TLS/SSL is in use, which causes an error when the client tries to decode them as proper TLS/SSL messages.
• TLS/SSL: Fixed a bug that could cause a deadlock when closing a socket from one thread that is currently sending data using another thread.
• TLS/SSL: Fixed possible NullReferenceException in TlsSocket class.
• TLS/SSL: BeginSend and BeginReceive methods work again.
• SSH Core: Added FIPS 140-2 compliant mode that is automatically enabled on systems where only compliant algorithms are allowed.
• SSH Core: Added a new exception status - PasswordChangeRequired - that is used when a password change is required before authentication can be successfully completed.
• Security: .PFX/P12 private key file loading support for Windows Mobile 5 and newer

Once every week or two, one of our customers using Rebex FTP/SSL or Rebex Secure Mail components encounters the “Server certificate was rejected by the verifier because…” error when connecting to a server secured using the TLS/SSL protocol. And even though the workings of TLS/SSL - the communication protocol using certificates and public key infrastructure to authenticate servers and clients - are sufficiently explained in our FTP/SSL tutorial and Secure Mail TLS/SSL Tutorial, we often have to provide a quick introduction into public key certificates in order to explain why the error occurred and how to solve it. Publishing this on our blog looks like a proper thing to do.

Public-key cryptography

Public-key cryptography, also known as asymmetric key cryptography, is a method for secret communication between two parties without requiring an initial exchange of secret keys. It can be used to create digital signatures, to encrypt messages using public key encryption, or to compute a shared secret key. The most common public-key cryptography algorithms used to enable secure transmission of information over the Internet ate RSA, DSA and Diffie-Hellman.

Public-key cryptography is known as asymmetric because a key owner has a pair of two cryptographic keys – a public key and a private key. The public key may be freely distributed and published, while the private key must be kept secret and only accessible to the owner. The keys are related mathematically, but the private key cannot be feasibly derived from the public key.

To compute a digital signature of a message, the private key is needed. However, a digital signature can be verified using the public key alone. This makes it possible for the receiver of a message and its signature to verify that message was signed by an entity that has access to the corresponding private key – the claimed sender.

For more information, check out the Wikipedia article on public-key cryptography.

Public key certificate

A certificate is a document that uses a digital signature to bind a public key with an identity (such as a person, an organization or a server). A certificate can be freely distributes (just like the public key) and does not contain any secret information – basically, all it contains is the public key, identity information, validity conditions, additional attributes, information about its signer and a signature. However, for each certificate, there is a private key that corresponds to the certificate’s public key. The private key is not a part of the certificate and must be kept secret by the identity that owns the certificate.

Check out the picture on the right – it shows the contents of Google’s certificate used by https://www.google.com to secure user authentication.

Public key certificates can be used for variety of purposes – the ones our users are most interested in are:

• Secure communication using TLS/SSL protocol, where a server presents its certificate to the client to make it possible for the client to verify that it is really connected to the desired server. Optionally, a client can also present his own certificate to authenticate himself to the server. TLS/SSL is used by HTTPS (HTTP over SSL), a well-known protocol used to secure websites, but many other protocols such as FTP, SMTP, POP3 or IMAP can also utilize it.
• E-mail signature and encryption using S/MIME. This makes it possible to sign e-mail (using sender’s secret private key), enabling others to verify the signature using the signer certificate’s public key. On the other hand, to encrypt e-mail, the recipient certificate’s public key is used – once encrypted, the e-mail can only be decrypted by the recipient (using his corresponding private key). Check out our S/MIME tutorial for more information.

Certification Authorities (CAs) and Public Key Infrastructure (PKI)

The certificate is usually signed using a private key of another identity (known as certification authority) and the actual data being signed is the certificate content - public key, identity, validity conditions, additional attributes and information about the signer. This ensures that the certificate information cannot be forged or tampered with and that the signer (the certification authority) attests that the public key and the identity belong together. Therefore, if one trusts the signer (usually called the certificate issuer), all the certificates it signs (issues) are also trusted. This arrangement (using a CA to bind a public key with the respective identities) is called public key infrastructure.

In the X.509 public key infrastructure, the public key of a certificate authority itself is also a part of another certificate that is either signed by yet another certification authority or by the private key that corresponds to the certificate’s public key itself (that is a self-signed certificate, also known as root certificate). This forms a certificate chain of trust – certificate of every identity chains up to a root CA certificate. If a root certificate authority is trusted, all certificates it (or one of its sub-ordinate CAs) issues are also implicitly trusted if all the certificates in their chain are known and valid. The validity check evaluates the chain, making sure each link is signed by the next link, that the signature is valid, that each certificate has can be used for a specific purpose at the specific time and that the last certificate in the chain is a trusted CA certificate.

The Google’s certificate above was issued and signed by Thawte, whose certificate was in turn issued and signed by Verisign using its root CA certificate. The picture on the right shows this certificate chain.

Trusted root certification authorities

Microsoft Windows and most web browsers and SSL libraries come with a list of trusted certification authorities. These are usually commercial certification authorities that have to undergo annual security audits by independent organizations in order to be included in these lists. Rebex TLS/SSL library also uses Windows certificate infrastructure and its certificate stores to validate certificates, which makes it easy to manage using well-known tools. The same infrastructure is utilized by Windows components and many Windows applications that use CryptoAPI to perform security operations. For example, Internet Explorer uses it to validate server certificates when browsing a website protected using HTTPS (HTTP over SSL) protocol. You can even use Internet Explorer to manage the certificate stores (alternatively, use the “Certificates” MMC snap-in).

There are many commercial certification authorities (CAs) that charge for their services. Some of these are authorities that have been added to the aforementioned list by the OS and browser vendors, others are local certification authorities that are trusted by government institutions and are often not trusted by Microsoft Windows and other operating systems out-of-the-box. Some CAs that issue certificates to the public at no cost are also not trusted unless explicitly added to the list of trusted CAs.

To add a certificate of a certification authority into the “Trusted Root Certification Authorities” store of the current user, simply right-click the .cer/.der or .p7b file downloaded from the CA’s web site or start Internet Explorer and follow the instructions in the picture on the right. Only self-signed certificates belong into this store – certificates of non-root CAs have their own store - “Intermediate certification authorities”.

Please note that each Windows user has a separate set of certificate stores. There are also local machine certificate stores that are used by Windows Services and other similar applications. This can be managed using Microsoft Management Console’s “Certificates” snap-in that is a part of every Windows installation.

What to do when a server certificate is not trusted?

A server certificate will usually fall into one of these categories:

• The certificate is signed by a certificate authority that is trusted by Windows certificate infrastructure. This is the desired state.
• The certificate is signed by a certificate authority that is not trusted by Windows certificate infrastructure. For example, this can be a third-party CA or a corporate CA. Add the root CA certificate into “Trusted Root Certification Authorities” store and add each intermediate CA certificate into “Intermediate certification authorities” store to make the server certificate trusted.
• The certificate is self-signed. This is what many FTP and mail servers generate by default. Either replace the default certificate with a certificate issued by a real CA, or make it trusted by Windows certificate infrastructure by adding it into the “Trusted Root Certification Authorities” store, because – in theory and in practice – it is both a server certificate and a CA certificate.

To be continued…

Tomorrow, we will look into the most common certificate problem encountered by our customers – the “Server certificate was rejected by the verifier because…” exception.

With the first release of .NET Framework, Microsoft also introduced the concept of strongly-named assemblies (DLLs) in order to avoid some problems of what was known as DLL Hell. A strong name means that a DLL is uniquely identified not only by filename, but also by its public key token and version number. This makes it impossible to accidentally run an application with a different version of a DLL that is incompatible with the expected version.

In practice, this means that as far as the .NET's class loader is concerned, version 2.0.0.0 and version 2.1.0.0 of an assembly are completely different identities and therefore considered incompatible. The same applies to versions that only differ in a build or revision number. Therefore, for example, applications compiled with Rebex FTP for .NET 2.5.2800.0 or 3.0.3200.0 will refuse to work with 3.0.3300.0. This applies both to Rebex FTP for .NET installed as a shared assembly in Global Assembly Cache (GAC) and as an application-private assembly in the application folder.

The recommended way of dealing with this is to recompile your application with the new version and distribute the next version of your application with a new set of DLLs. However, there might be some scenarios where this is not desirable – and this document describes how to make your existing applications use the new Rebex component version instead of the old one without the need to recompile your code.

Compatibility List

The following table lists all currently available Rebex assemblies, their current version and all the versions it should be backward compatible with:

If you currently use an older version not shown in this table, it means that it is no longer compatible with the current version. In this case, you will have to recompile your code and possibly make several slight changes to it.

The public key token for all Rebex assemblies is “1c4638788972655d”.

Version Policies

Microsoft .NET Framework supports version policies. These policies are stored in XML files and are simply a request to load one version of an assembly instead of another. This is exactly what we need here.

The policy for redirecting from old versions of Rebex FTP for .NET (2.0.0.0 - 3.0.3299.0) to 3.3300.0.0:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">    
    <dependentAssembly>    
        <assemblyIdentity name="Rebex.Net.Ftp" publicKeyToken="1c4638788972655d" />    
        <bindingRedirect oldVersion="2.0.0.0-3.0.3299.0" newVersion="3.0.3300.0" />    
    </dependentAssembly>    
</assemblyBinding>

There are three levels at which version policy can be applied in .NET:

1. Application-Specific Policy

Each application has an optional configuration file that can specify the redirections. The name of the configuration file is the name of the executable + the ".config" extension (eg. WinFormClient.exe.config) for executable files and Web.config for ASP.NET applications.

To enforce binding to a different version than the application was linked with, place the version policy under the <runtime> node of the <configuration> root node:

<configuration>    
    <runtime>    
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">    
            <dependentAssembly>    
                <assemblyIdentity    
                    name="Rebex.Net.Ftp"    
                    publicKeyToken="1c4638788972655d" />    
                <bindingRedirect    
                    oldVersion="1.0.0.0-1.2.2.0"    
                    newVersion="1.3.0.0" />    
            </dependentAssembly>    
        </assemblyBinding>    
    </runtime>    
</configuration>

2. Global Assembly Cache Policy

This only works if the component is installed in Global Assembly Cache. The binding policy can be specified manually using .NET Configuration Management Console (see the screenshot) after adding the assemblies into "Configured Assemblies" group:

One binding policy has to be defined for each Rebex assembly (only for the components you actually use and their references, of course). The drawback of this method is that this will affect all applications using Rebex components, so use with care.

3. Machine-Wide Policy.

Machine-wide policy is stored in machine.config file. Policy statements made in machine.config also affect all applications running on the machine. Edit this file only if you know what you are doing. See .NET Framework documentation for more information. We strongly suggest using one of the other methods instead.

PowerShell - a powerful new scripting language and command shell from Microsoft - has many built-in commands. However, it lacks support for transferring files over FTP, FTP/SSL or SFTP. Luckily, PowerShell is based on .NET and can invoke methods of .NET classes. Let's see how to upload or download files to an FTP or SFTP server from a PowerShell script using either Rebex FTP (/SSL) or Rebex SFTP component.

Step 1 - Loading FTP or SFTP assembly

First, we have to load Rebex assemblies via [Reflection.Assembly]::LoadFrom command. This will load Rebex.Net.Ftp.dll for FTP or FTP/SSL and Rebex.Net.Sftp.dll for SFTP. Other assemblies needed by the two will be loaded as well.

PS C:\> [Reflection.Assembly]::LoadFrom("C:\Program Files\Rebex\FTP for .NET 2.0\bin\release\Rebex.Net.Ftp.dll")

GAC    Version        Location
---    -------        --------
False  v2.0.50727     C:\Program Files\Rebex\FTP for .NET 2.0\bin\release\Rebex.Net.Ftp.dll

Step 2 - Connecting, logging in, uploading, downloading and deleting files

PS C:\> [Reflection.Assembly]::LoadFrom("C:\Program Files\Rebex\FTP for .NET 2.0\bin\release\Rebex.Net.Ftp.dll")

GAC    Version        Location
---    -------        --------
False  v2.0.50727     C:\Program Files\Rebex\FTP for .NET 2.0\bin\release\Rebex.Net.Ftp.dll

PS C:\> $ftp = New-Object Rebex.Net.Ftp
PS C:\> $ftp.Connect("ftp.rebex.net")
220 Gene6 FTP Server v3.7.0 (Build 24) ready...

PS C:\> $ftp.Login("username", "password")
230 User logged in.

PS C:\> $ftp.PutFile("C:\temp\test.txt", "test.txt")
89
PS C:\> $ftp.GetFile("test.txt", "C:\temp\test2.txt")
89
PS C:\> $ftp.DeleteFile("test.txt")
PS C:\> $ftp.Disconnect()
221 Goodbye.


PS C:\> $ftp.Dispose()
PS C:\> Remove-Variable ftp
PS C:\>

That's all!

What about GAC?

And in case you would like to load Rebex assemblies from Global Assembly Cache (GAC) instead of from a path, use Assembly.Load method instead:

PS C:\> [Reflection.assembly]::Load("Rebex.Net.Ftp, Version=2.5.3127.0, Culture=neutral, PublicKeyToken=1c4638788972655d")

GAC    Version        Location
---    -------        --------
True   v2.0.50727     C:\WINDOWS\assembly\GAC\Rebex.Net.Ftp\2.5.3127.0__1c4638788972655d\Rebex.Net.Ftp.dll

Wildcards in SFTP

Even though the SFTP protocol does not support using wildcards to filter its directory listings, this feature was requested so often that we simply had to add it to the GetList method and its variants. How do we do it? It's simple - all the filtering is done at the client side. Of course, this won't help you speed up the listing if you have thousands of files in a directory, but at least you would be able to limit the listing scope easily.

Better support for oversized packets

We have noticed that one popular SFTP server sometimes sends packets that are about 4 times larger than the maximum packet size specified by the protocol draft. And this was too large even for our packet parser. To be able to communicate flawlessly with these servers, we implemented a growable receive buffer that can accomodate even very oversized packets, yet doesn't waste any precious memory space with servers that do behave according to the rules.

Similar problem was discovered in the IMAP protocol - here it occured i the Search method on some servers. A similar workaround was added for these as well.

Complete list of changes:

FTP: Fixed a bug introduced in the last release that caused a bad InvalidOperationException to be thrown when FTP server reported an error during upload.
SFTP: Enhanced packet reader to support oversized SFTP packets.
SFTP: GetList, GetRawList and GetNameList enhanced to support wildcards. However, they are processed at the client side because the SFTP protocol can't do that at the protocol level.
SSH: Fixed a problem in RSA private key reader that caused an error with some keys.
SSH: Enhanced packet reader to support oversized SSH packets.
IMAP: Response-reading code enhanced to handle oversized responses that occured while searching with some servers.
SNTP: Ntp.SynchronizeSystemClock method can now syncrhonize system time even if the current clock value is outside the range supported by NTP.
SNTP: Added experimental support for setting system time on Linux.

The next release of FTP and SFTP components will finally feature directory tree transfers!