Application Security Testing: An Integral Part of DevOps
It's hard to imagine the line of human activity where computers and computer networks are not used. Actually, people can get everything they need without leaving their houses. With the help of the Internet, a man can find a job, work at home, get money to his individual account, order meals and other goods (even from abroad), learn the latest news, study, communicate with friends... And all these things are only everyday tasks. What can we say about large companies and corporations where data exchange among departments, branches and, sections is a permanent activity? Turning information into the subject of a sale (and quite an expensive one) naturally leads to the necessity of high-quality and high-performance protection and safe transfer.
But, what exactly is treated as safe transfer? Someone can be interested in providing only a particular user with access to the information (account number transfer, for example), so it's necessary to drive off unauthorized users. This can be done by transferring encoded data. On the other hand, sometimes it's not so much important to hide data from unauthorized peeping, while it is necessary to be sure that data came from the source that is indicated (e.g. when you order goods in electronic storefront, you need to ensure that this is the storefront and not a hacker's site). Furthermore, it would not be out of place to have the possibility to determine that the message was not modified.
Let's compare eight existing packages:
|PowerTCP SSL Tool||Dart Communications|
|IP*Works SSL Internet Toolkit||/n software Inc.|
|CryptoAPI + SChannel||Microsoft Corporation|
|Chilkat SSL||Chilkat Software|
|OpenSSL||The open-source community|
Secure Level Protocols Implementation
It should be mentioned that only four of the named libraries have their own implementation of SSL. Besides SecureBlackbox, only CryptoAPI/SChannel, StrSecII, and OpenSSL exhibit this characteristic. As a matter of fact, two more packages were based on OpenSSL: Visual SSL and Chilkat SSL, which more or less realize and enhance the features of their basis. PowerTCP and IP*Works chose some other way and took CryptoAPI as their basis (although PowerTCP promises compatibility with common UNIX protocols, this statement is not clear). It's hard to say for sure, what is better and what is worse, but it's obvious that your own (custom) implementation can provide more flexibility and tuning of software. Moreover, in that case, encryption algorithms are also custom, and this allows you to add new ones or cut down use of existing ones when necessary.
There are several known protocols that determine secure data transfer mechanisms between applications (HTTP, FTP, and so forth) and transport level (TCP/IP) protocols; among them are PCT (Private Communication Technology), SSL2, SSL3 (Secure Sockets Layer), and TLS (Transport Layer Security). The first of the named protocols is actually crowded out by others because of its limitations and weak encryption. Support for this protocol by PowerTCP and IP*Works can be probably explained by the possibility to work with it by means of standard SChannel methods. Another protocol, SSL2, is also in disfavor lately because its younger brother SSL3 has a number of advantages such as the possibility to do the "handshake" at any moment (not only at the beginning of the session), use of certificates chains, and stronger cryptography. But, this fact does not prevent most packages (except Chilkat SSL and StrSecII) from supporting both versions of this protocol. In turn, the protocol TLS1 is merely an advanced version of SSL3 and has only small distinctions from it. However, they are enough to make interaction impossible. Thus, more frequently used protocols are SSL3 and TLS1, which are supported by all concerned products.
Because SSL/TLS is located between application-level and transport-level protocols, it can be used directly or indirectly. In the second case, the application uses standard application-level protocols. In the first case, applications use SSL/TLS in conjunction with custom TCP-based protocols. Let's determine the ways that are supported by considering the products. Initially, SSL was adopted only for HTTP, although recently it is used with increasing frequency with other protocols. Most, but not all, libraries use an external implementation of application-level protocols. For instance, PowerTCP besides HTTP supports only FTP and POP. At the same time, IP*Works makes it possible to work not only with HTTP or SMTP, but also with FTP, POP3, IMAP, and NNTP. Add SOAP and LDAP to the list and you will get nearly a full range of common application protocols. As for access to the transport layer, it's more or less supported by all libraries. But, most of them let you use SSL only on the socket level (synchronous or asynchronous). StrSecII and SecureBlackbox leave the TCP side to the user's discretion. SecureBlackbox also provides support for several popular socket classes and components.
Certificates and Storages
One of the main elements of SSL/TLS protocols is certificates and their storages. A certificate is indeed the thing that allows us to authenticate both sides of the conversation. Usually, a certificate contains information about the person or organization for which it was issued, about the organization that issued it, the time limits of its validity, and optionally information that allows applications to check its validity automatically. SSL3 and TLS protocols suppose mediatory certificate presense for servers and optional for clients. Nevertheless, in some cases the server can require a client certificate; for example, to limit access to some information. Certificate management includes such operations as generation and verification of certificates and certificate storage management. While, in the case of validation, everything is easy and clear—all companies offer this service; with generation, things are worse. If you are going to use IP*Works or Chilkat SSL, unfortunately you will not be able to create your own certificate (the underlying cryptography libraries, CryptoAPI and OpenSSL respectively, offer such functionality, but you will need to deal with them directly). Also, not everything is perfect with storing certificates. OpenSSL and Visual SSL don't provide such a possibility at all. CryptoAPI and its "users," IP*Works and PowerTCP, don't go beyond using system storage, while Chilkat and StrSecII give preference exclusively to their own storages. And SecureBlackbox gives you freedom of choice, allowing you to use your own storage as well as the system one.
Platforms and Development Environments
Naturally, the question arises about with which platforms and which development environments one or another tool can be used. It's nice if you confine your plans to Windows. No problems, then—all packages support Windows. But, if Linux is your platform, you are limited to StrSecII, OpenSSL, and SecureBlackbox. For those who prefer newer technologies such as .NET, the possible choices are SecureBlackbox, PowerTCP, and IP*Works (the last one supports Java and PocketPC as well). On PocketPC, you are stuck with CryptoAPI or IP*Works. Users of other platforms, such as UNIX or MacOS, are bound to OpenSSL—only it works on various platforms; however, it will apply certain restrictions on features supported.
How do matters stand with different development environments? What if I am familiar with Pascal but out of touch with C++? Most products can be used in different environments. Delphi and Visual C++ are the most popular environments today. Two of four libraries that have native Delphi code, SecureBlackbox and StrSecII, support Kylix as well. As for Chilkat and PowerTCP, each of them has chosen just one line, the first one being Visual C++, and the second being ActiveX. ActiveX is also supported by IP*Works and SecureBlackbox. In general, these two packages support the greatest number of suitable development environments: Delphi, Visual C++, Visual Basic, C++ Builder, and ActiveX. Besides, IP*Works gives attention to Internet programming, while SecureBlackbox, as stated above, provides the possibility to code with Kylix. CryptoAPI will allow you to work with any development tool that supports DLL or ActiveX.
Whatever user-friendly library could be depends largely on the quality of documentation and support. No one likes to examine all capabilities empirically; so well-structured, full, and understandable documentation is quite an essential element of any good library. Unfortunately, it is not always considered. For instance, Chilkat SSL does not have documentation in principle, and StrSecII has some objects and classes description in its own format, which is not too comfortable to use. OpenSSL didn't go very far: there is a kind of documentation but it is not full in the first place and HTML is used instead of a standard format in the second; that makes working and searching much harder although you can find some outside descriptions and manuals on the Internet, mainly in .pdf format. On the other hand, there are demonstrating examples for practically every package, designed to show how all this has to look at the final condition. To have examples, of course, is very good, but it's one thing when you can look at the finished decision and quite another matter when you must do everything yourself from the very beginning, clearly understanding what is used and why. That's why even examples with detailed description of objects, their properties, and methods frequently are not enough and the developer feels a need for a manual or a handbook for beginners. For some mysterious reasons, this kind of documentation is in disrepute and you can count on this kind of help only when using Visual SSL or SecureBlackbox.
Price and Support
After all, let's see how much you will have to pay for the possibility to use each of the libraries and what kind of support you can expect from developers for your money. First of all, half of the products are free. That affects support, but not in the best way. So, OpenSSL users can get support from the community by means of mailing lists. With Chilkat, you will need to pay for solving each problem you face. As for Visual SSL, you should not wait for any support at all because of the "discontinued" status of this product. CryptoAPI, as part of the Windows OS, does not require separate payment and you can count on Microsoft support and newsgroups.
To use any other library, you will have to buy a license. A StrSecII single developer license includes a 12-month upgrade subscription (for $99); and if you want to add e-mail support and the possibility to receive StrSecII by e-mail or downloaded as a single file, you will need to cough up as much as $399. To solve problems with PowerTCP, besides the license fee ($999) you have to pay more for a one-year support subscription. IP*Works offers several types of support: free and paid. You can expect answering questions, upgrading minor versions, and getting samples to be free. Or, you can get a one-year subscription for $495. It has some advantages compared to free ones, such as high priority of answering the questions, access to additional demos, and limited analysis of source code related to the components. You can also pay for solving problems on per-incident basis. Anyway, the license itself costs $945-$1445 (depending on the development environment you are going to use). With the SecureBlackbox license, you get lifetime support and the possibility to freely download upgrades until the release of the next major version. This is included in the license that is available for fees starting from $79 for client-side only to $369 for site-license, including both client and server sides.
Actually, there are three more libraries we could touch on: Synapse library, Indy, and Internet Component Suite (ICS). They have a lot of similarities; the main one is that they all mainly focused on working with application-level protocols (the selection is quite large), while using SSL is a secondary feature. For the transport layer, all of them use sockets. All products have Delphi/Kylix native code components and, as a result, the possibility to work on Windows or Linux. Linkage of the SSL depends on the secure protocols provider. As a SSL provider for Synapse can be OpenSSL or StrSecII, Indy extends the choice with SecureBlackbox, and ICS can use OpenSSL and SecureBlackbox. All components (except the SSL part for ICS, which is commercial) are freeware/open-source. The capabilities of working with certificates and encryption depend on the SSL providers, too. As for documentation, Indy has only a component reference, Synapse adds F.A.Q., and ICS seems to have no documentation.
So, you can choose from the various packages one that will meet your needs. Just think about what is most important for you: cost, feature-richness, or ease of use. Or, choose the most effective combination of features (I guess you can find the answer above).