• Login
• Become a member
• RSS
• Part of the TechTarget network

Where is SSL finding traction in securing Web services?
If you look at the different areas where people are using Web services, you find that they primarily fall into the following categories: (a) Company internal distributed applications that previously might have used RPC or CORBA

or even DCOM or RMI for inter-application communication; (b) ISVs who are adding a Web services-based interface to their products, in addition to existing APIs; (c) Internet companies such as Amazon, Google and eBay, which are exposing part of their service through Web APIs for consumption

Not many people realize that SSL allows negotiation of the key size for encryption and the cryptographic algorithms at runtime. Pankaj Kumar, HP technical architect ,

by programs; and (d) B2B projects that use Web services for intercompany exchange of information.

SSL is great for securing the transport pipe. It has been around for quite some time, most people understand it and the interoperability among various implementations have improved significantly. And although it is not as easy as direct HTTP interactions, moving from HTTP to HTTP over SSL or HTTPS requires, in most cases, simple deployment time configuration changes only, avoiding costly redesign or source-code level changes. Given the array of security areas that get addressed by SSL, privacy, integrity and authentication of end points, use of SSL is indeed very attractive.

For category (a) Web services, the security needs are minimal to start with and are usually satisfied with moving the transport from simple HTTP to HTTPS. Same for most of the category (b) uses. Category (c) is interesting. Most of the publicly available Web APIs in this category don't support even SSL (though, they can without much change). I suspect that most of these are still at experimental stage and the need for security hasn't been very strong. Category (d) is an entirely different story. Applications conforming to standards such as ebXML are more demanding and would require message-level security support. Is SSL suitable for B2B Web service transactions between suppliers or partners, or is it solely a B2C proposition?
SSL works just fine for transport-level security but breaks down at the message level. If the requirement is to allow only trusted parties to participate and to secure the data from prying eyes, SSL fits the bill. But if the requirement is to use multiple transports, say HTTP and then JMS, and you cannot trust the point that acts as gateway between HTTP and JMS, then you may need to rethink your security strategy.

But because the message-level security technologies -- such as XML DSig, XML Encryption, WS-Security and many others -- tend to be complex to deploy and hence are yet to get wide adoption, there is a tendency to use SSL as a starting point. What kinds of hacker attacks is SSL well suited to hold off? Which would it fail against?
SSL is great at thwarting attacks based on network sniffing. If your data is flowing over SSL, then you can be sure that no malicious or compromised router would be able to retrieve the data. It is also great at authenticating the server -- and the client, if you set up for mutual authentication – by using X.509 certificates. This authentication mechanism is usually much safer than the password-based authentication of the client, such as HTTP-Basic or HTTP-Digest or any other plain text token-based authentication.

If the application requires the data to be stored on disk before processing, then SSL can't protect against attacks on that data. This could be a significant consideration for certain Web services-based applications.

However, there are a number of attacks against which SSL -- or for that matter, any technology -- is going to be ineffective. These include attacks based on software vulnerabilities that allow a hacker to take control of the machine. Similarly, it is hard to fend off against social engineering-based attacks. Can SSL be used alone with Web services, or are digital signatures or some other secure authentication method required?
Again, it depends upon what exactly you are doing with Web services. If you are using Web services

For more information Read another take on SSL for Web services   Learn about a recommendation for standalone XML gateways

just as a means for an interoperable and easy-to-deploy online interaction mechanism -- and, by the way, these are perfectly valid uses of Web services -- then it is perfectly OK to use SSL as the security solution.

On the other hand, if you have a workflow solution that uses Web services to move around documents, and you need document-centric security, then you should be thinking about XML digital signatures and XML encryption. Is SSL too bandwidth- or CPU-intensive for Web services? Do the benefits justify the expense?
All cryptographic solutions, including SSL, have the reputation of being CPU intensive. However, with Moore's Law making sure that we get more and more computing power for the same dollars, the performance overhead of SSL is less and less relevant. For a heavy load, one could always buy special hardware accelerators, which again, are not very expensive.

Not many people realize that SSL allows negotiation of the key size for encryption and the cryptographic algorithms at runtime. So you can actually adjust the security level, and hence the computing power needs, to meet your application demands.

The increase in message size due to SSL is not very significant, and is rarely a concern. Does SSL scale well enough for Web services transactions?
Yes. Unlike technologies like XML Digital Signature and XML Encryption that require the complete message to be available, at times, as a DOM tree, SSL can work at the byte stream level, avoiding the need for extra memory to hold the complete message. This also allows pipelining of processing. Additionally, the SSL processing of messages for two different connections can happen completely in parallel. Are there any emerging XML security technologies that can address Web services security requirements that are not provided by SSL?
As I noted earlier, SSL does not provide message-level security. Also, SSL does not address the problem of key management, secure assertions and access control. A number of technologies are being developed to address these. XML Digital Signature and XML Encryption are already W3C recommendation. WS-Security, which combines these for use in Web services, is now an OASIS standard. SAML, addressing the need for secure assertions, and XACML, addressing access control, are also now OASIS standards.

However, most of these standards are new, and it will be while before they get widely deployed. How would an organization address the fact that SSL often lacks authentication for Web services?
 

Well, if you use mutual-authentication feature of the SSL, then you do get client authentication. However, client-side authentication through SSL is not widely used due to the difficulty in managing client certificates. Some people address this by using HTTP-Basic or a token embedded in the XML message and then transmitting the message over HTTPS. This is great because SSL makes sure that sensitive information, such as account identification and password, is not transmitted in clear text over the Internet.

Join the conversationComment

All Rights Reserved,Copyright 2001 - 2013, TechTarget