SSL beats WS-Security?

The Webservices.org weekly newsletter contained a link to a very interesting presentation about securing web services, given by Brad Hill of isecpartners at Black Hat briefings.

The presentation states that SSL with client certificates is the better mechanism to secure web services. Two main arguments: 1) SSL with client certificates is proven technology and very robust and 2) WS-Security isn't very good because it is so extensive and complex, and therefore an easy target for attack

SSL with client certificates is indeed a strong mechanism for securing connections coming into your DMZ. And the use of self-signed certificates makes the setup cheaper and more straightforward. But the use of SSL with client certificates also has its challenges. Biggest issue is the SSL session termination by a network device in front of you application server. If the SSL connection can be terminated in a container under your control, all information can be retrieved from the client certificate. But in case of such network device, you can only hope (or arrange) that the device forwards information about the client certificate to your application (e.g. using a HTTP header field such as SSL_CLIENT_CERT).

For his 2nd point, WS-Security indeed has (too) many options. Actually, it is more the underlying XML Signing and XML Encryption standards that provide too many options. WS-I will have to do a good job in reducing the number of options and choosing some good defaults. And to make things really secure and robust, the WS-Security implementations should only implement and support what is required by the WS-I Security Profile.

EDIINT AS2 is a nice example how security can be made workable: numerous organizations implement message level signing and encryption when setting up AS2 connections (only complexity is the process certificate renewal when using message level encryption).

So, while not fully agreeing with all the content, the presentation is a great piece of information.