SSL Support in .NET Client

[Tomas Restrepo <to...@devdeo.com>]

As I mentioned in a previous email, now that a few initial patches I've
submitted have been successfully integrated into the .NET client code in the
trunk, I'd like to take a stab at adding SSL support to the .NET client. Is
everyone OK with that?

I've been looking at how best to approach this and I'd like to run a few
things I've thought of by you. Any comments appreciated :)

The first issue is that the .NET Framework v1.1 does not include any out of
the box support for standalone SSL usage (it fully supports HTTPS, though).
.NET v2.0 does support it through the System.Net.Security.SSLStream class,
but we can't use it if we hope to maintain compatibility with v1.1

One possible replacement I've found is the Security Library from
Mentalis.org (http://www.mentalis.org/soft/projects/seclib/). It's open
source, though published under a custom license
(http://www.mentalis.org/site/license.qpx), so someone would have to see if
this is a problem.

Once that is decided, we'd need to look at how to best implement this. I
know the preferred model would be to keep the .NET client as similar to the
Java client as possible, but the underlying connection and transport
mechanisms in both clients are quite different at this level. Most of this
is caused by the fact that the Java client IO and session mechanisms are
based of MINA, while the .NET client doesn't have something similar (only a
portion of the buffer management in mina was ported and implemented in
Qpid.Buffer).

That said, I do not feel we'd need to port MINA to .NET in order to
implement any of this, but it would be nice to refactor the transport layer
a bit to make it easier to implement [1].

Here's one possible proposal for this (very rough draft, as I haven't
touched the code yet):

- Make the ByteChannel (IByteChannel implementation) a bit of a higher-level
construct. Right now, the ByteChannel is what hooks together the
BlockingSocketProcessor with readers and writers on top of the transport
(particularly with AmqpChannel), but it's a very thin layer and tightly
coupled with the BlockingSocketProcessor class.

I'm thinking we could do some fairly simple refactoring here that would
decouple the ByteChannel and BlockingSocketProcessor, by moving the buffer
management (ByteBuffer-related operations) in BlockingSocketProcessor into
the ByteChannel and connecting both classes through a simple Stream
interface. 

This would not only simplify the socket processor, but also make it easier
to do the next step, which is to introduce filtering streams between the
blocking socket processor (or any other potential processor introduced
eventually when we tune the transport layer) and the ByteChannel. In
particular, hook an SSL filtering stream to add SSL in the simplest manner
(fairly simple to do with both .NET v2.0's SSLStream or Mentalis'
SecureNetworkStream class).

- Refactor the transport layer: besides the changes to the
BlockingSocketProcessor and ByteBuffer classes mentioned above, I'd think
that some refactoring of how the transport layer is initialized is needed.
In particular, I'm thinking about the following:

a- Improve how the transport is initialized, including handling it all the
broker connection information (as that's what will contain the SSL
connection requirements).

b- Either formalize the transport -> processor relationship so that any
transport layer is implemented in the same way, or remove the processor and
have the transport class implement the socket operations directly. I'm not
100% happy about the second option, but another option would be to repurpose
the processor classes so that they don't handle socket connection and only
I/O (and maybe rename them to something more appropriate?).

Besides this two big changes, I'm sure other minor stuff might be needed,
but I'd take a look at it better when I'm doing the implementation. One
thing I wouldn't do at first is add client-side certificates for SSL
connections until the improved support for that (which Kevin Smith is
working on) is committed into the Java server and client code and the
authorization issue we discussed is more formalized.


[1] One big difference here between the Java and .NET clients here, besides
MINA, is that the Java client does a lot of stuff through the
AMQProtocolHandler class, which doesn't exist in .NET yet. For example, this
class does all Heartbeat operations, which in the .NET client are
implemented directly (and I think partially only) in the AMQConnection class
directly.

I think that moving that stuff out of AMQConnection and possibly implement
something similar to AMQProtocolHandler in the .NET client would be good,
but there's a bit of stuff in there I haven't quite figured out yet as I'm
not very familiar with MINA.

I'd sure appreciate any comments on this issue!

Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/