Introduction

Welcome!

We are very happy to announce that we have made the decision to offer our commercial lineup of MFC libraries, including Ultimate Toolbox, Ultimate Grid, and Ultimate TCP/IP to the CodeProject.com community free of charge.

These are the full and complete libraries including source code, documentation, samples and examples.

Ultimate Toolbox, Ultimate Grid and Ultimate TCP/IP come with full source code, and are compatible with Microsoft Visual Studio versions 6.0 through 2005.

The Ultimate Toolbox and line of related MFC libraries products have been powering professional MFC applications for more than 10 years. We realize that there is a very large number of users who are still coding new applications in Visual C++ and MFC and who are looking for effective and proven libraries to enhance their applications, as well as those with legacy code to maintain and update.

By releasing these long standing MFC libraries to the CodeProject.com community we hope that the libraries will continue to grow, evolve and provide a library of useful controls to the development community through the auspices of The Code Project and its members.

Includes Servers For The Most Popular Protocols

The Server edition of Ultimate TCP/IP includes the server-side implementations for the following protocols:

Web Server (HTTP protocol).

Finger server.

Fully functional Email and relay server (SMTP, POP3, DNS)

File transfer server (FTP)

Echo server.

*full source for each of the protocols is included

Design Your Own Custom Protocol

Create modified protocols by deriving from our base protocol classes.

Create entirely new protocols by deriving from our client and server framework classes. This is very easy since the product comes with complete source code for all of the included protocols, which you can then use as a guideline.

Our customers have found that source code availability drastically cuts down on time spent debugging .

Maximum Access Control

The framework includes functionality that lets you grant, suspend and/or deny user access based on their IP address or network range.

The server framework also monitors every single command sent from the server.

Allows you to grant, deny and modify client requests based on your own custom protocol logic.

In conjunction with the secure version you can make sure that both the server and the client use a certificate for authentication.

Programmatic And Interactive Certificate Management

Unlike other products the certificate management wizard can be integrated with your own application, without having to run as a separate application.

You can search, view, select, install, and/or delete a certificate programmatically or interactively.

Generating a certificate-signing request (CSR) can be done with a single function call (programmatic mode). You can also do this in interactive mode by integrating the ready-to-use certificate management wizard into your application.

Security Features

Fully Supports PCT, SSL v2.0, SSL v3.0, and TLS v1.0.

The certificate validation process is fully automated, and you can configure this process to: deny access for all errors; allow access regardless of an error (ideal for testing); or build your own authentication logic based on the occurrence of certain errors.

When used in conjunction with the enterprise edition you can ensure that both the server and the client use a certificate for authentication.

Included SSL/TLS Servers

Secure Web Server (HTTPS): can be used by all browsers that support SSL/TLS (e.g. Netscape and Internet Explorer).

Secure Mail server: can be used by all clients that support SSL/TLS (e.g. Outlook Express and MS Outlook).

Secure FTP Server: can be used by all clients that support SSL/TLS (e.g. WS_FTP and Cute FTP).

Secure Echo: can be used as the basis for building a secure custom protocol that takes advantage of the well-known, secure SSL/TLS protocol.

Layout

We've split up the components of the Ultimate TCP-IP into separate source code, samples and documentation files for the initial deployment.

In general, for a code library such as the Ultimate TCP-IP, installation files are a cumbersome nuisance. While they do allow the formality of license agreement acceptance, and are expected of a commercial offering, for our purposes it would be too much trouble to update an entire install in order to accommodate a small update to a core source file or sample, and if the CP community finds this offering useful (and we hope they do) we expect that there will be updates and patches in various forms - for now, we'll keep it simple and see how it evolves.

The samples and library projects all reference relative paths with respect to source and include files, and should compile 'out of the box' if the ZIP files are extracted to a common directory - your installation should look more or less like this:

Support for the products will be community based, and will include participation from core developers of the products, long standing and informed users of the products, and other members of the CodeProject.com community.

It is our intention that you be able to use the libraries in any manner you wish however specific details of licensing rights, limitation of liability, and other details are included both here, and in a license.txt file included with the downloadable packages

The main focus of Ultimate TCP/IP Version 4.2 has been to update the source code for use with Microsoft Visual Studio 2005, while maintaining compatibility with Visual Studio 6.0. This section contains an overview of the various impacts of the version 4.2 revisions:

Unicode builds:

New Visual C++ 8.0 projects now default to Unicode compilation.

Much of the Ultimate TCP/IP code is char based, having its origins in the implementation of several DOD RFCs dealing primarily with transmission protocols using 7 and 8 bit ASCII based command sets and data formats. For this reason updating the code to support compilation under unicode constitutes a special case, in that unlike most Windows libraries it is desirable to maintain the core code as char based while providing a unicode interface where necessary for ease of use within a wide char build.

In some cases, it made sense to rework the classes for full unicode compatibility substituting _TCHAR for char and using the generic text mappings. Other classes (especially those encapsulating ANSI based internet protocols) were modified to provide the user with wide char overloads when used in a unicode build. This was especially important for those classes where a wide char version of a function might be convenient for the user, but the char equivalent will still be called from char based internal code.

Some functions (overrides) that act as notification callbacks concerning events where protocol data is returned will still return ANSI text.

Warnings:

A primary goal of the Ultimate TCP/IP 4.2 release was clean compilation at Warning Level 4 in both VS2005 and VS6.0.

There were several issues to be addressed here. It was found that many areas of the code files evoked warnings at level 3 in VS8 that are either new to VS7/8 or VC6 level 4 warnings re-classified as level 3. Also, there are new warnings dealing with 64 bit portability (on by default in new VS2005 projects).

Level 4 warnings invoked by the STL code that were present in VC6 builds have been addressed.

With regard to 64 bit portability, Ultimate TCP/IP 4.2 is not intended to provide full 64 bit compilation, though some changes were made to suppress these warnings. In some cases functions taking integer parameters to designate buffer sizes have been updated to take size_t, which should help users of the class using values returned from strlen etc. to avoid warnings when calling the UT code. Future releases may address this issue more fully.

Note: Some portions of the code using static functions may give rise to warning C4710 (function not inlined). This warning occurs after the compiler has read the last line of code in the compiland, and can only be discarded on a per-project basis.

Updates to the C Run Time:

With the introduction of VC8, many CRT string handling functions are deprecated in favor of their safe equivalents.

Version 4.2 only partially addresses this issue, preferring to retain (for now) the non-safe string functions. Pragmas are provided to disable this warning in the core Ultimate TCP/IP code on a per file basis - these pragmas should not affect warning settings beyond the scope of each compiland. Future versions of Ultimate TCP/IP should address this issue more fully, as do Ultimate Toolbox and Ultimate Grid.

We have tried to limit the use of pragmas in disabling warnings for the Ultimate TCP/IP code. Beyond the safe string warnings, most pragmas dealing with warnings should be disabling warnings arising from the STL or SDK.

Several POSIX function names were deprecated in favor of their ISO equivalents.

All functions generating warning C4996 related to their POSIX name declarations were changed to use their ISO name declaration. This change is backward compatible to VC6. Some of these functions remain deprecated in favor of their safe counterparts.

Files referencing headers no longer included in VC8 were updated (e.g. iostream vs iostream.h). This is change does not break VC6.0 compatibility.

Changes to the Platform SDK

There have been changes to the Platfom SDK with the release of Visual Studio 2005 and the Platform SDK 2003.

If you are using the Ultimate TCP/IP secure client and server classes with 2005 it is no longer necessary to install a separate version of the Platform SDK to compile the UTSecureLayer.DLL. However, some key headers and lib files required by Visual Studio 6.0 are no longer contained in the revised Platform SDK 2003. VC6.0 users compiling the secure code will need to access a previous version of the Platform SDK. (PSDK from February 2003 recommended)

UTSecureLayer.DLL builds:

With version 4.2, the UTSecureLayer builds have been renamed based on character set and release/debug version.

Where previously code built against the secure DLL had to assume that the build was compatible with the current settings, we've separated it into UTSecureLayer.DLL, UTSecureLayerU.DLL, UTSecureLayerD.DLL, UTSecureLayerUD.DLL based on Unicode / Debug settings. Some project settings may need to be reset to reflect this.

Breaking Changes:

CUT_DataSource and derived classes

In preparing the Ultimate TCP/IP for wide char compilation, most file names and paths were changed to use _TCHAR strings, and this is reflected in the interfaces to the datasouces which take file names.

The interfaces that were specifying buffer or data lengths as unsigned int now take size_t, which may require changes to existing derived classes.

The datasource classes themselves remain primarily char based, as they are mostly used internally by ANSI based protocol classes. In future we may provide wide char or _TCHAR based classes.

The strings returned in the UT_ARTICLEINFO structure will be wide char for _UNICODE builds. This may break code that was attempting to decode strings with calls to CUT_HeaderEncoding methods, which take only char. For this reason, and added convenience, the strings returned in this structure will have been decoded if necessary, and the structure now contains a text representation of the associated character set for the applicable fields. Note that only Author and Subject are routinely encoded in an NNTP header.

CUT_Msg, CUT_HeaderEncoding - decoding functions that previously took a reference to an LPCTSTR to return the charset now take an LPSTR that should be declared/allocated with space to receive the charset.

Miscellaneous Fixes:

CUT_SMTPClient: Was failing to include Reply-To header if set in CUT_Msg when sending.

Share

About the Author

In January 2005, David Cunningham and Chris Maunder created TheUltimateToolbox.com, a new group dedicated to the continued development, support and growth of Dundas Software’s award winning line of MFC, C++ and ActiveX control products.

Ultimate Grid for MFC, Ultimate Toolbox for MFC, and Ultimate TCP/IP have been stalwarts of C++/MFC development for a decade. Thousands of developers have used these products to speed their time to market, improve the quality of their finished products, and enhance the reliability and flexibility of their software.

Is it possible the certificate is not found in the store? Could try spelunking with certmgr.msc, and check the docs on CUT_SecureSocket::SetCertStoreName etc. Might possibly be access rights as well if running the server as a service.

Need to refresh myself on this - just first thoughts.

Have you tried it with the test certificate supplied? Is it the FTP client that's failing, or mail as well?

The certificate is in the store, both FTP client and mail are failing, and I don't think it's a problem of access rights.

I tried my certificates and the one supplied, but I always get the same answer. Everything works fine till I try to connect from the client, then I get "failed to initialize security context". In the FTP client I can read "234 SSL enabled start the negotiation Security handshake failed"

Sorry for the slow response - I'm rusty on this, and don't seem to be finding time to refresh. Also, I'm not running VS2010, though I don't think that's a big issue.

Couple of suggestions though. First, make sure you grab the updates (The Ultimate Toolbox - Updates and User Contributions[^] - there's an updated secure mail client in update 02 that would make a good check against gmail or whatever, just to test that much. I don't think any of the existing updates require recompiling the UTSecureLayer.dll. There's also an important TLS fix outlined a few threads down that needs to be put in an update, but that shouldn't affect negotiation.

As for the test certificate supplied, I think I do recall having to move it to another store when doing some testing with the secure mail server - might be worth a check.

Again, feeling a bit lame on this - will try to find some time in the next few days.

Gmail SSL with TLS sends the message, even if it still tells me "failed to initialize security context";

gmail SSL without TLS doesn't work.

Using mail client with mail server still doesn't work and tell me "failed...". In the server's message list I can see:
"
Client [127.0.0.1] connected
New command:
two weird charachters...
must issue a STARTTLS command first
New command:
New command:
EHLO localhost
250-roby.com localhost [127.0.0.1] 250 STARTTLS
New command:
STARTTLS
"

Using FTP client and server:

The same errors, and the following message in the server:
"
Connected to port 21
Waiting for connections
client [127.0.0.1] has connected
[127.0.0.1] issued command 33 'AUTH TLS-P'
Client [127.0.0.1] has disconnected

Gmail SSL with TLS sends the message, even if it still tells me "failed to initialize security context";

gmail SSL without TLS doesn't work.

Ok - this is normal, I think. GMail with TLS involves a fallback in the negotiation, and a call to CUT_SecureSocket::HandleSecurityError in the UTSecureLayer code - this function displays a message in a debug build, but not in release, so you should be ok.

Gmail with TLS is the recommended port for the UT code at present.

So thanks - this tells us the problem is not some quirk of VS2010 - so testing can concentrate on the mail and FTP setups. To be honest I'm not sure the FTPS client isn't outdated in any case.

You might try testing with the FtpClientS example with a connection to ftp.secureftp-test.com (see http://secureftp-test.com/[^]. I think port 21 is also used for explicit FTPS.

I saw another weird thing that could be related. If I quote the HELP command (but with other commands it's the same) after the "list" I get the following messages:
I quote HELP once and get:
"226 transfer OK"
Twice:
"227 Entering passive mode (64,65,53,234,39,34)"
Another time: here I get the correct answer, that is the list of available commands...

The answers obtained before are related to the socket connection in GetDirInfo (or GetDirInfoPASV if the "firewall" mode is on).

(this really should be available on the dialog - might have been what was stopping things for you).

Worked for the local machine.

Next, opened certmgr.msc and exported the certificate with private key (must be created with the -pe option), and moved that .pfx file over to another machine.

Installed and selected testCert3 in the server example, and all is good - can connect from the other box and tranfer securely, both normal and PASV (firewall).

Note that the server code defaults to CurrentUser when selecting / browsing for certificates - you should be able to change that in the server example with a call to CUT_SecureSocketServer::SetMachineStore() - 0 for Current User, 1 for Local machine.

On the client side, try SetCertStoreName("MY\\.LocalMachine"); (see docs on CertOpenStore in MSDN).

Hope this is helpful, and you're able at least to get the sample client and server running with your certificates. I tested only with the CurrentUser store.

As an aside, if you have implemented the TLS extra data code in the thread below (here[^]), be sure and add some initialization to the ExtraData object - might be just my code (haven't yet implemented all of Brad's items), but something like this is needed after the declaration in CUT_SecureSocket::SocketOnConnected:

ExtraData.cbBuffer = 0;
ExtraData.pvBuffer = NULL;

In other news, yesterday I did some testing with ftp.secureftp-test.com

Non-secure connections are ok.

For secure connections, I first tested the AUTH command we were sending - this server doesn't understand AUTH TLS-P or TLS-C, but does allow AUTH TLS, so made that small change in CUT_FTPClient::SocketOnConnected - we were falling back to AUTH SSL, which seems about equivalent, may depend on server, but AUTH TLS recommended.

In my scenario, think some level of firewall (Windows, modem etc) is not allowing incoming connections from the server for the data channel, and the fact that the encryption is in place may be defeating the firewalls attempts to identify this as an ftp related connection, even with certain app exceptions enabled - could be server side as well.

So, that leaves firewall mode, asking the server for a data port and connecting to that.

If I disable security on the data socket before connecting in the PASV (firewall mode) versions of the data methods, the server will allow the connection to proceed - for example, in CUT_FTPClient::GetDirInfoPASV():

this seems right, as the client should be responsible for initiating the security negotiation in explicit FTPS. It doesn't seem to matter whether the data channel is marked as clear or private (PROT C or PROT P) for this server at least (note our FTP client code doesn't make use of PBSB or PROT commands presently).

All of which leaves us with a secure control channel and a non-secure data channel.

If security is left enabled on the data socket (m_wsData), the default connect and SocketOnConnected from the base classes are called, and this is probably why the security negotiations are failing. What I think would be needed is a specific WSFTPDataConnect fn, and possibly an override for SocketOnConnected in the CUT_WSDataClient class for this to be implemented properly, given the quirks of various servers. I could be missing something here.

Along with that, probably some enhancements to allow for the various AUTH and PROT parameters that might or might not be acceptable for certain servers.

This may be secondary for you if you're planning on using the UT server and client code as described above, but I think some work is needed and/or some enhancements could be made to the existing kit to provide some better support for options and connections of various types. I think the code is a little dated by todays standards.

I just noticed that the rest of my research dissertation was cut off - for the record:

...
In other news, yesterday I did some testing with ftp.secureftp-test.com. Non-secure connections are ok. For secure connections, I first tested the AUTH command we were sending - this server doesn't understand AUTH TLS-P or TLS-C, but does allow AUTH TLS, so made that small change in CUT_FTPClient::SocketOnConnected - we were falling back to AUTH SSL, which seems about equivalent, may depend on server, but AUTH TLS recommended.

In my scenario, think some level of firewall (Windows, modem etc) is not allowing incoming connections from the server for the data channel, and the fact that the encryption is in place may be defeating the firewalls attempts to identify this as an ftp related connection, even with certain app exceptions enabled - could be server side as well.

So, that leaves firewall mode, asking the server for a data port and connecting to that.

If I disable security on the data socket before connecting in the PASV (firewall mode) versions of the data methods, the server will allow the connection to proceed - for example, in CUT_FTPClient::GetDirInfoPASV():

this seems right, as the client should be responsible for initiating the security negotiation in explicit FTPS. It doesn't seem to matter whether the data channel is marked as clear or private (PROT C or PROT P) for this server at least (note our FTP client code doesn't make use of PBSB or PROT commands presently).

All of which leaves us with a secure control channel and a non-secure data channel.

If security is left enabled on the data socket (m_wsData), the default connect and SocketOnConnected from the base classes are called, and this is probably why the security negotiations are failing. What I think would be needed is a specific WSFTPDataConnect fn, and possibly an override for SocketOnConnected in the CUT_WSDataClient class for this to be implemented properly.

Along with that, probably some enhancements to allow for the various AUTH and PROT parameters that might or might not be acceptable for certain servers.

This may be secondary for you if you're planning on using the UT server and client code as described above, but I think some work is needed and/or some enhancements could be made to the existing kit.