Web Services and SSL

The use of Web Services and Secure Sockets Layer (SSL) is part of an overall solution recommended by many companies and analysts but does not alone have the visibility in the message to provide the proper security to mitigate risks.

Web Services requires granularity on encryption. For example, encrypting sensitive information while exposing routing information in clear-text. This is the reason why the XML Encryption, XML Signature and WS-Security standards were invented and ratified. Viruses and other malicious XML can just as easily be transported encrypted as in clear-text. In fact, it can be harder to detect a compromised SSL connection because it is passing encrypted attacks.

SSL is a good technology for protecting pipes between machines. SSL should be used in conjunction with other security mechanisms to provide transport-level security for Web Services but it is neither purpose-built nor adequate for most security for Web Services. SSL and IP filtering operate on the machine level, providing only a clumsy level granularity for securing Web Services. It does not provide application or user-level Web services authentication or authorization capabilities nor provides encryption and non-repudiation at the element level. Below are some of the reasons why SSL is not recommended as the only solution for securing Web Services.

First of all, SSL can be expensive to provision. Managing the environment and procuring the technology for every single possible Web services consumer and Web Service combination is a definite challenge and a significant cost. Some Web Services may have hundreds and thousands of different requestors. If you were using, for example, mutual SSL, managing the keys across a diverse set of participants would be costly from a management standpoint and represent a potential Web service risk.

It is possible that SSL can be compromised but the likelihood is dependent on the key sizes being used. What is more common is not automatically checking revocation lists (CRLs) whereby the termination points do not check for expired and revoked keys. Many Web Services are also stateless. Creating and tearing down SSL connections for every single message can cause performance problems. In addition, encrypting the entire message can be less efficient than encrypting just specific portions of the message that truly need to be encrypted.

Another important deficiency is that SSL only protects the transport between two computers or devices. If any of the endpoints or intermediaries (such as routers) are compromised, then transport security provides no protection against Web services attacks sent from a compromised machine. Compromised endpoints (often caused by a host-level break-in) can occur for a number of reasons. A disgruntled employee, a recently fired worker or someone who simply wants to take advantage of the system can easily use their knowledge to compromise a machine and perform malicious actions that are very difficult to track with no other checks and balances in place. With only SSL or IP filtering protection, a compromised machine can be used to attack any Web Service that that machine has access to.

Because Web Services are often used (or planned to be used) in external environments such as B2B communication or across firewall communication, there is a reliance on external parties and their security capabilities. If a partner's machine is compromised, then SSL provides a convenient pipe for an outside hacker to attack your systems. Relying on the security mechanisms of an entity outside your control is a major security risk and is obviously not a recommended practice.

SSL provides additional protection for Web Services but is not recommended as the only security solution. For instance, SSL only protects the pipes and provides no protection against host-level or intermediary break-ins. An attack can be sent through encrypted channels just as easily as through clear-text channels but are harder to detect. SSL only provides point-to-point transport protection leaving sensitive information in clear-text outside of the channel. SSL is also rather inefficient in that it encrypts the whole message, not just the parts that require encrypting and is also required for every connection point.

Web services and SSL provides some additional protection for services however they are not recommended for the only security solution

Not all endpoints will necessarily support SSL. Given the types of endpoints such as desktop applications like Mi¬crosoft Excel or even wireless applications like phones, many of these are more likely to support XML Encryption, XML Signature and more granular forms of authentication for communication than SSL.

Diverse Applications Means Diverse Attacks

Any type of application can be behind the Web Services interface. They range from packaged applications such as SAP and Peoplesoft to internally developed applications like J2EE and .NET developed programs to desktop applications. Legacy applications like mainframes can also be exposed via Web Services. These applications obviously carry their own security vulnerabilities which are likely to be even more exposed via Web Services interfaces. In addition, they all approach security in different ways. This presents a significant security challenge to protect these services consistently.

Because Web Services are easy to access and relatively easy to compromise, the likelihood of successful attack is quite high. Given the limitations of SSL in the Web services environment, IT managers can examine some of the security tactics mentioned above: authentication, XML Encryption and digital signatures.

For More Information

Learn more about Web services and SSL – as you investigate a total Web services and SOA management solution: download the free webinar, SOA Governance: Where the Rubber Meets the Runtime