NetKernel News Volume 6 Issue 4 - On Software Fortresses
search:

NetKernel News Volume 6 Issue 4

March 27th 2015

Catch up on last week's news here, or see full volume index.

Repository Updates

NOTE: As announced previously, Java 6 is now end-of-life and since January 2015 all modules are built and target Java 7. Do not attempt to install updates if you are still running Java 6.

The following updates are available in the NKSE and NKEE repositories...

  • database-relational-1.18.1
    • Ehnancement to the configuration of the ConnectionPoolAspect - now supports which, in the event that the pool is fully consumed will wait a designated time in order to try to provide a connection. Default behaviour is unchanged where an exception is thrown if no connections are free. Thanks to Dave McCormack at Boston College for suggesting and testing this.
  • http-client-2.22.1
    • Security enhancement - SSLSocketFactory now defaults to use TLS v1.2 even on Java 7 (see below).

The following update is available in the NKEE repositories...

  • encrypted-module-factory-1.15.1
    • We managed to find a way to get the more tolerant licensed module factory to update via Apposite (so just accept this update - no need to do clean install to get this enhancement as we suggested previously )

HTTP Client TLS v1.2

By default Java 7 still uses TLS v1.0 for secure sockets. TLS v1.0 is known to be vulnerable to the BEAST attack potentialy exploitable with javascript.

Java 8 now defaults to TLS v1.2 and, in fact, Java 7 supports TLS v1.2 - however, for reasons of being "compatible with historical servers", it is not used as the default!

Given that we have now made Java 7 the minimal Java target platform, we've taken the opportunity to improve TLS capability of the http-client library.

With today's update, when no user-specified connection manager is provided, active:httpGet (Post, Put etc etc) now defaults to TLS v1.2 on both Java 8 and Java 7.

TLS supports negotiating the protocol version, so if you do talk to an old server still running TLS (or even SSL!) then there should be no issues.

TLS/SSL is a moving target, so you might like to save a copy of this Groovy script in the Scripting Playpen...

//Test TLS client capabilities
s="https://www.howsmyssl.com/a/check"
rep=context.source(s, String.class)
context.createResponseFrom(rep).setMimeType("text/plain")           

This will provide a JSON report for the TLS capability of the Java stack you are currently running on.

For the record, on the server-side, the recent Jetty 9 update to the http-server module defaults to TLS v1.2 even on Java 7. To check any server-side TLS version you can use Chrome or Firefox by visiting the site and examining the padlock connection status.

Tony's Blog: Gödel Alone Knows

In a dramatic move that risks damaging his reputation as the "practical one in the 1060 Research team who actually makes stuff", Tony has started a series of articles that explains how ROC traces its history back to the fundamental mathematics of Gödel numbering...

History of Gödel Numbering - Part 1

History of Gödel Numbering - Part 2

I know for a fact that there's a third part in draft since he's determined to shame me by actually completing a series of articles once he's started it!

Tony is able to risk this flirtation with academia, since he knows full well that he can restore his reputation any time by publicly unveiling another killer bit of IoT electronic device engineering he's put together. Watch this space...

On Software Fortresses

A month or so back, I was in a conversation introducing ROC to Paul Worrall founder of Interition. Paul has a deep background in enterprise architecture in the financial sector - he's got some very cool ideas/solutions on how to solve a critical banking problem: how to know who actually wrote your software (the problem of software provenance) and what it is doing - questions that are increasingly becoming a regulatory compliance requirement.

We rapidly dug into some of the standard ROC patterns and how they relate to security (for example the Trusted Notary demo).

Next day Paul explained that, after seeing the ROC patterns, his head had been full of ideas - he told me I needed to read a book called Software Fortresses and explained that the Software Fortress pattern is regarded as the ideal by a number of banks.

The problem, as he explained, is that it is very hard to actually get right when your building blocks are objects and low-level Java code. In fact, in his experience, even with all the resources that a Bank can apply to the problem, the ideal never makes it to reality.

When I got hold of my copy of the book, I quickly understood why Paul was excited.

The software fortress pattern is very simple. It consists of a walled fortification within which a given business function resides. Access to the business function is only possible by sending a message to a Guard acting as the Fortress gatekeeper. The Guard accepts (or rejects) the message and, crucially, translates the message into an approved, validated trusted inner message.

The business function within the Fortress is not interacting with an untrusted external party - it is simply satisfying an approved trusted request from the Guard. The Guard acts as a trust broker.

Here's what it look like pictorially, the book takes its time to justify this, but the diagram is really all you need to understand the pattern...

Anything look familiar? What about this...

The Software Fortress is a specific instance of the general ROC/NetKernel Overlay pattern. In fact we call the Software Fortress pattern the GateKeeper Pattern (discussed in our overlay patterns book, with a worked example in the wiki tutorial - Ironically you were permitted to view this page by that very same GateKeeper since this wiki is contained within its own Software Fortress!).

NetKernel comes with literally dozens of embodiments of Overlay. The mapper, the throttle, the pluggable overlay, the HTTPBridge, etc etc. There is even a standard base class StandardOverlayImpl in NKF to easily create your own.

And since Overlays are just ROC spacial patterns, we can compose them and evolve them with no brittleness and without any side-effects on the encapsulated business functions.

So now I see why Paul couldn't sleep that night. ROC makes turning the Software Fortress ideal into a practical and easily accomplished reality.

DrawBridge / Reliable Messaging Prelude

I didn't elaborate on the role of the drawbridge in the discussion above. In the book, the drawbridge is assumed to be a reliable messaging infrastructure such as MQSeries and the like.

This got me thinking, if we know that the ROC abstraction dramatically simplifies complex N-Party interactions - such as we show in the Trusted Notary demo - what would a full ROC Reliable Messaging solution look like???

So I've set myself a challenge to build it. I may crash and burn, but in the style of the TicTacToe series, next time I'll try to explain how to think about and build a solution to this problem the ROC way...


Have a great weekend!

Comments

Please feel free to comment on the NetKernel Forum

Follow on Twitter:

@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff

To subscribe for news and alerts

Join the NetKernel Portal to get news, announcements and extra features.

NetKernel will ROC your world

Download now
NetKernel, ROC, Resource Oriented Computing are registered trademarks of 1060 Research


WiNK
© 2008-2011, 1060 Research Limited