Mashed Articles

Again a great “Security Now” podcast about SSL: how governments can sniff SSL traffic by enforcing Certificate Authorities to provide them with (intermediate CA) certificates. Based on this paper. Great story, recommended reading or listening!

Some things that I picked up:

• Different CA’s can provide you with SSL certificate for same URL (or whatever)
• Internet Explorer (actually the Windows crypto) downloads extra CA’s dynamically; so the list you see in IE can grow behind the scenes
• Firefox manages the list of trusted CA’s itself
• There is no standard policy for when a CA is accepted by browser vendors
• The list of trusted CA’s should be based on your geographical location
• Trusting a CA is somewhat equivalent to trusting a government
• Browser should provide (advanced) users with extra features to help them decide if CA certificate should be trusted or not

In my daytime job, SSL/TLS is used a lot for communication between IT systems within the corporate firewall or with business partners across the Internet. Low level configuration of SSL/TLS is often not supported:

• Configure single CA (or self-signed) cert to be trusted for specific outbound connection (e.g. when business partners have defined their “own CA”)
• Different SSL client certificate per outbound connection
• Easy configuration revocation checks (OCSP etc); and checking if the revocation checks actually work
• Different timeout settings per connection
• Only accept SSL connections on specific interfaces

Invoking services within the Intranet was in the design of Azure from the start. The .Net Services Bus of Azure allows local services to be called from the cloud.

A connection is setup from within the corporate firewall to the Azure servers in the cloud. This bidirectional connection is used to invoke services on the Intranet. The Services Bus is much more advanced than the Secure Data Connector from Google.

Azure is not limited to .Net, there are also Ruby and Java SDK for .Net Services available! To learn a bit, I downloaded and installed the Java chat sample. Encountered the error “The subscription cannot be created” during my first experiments. But waiting a while resolved the issue: probably the service didn’t unregister correctly during my first runs and the service bus needs to detect that the service was no longer present.

In the Chat example, client and service are running in the same application (multi-threaded). No need to deploy the service implementation in an application server. Also nice to see how the JAX-WS API is leveraged to create the service.

Connecting from Azure to Amazon (or the other way around) should be trivial. But integrating Azure with AppEngine (or Force.com) is a different story. Both cloud have there own version and solution for integration and interoperability. A ESB hosted in the cloud or behind the corporate firewall will bring that interoprability.

All existing messaging solutions (WebSphereMQ, JMS, …) use proprietary protocols. This is not a problem within a single organization. But between organizations, standard protocols are needed. Therefore, the B2B world uses protocols such as AS2, RNIF (RosettaNet) or good old (S)FTP(S).

AMQP is an initiative to bring a standard binary wire protocol to the messaging world. Just like POP3+SMTP allows you to retrieve and send emails using whatever email server, AMQP will allow any AMQP client to receive and send messages via any AMQP compliant server.

But when I read the spec, AMQP is focusing on the client-server protocol, contrary to SMTP that is (also) used for communication between mail servers. The AMQP spec states that a bridge should be used for server-2-server communication, but doesn’t provide any details. As such, AMQP is focusing on messaging within the corporate firewall.

AMQP can be used for unbalanced B2B scenario’s, where one side runs the AMQP broker. This is a setup similar to one big company or intermediary running an (S)FTP(S) server and smaller organizations putting and retrieving files from it. But for good decoupling, server-to-server communication is preferred. The server at the sending side will take care of delivering the message to the server at the opposite side. Like e.g. AS2 does: once an organization has an AS2 server in place, it becomes equal to all its AS2 counterparts.

With all this in mind, I was a bit puzzled by Paul Fremantle’s enthusiasm about AMQP. In particular because he is the WS-RM spec lead.

WS-ReliableMessaging should have brought reliable async messaging to the WS-world. But it didn’t. The WS-RM spec doesn’t mention message persistence and so (most) vendors have an in-memory implementation, which is not reliable.

I still remember going through the book “Programming Indigo” and learning about the ReliableSessionEnabled binding property. What a disappointment to learn that for real reliability, one had to use the MsmqIntegration Binding and thus the proprietary MSMQ transport layer.