qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: SSL Support in C++ Broker (was Re: C++: SocketPrivate Class.)
Date Mon, 31 Mar 2008 16:36:05 GMT

On Sat, 2008-03-29 at 01:04 -0400, Joshua Kramer wrote:
> Howdy Folks,
> > Is SSL more like TCP than SSL is like Infiniband?  I would argue yes, as SSL 
> > is a layer 5/6 modification to TCP, not an inherently different protocol as 
> > you seem to be coding - are my assertions correct?
> Earlier [1], we were having a discussion regading the best 'placement' of 
> SSL support for the C++ broker.  Andrew Stitcher suggested I create a 
> class parallel to the Socket class (as he is creating an Infiniband 
> class), and I had planned to simply modify the Socket class to add SSL 
> support.
> I may derive a SSLSocket class from the Socket class.  Is there any 
> compelling reason not to do this?

I've thought this over a bit, and I think the code structure need to be
determined by when you know you've got an SSL/TLS connection:

If you have separate listening connections which are either wholly SSL
or wholly not it makes more sense (to my mind) to keep the
implementations separate (but possible to use inheritance if that makes
sense) and to have a new SSL specific Acceptor to be the factory for the
new SSL connections.

However if you don't know before accepting a connection whether it is
encrypted or not then I still think you'd want separate implemetations
as above. But you will need to modify the Acceptor/factory to create
either a Socket or an SSLSocket depending on whether encryption is
negotiated or not.

Does this make sense to you?

I think my major point here is not to obsess about cramming your work
into a single class implementation as that isn't how the division of
responsibilities in this code work.

I'm very happy to help you with understanding the current code, code
review etc.

> Also, what considerations should I make for those who are doing the 
> Windows port of the C++ broker?  At this point I do not have Windows tools 
> available to me.  I'll be using the Mozilla NSS libraries for SSL.

One important point about your work is that it also needs to modify the
autoconf part of the project so that if the NSS libs (and anything else
you depend on) aren't detected then the SSL/TLS support doessn't attempt
to build. But this isn't a specifically Windows point.

Generally in order to do this the cleanest way (which will help the
Windows port) you should be adding new code in new files with only
minimal changes to existing files. The new files are only built if the
platform supports your dependencies.

I will be making a (hopefully) small number of changes to the existing
network IO code infrastructure in the next couple of weeks which should
help this happen.


View raw message